That's... very basic. Not an awful lot of useful information about the hardware environment.

The challenge for things like EC2 is more in that most cloud hypervisors, for security/performance/complexity reasons, have stopped emulating the older hardware a lot of "basic osdev projects" rely on. So you're stuck with a very modern set of hardware for interrupt controllers, disk IO, etc. I was hoping to see something more along those lines here, not just how to make and upload a disk image.

Is there a particular OS you had in mind that doesn't deal well with modern hardware?

I guess it depends on how you read "Your OS." I read it as "Hobby osdev project."

"Port your OS to EC2," as I read it (I live in weird weeds so this may not be how other people read it) implies an OS you've written ("your OS") that currently doesn't run on EC2 (or you wouldn't need to "port" it - that implies, at least to me, getting something running where it doesn't currently run).

A lot of the hobby OSes out there, even if they're 64-bit, don't always support the latest and greatest drive controllers, interrupt controllers, etc. So if you don't have NVMe support (or virtio block device support - not sure if EC2 supports that or not), you won't be able to read the disk. Legacy ATA/SATA interfaces are often what's supported.

I would have expected, based on the title and what it implied, a list of the hardware supported in various instance types. If the virtualized instances support virtio, mention it. If they only support SATA or NVMe, mention that. And perhaps some references to the relevant specs to implement those.

But if all you have to do to get your OS running is just put it on a disk image, then I'm not sure it really qualifies as "porting to EC2." Just "Installing on" would be more useful phrasing for that.

You are correct. There are actually quite a few different configurations available on AWS alone - not to mention most cloud providers are very different. What works on one instance type on AWS won't immediately run on Azure without additional drivers.

Google Cloud is probably the most friendly one for hobby osdev cause they are based on KVM.

For instance when starting with https://github.com/nanovms/nanos (whom I'm with) we targeted the t2 instances first and it actually took a longer time to come up with support for some of the newer t3 instances because we had to add ENA and NVMe drivers.