Disclosure and claim to authority: I work on the Windows team at Microsoft, sometimes on performance and OS installation stuff.
There's definitely some cruft that chews up time on first boot. But it's not everybody's favorite punching-bag, licensing. That stuff doesn't happen in the critical boot path.
It might be installation of device drivers, but that too is unlikely. If you generalize Windows in a VM, you can use the `sysprep.exe /mode:vm` flag, which essentially tells sysprep to retain most of the device tree, since you expect to run the thing on similar hardware. I would assume that AWS is clever enough to have found that flag; certainly we have Azure use it. When the flag is used, there's very little device- and driver-related work to do on first boot after generalization.
The reality is that software is complicated and hard, and anything punchy enough to fit into a comment on a website is going to be a vast simplification of reality. So let the simplification begin :)
One reason first boot is slow is the component that orchestrates startup of usermode services, which on Windows is called SCM. SCM is very old. At the time SCM was created, it was much better than the SysV-style init scripts of other OSes. But since then, other OSes leapfrogged Windows with systemd/launchd, which are a generation ahead of SCM. SCM starts services in serial, while systemd maximizes parallelization. SCM has a "push" model: it basically starts all the services that it can find, while systemd has a "pull" model: it starts just the dependency cone you need to get the system you want. (This is a simplification.)
Another performance issue is that Windows doesn't have a way to notify code that the hostname has changed. Obviously it'd be easy to add one, but then the hard part would be updating the whole OS to do something reasonable with that notification. So instead, Windows requires a reboot to change the hostname. Except first boot: to avoid a reboot as soon as you power on your shiny new computer, there's a clumsy dance where the OS holds back most usermode processes until the hostname is set, then it sort of tries booting usermode again. (Huge simplification!)
Thirdly, the footprint of Windows is just bigger than that of an expertly hand-tuned Linux installation. Much of this problem was solved with Nano Server... but are you actually using Nano Server? It turns out that people like Windows because Windows runs Windows programs. Take away compatibility with many Windows programs, like Nano Server did, and you get a much faster and more secure OS that nobody's heard of.
We take both perf and cloud hosting seriously, and we're working on problems in this space. You should expect Windows to get better with each release. But to close this off, I don't want to hog all the blame. It's always possible that AWS is doing something silly in their guest agent or paravirtualization stack that measurably degrades boot perf. We've previously caught Azure doing silly things -- now fixed -- that seriously delayed the amount of time before the guest reported itself as ready. If you want to see Windows hosting done well, try Azure.