This is an admission that their UX sucks and makes it hard to know what state your account is in and what you're paying for. They waive the fees because a few high profile cases of people paying thousands due to the AWS console being awful would drive a lot of customers away.

I do feel your pain though. Managing AWS costs can be a full time job itself.

For smaller customers, the friendliness of customer support and the flexibility to help them if they make mistakes is much more likely to be a retention consideration. And who knows when a company spending 3 digits a month becomes a customer spending 6 digits a month? You want to be the provider of choice in case the company grows.

Except it doesn't cost them anything. The marginal cost of keeping your single instance running is $0 (unless they were 100% out of capacity and they could have sold that instance to someone else either at full price or spot price)

Your argument is like saying that a bus traveler costs the gas needed to power the bus, but it's never the case: the bus would be cruising no matter what. And symmetrically the VM host would be up no matter what you did with your instance.

It would be very bad for any cloud provider to leave hosts with only one VM running on it, and you can be pretty sure only very small minority of their park that end up in that situation where shutting down a single VM would lead to a shut-down of the entire host, because it means that the host was vastly under-used in the first place.

At least in AWS, they never supported this, and in fact may require you to reboot an instance occasionally in order for it to be moved to a new hardware host (typically when they are upgrading their hardware).

The way you easily deal with this issue is very simple and does not require moving VMs: you just allocate newly spawned VMs to existing hosts with available room! When you do so (and they obviously all do!) you end up with little unused hardware…

Now you have 19 VMs running, but need to keep all 3 hosts powered. If you don't have live VM moving, you are now forced to keep Host3 running only because 1 VM is running on it, even if that VM is idle. So, this one idle VM is responsible for all the energy consumption of host3, and will continue to be so until at least 3 more VMs get started (since you have room for 2 more VMs on host1).

If you did have live VM migration, or if the idle VM were powered down instead of running idle, you could close host3 completely, moving the VM to host 1, and only re-open host3 if needed for new VMs.

This is equivalent to the problem of memory fragmentation. Even though overall usage is low, if host usage is highly fragmented and you aren't allowed to move used memory around (compacting), you can end up consuming far more than actually needed.

Yes it is similar to memory fragmentation in some way, but your argument is like saying an integer stored on the heap costs a full memory page! You realize that it's nonsense. Sure in extreme edge cases it can, but that's not a good metric to know the memory footprint of an integer!

Being able to move VMs is nice as it allows more host use, but it's doesn't mean hosts end up with single idle VMs often!

[1]: let say 10W, which at $.2 per kWh[2], ends up costing $17.5 for an entire year!

[2]: electricity prices from [here](https://www.eia.gov/electricity/monthly/epm_table_grapher.ph...) $.2 per kWh is slightly above the rates in California and Rhode Island, which is the highest in the US for industrial use.

It's very low cost, especially if its on a VM from a host that otherwise runs other VMs, but it's not 0. And if it happens to be the last VM preventing a hardware server from completely powering off, then it's actually quite far from 0.