Autoscaling
Autoscaling automatically adds compute capacity when demand rises and removes it when demand falls, driven by rules you set (CPU, request count) or a schedule. It's how the cloud handles your busiest hour without you paying for that hour around the clock.
Autoscaling is the cloud automatically adding compute capacity when demand rises and removing it when demand falls, driven by rules you define, CPU or memory thresholds, request counts, or by a schedule. The system grows to meet a spike and shrinks back afterwards with no one touching it.
In plain terms
On-premise, you size for your busiest hour of the year and let that hardware idle the other 8,700 hours. Autoscaling inverts it: you run a small baseline, and when the Black Friday surge hits, the platform launches more instances behind your load balancer; when traffic fades, they’re terminated and the meter stops. You set three things, the floor, the ceiling, and the trigger. AWS calls this an Auto Scaling group, Azure a Virtual Machine Scale Set, Google Cloud a managed instance group; the idea is identical.
Why it matters when you migrate
- It’s where the cloud’s cost advantage actually lives. A lift-and-shift that keeps fixed-size servers running 24/7 pays cloud prices for on-premise behaviour; replatforming to autoscale is where the savings show up.
- Your app has to tolerate it. Instances appear and vanish without warning, so the app must be stateless, nothing irreplaceable on local disk, and fast to start. Many legacy apps need work here before autoscaling helps them.
- Always set the ceiling. An unbounded scaling policy meeting a traffic surge, or a bug that looks like one, is a classic route to bill shock. The max-instances cap is the cheapest insurance in the cloud.