[YokoZar]

I once considered writing an EC2 autoscaler that knew the exact timestamps of the instances so that it could avoid shutting down VMs that still had 59 minutes of "free" time left because they'd been up across another hour-long threshold. That sort of nonsense logic shouldn't be useful, but Amazon was giving a huge economic incentive for it.

This is certainly a long time coming.

[daigoba66]

If it helps, AWS' default auto scaling algorithm specifically takes into account instances which are nearest to their next billing hour and prioritizes those for termination accordingly to, in theory, save money.

[matwood]

> I once considered writing an EC2 autoscaler that knew the exact timestamps of the instances so that it could avoid shutting down VMs that still had 59 minutes of "free" time left because they'd been up across another hour-long threshold.

Years ago my boss at the time did this (this was when scaling had to mostly be done in code/by hand). I just recently updated all the code as I moved it to using spots. The low price of spots made it less important to shut ones down closer to the hour mark though.

[vacri]

Remember that AWS has been in the game for over a decade. Per-hour billing was amazing when it came in.

Also, is the economic incentive really that huge? Or is it just a nicety?

[jdc0589]

it's totally dependant on your workload. for some users there will be absolutely no difference, for others it could easily be thousands or tens of thousands of dollars of savings over a year.

[vacri]

Thanks, I stand corrected. I've read through a few other use cases in the comments here and I can see now that there's scope for savings, depending on workload.

[macarthy12]

> that it could avoid shutting down VMs that still had 59 minutes

AWS batch currently does this. I presume that will change now.