Most cloud providers can spin up an instance to SSH-able pretty quickly (seconds), if it's holding you back, you may want to look at the image you're using to boot those instances - perhaps it has dependencies you weren't hitting in your datacenter that you might in the cloud (multicast, firewall rule differences, etc). Alternatively - are you building "weird" instances? (A lot of extra disks/NIC's/resources) Those can take a longer time just to find a spot where there's locality with all of your parts (but these days that's less common).

Otherwise, if it's bare metal, I'm usually still waiting for the ram to finish counting by the time I'm done with whatever cursed thing put me back in a cage.

Just using the standard image they provide for Kubernetes.

I didn't do the work of reverse-engineering all the bloat that's in there.

Because they do a lot of stuff some is complex.

> If it's not gonna boot fast, I don't see the point of replacing straightforward shell scripts.

If you do a lot of stuff and have a complex boot shell scripts are neither fast nor 'straightforward'.

such instances might be booting more than once.

One for general startup expanding the root fs to the available boot disk size, one more to run cloud-init or equivalent, and the a final more.

Then again, depending on what services are actually enabled... It might take a bit more to become available/ready/green for use.

Why?

Systems don’t just boot slowly “in general”, there’s specific things happening slowly and if you know exactly what the you can fix it.