> and let's be real, it's low 5 minutes at least for most resources like instances
If you've got a pre-baked application AMI, are using EBS-backed instances, and are starting them with auto-scaling or health-checks rather than manually using the console, then no, you really can have new instances up in a couple of seconds.
Mind you, the key (to getting a high ROI from AWS) isn't scaling up on a dime. It's scaling down on a dime, whenever your load decreases for even a minute or two, knowing you can just scale right back up. Being able to run with literally no paid compute-hours spent sitting around doing nothing waiting for a task can save you a rather large amount of money, usually quite easily compensating for that 30-40% AWS surcharge.
Amazon and people who have been hit by this seem to disagree with you:
"Pricing is per instance-hour consumed for each instance, from the time an instance is launched until it is terminated or stopped. Each partial instance-hour consumed will be billed as a full hour."
"You are billed for an EC2 instance-hour for each hour or partial hour (rounded up) that your instance is in the “running” state. Instances that are in any other state (“stopped”, “pending”, etc.) are not billed."
Here's a company that got hit hard by that behavior :
"A little-discussed fact about AWS EC2 pricing is that users are billed for each server that runs for any partial hour it runs. That means if a user starts a server and then kills it within five minutes, he is still billed for the full hour. That seems acceptable, but if a user kills a server and replaces it with a new server of the exact same type and location, this move doubles the bill."
I'd love if you could point the way then, because my pre baked AMIs that are EBS backed are always taking at least 3-5 minutes to be healthy and processing traffic or requests from the moment they're spun up.
This is not restricted to a specific instance type, nor a specific region.
There is literally no way you are performing compute in seconds from when an EC2 instance is instaniated.
I've bookmarked this to come back to benchmark this.
> whenever your load decreases for even a minute or two, knowing you can just scale right back up.
Doesn't AWS still charge by the hour ... so if you were spinning instances up and down based on minute-to-minute load you would be overpaying for vs just maintaining a steady baseline.
If you turn an instance off you need to be pretty confident it will stay off for at least an hour.
Would it make sense to spin up a bunch of instances and then stop them, then manage your own autoscaling by just starting/stopping rather than launching/terminating? What's the downside there? You only pay for EBS storage, which is a tiny fraction of compute costs.
If you've got a pre-baked application AMI, are using EBS-backed instances, and are starting them with auto-scaling or health-checks rather than manually using the console, then no, you really can have new instances up in a couple of seconds.
Mind you, the key (to getting a high ROI from AWS) isn't scaling up on a dime. It's scaling down on a dime, whenever your load decreases for even a minute or two, knowing you can just scale right back up. Being able to run with literally no paid compute-hours spent sitting around doing nothing waiting for a task can save you a rather large amount of money, usually quite easily compensating for that 30-40% AWS surcharge.