It's kind of funny just how much slower it is to write — and particularly test — #Windows oriented configuration-automation that's equivalent to #Linux oriented content (even using simplification frameworks like #SaltStack).

Maybe it's just me, though. Maybe if I were more Windows-oriented, the relationship would be inverted (at least for the code-up part).
The days I tend to post more are the days where I'm working a Windows-heavy workload. With how much slower it is to iterate with #Windows EC2s, it leaves a lot more "dead" time that I tend to fill by reading from and/or posting to Fedi.

The speed-difference between #EC2Launch and #cloud-init is pretty stark. When I fire up a #Linux instance that has a #userData payload, doing:

sleep $(( 60 * 2 )) ; ssh <USER>@<INSTANCE_ID>Is usually sufficient to get me a login. If I launch a Windows-based EC2, I usually have to do:
sleep $(( 60 * 10 )) ; aws ssm start-session --target <INSTNCE_ID>Unless I want the dreaded "not available error". Worse, while two-minute pause for the cloud-init/Linux EC2 usually logs me in with the cloud-init content well underway, the #SSM login, after a ten-minute pause, usually has me arriving well before EC2Launch has even finished unpacking its data to start executing powershell scripts. It's like "dafuq is taking you so long??"

It feels like #EC2Launch operates at about 1200bps when talking to the metadata service.
In a way, it reminds me of how old Sun E10Ks' domain-configuration would pull information. Dog. Slow.

Also reminiscent of when I was stuck doing StorageTek (tape-library) work and customers were using serial-based control systems rather than updating their boards so that they could use TCP/IP without the need for SLIP.
I guess maybe the slowness contributes to why #AWS never added the same kind of "extract a ZIP'ed #userData payload" that's available in #cloud-init. If #EC2Launch is this gawdawful slow with a text-stream payload, how slow would it be if it had to convert a ZIP-stream into uncompressed data".