Autoscaling in Azure: add instances when it's busy, remove them when it's not
Sizing a server for your worst hour means paying for that hour all day. Autoscale flips it: the app grows more instances when the crowd arrives and quietly gives them back when it leaves — the elasticity that was the whole reason to be on the cloud.
On-premises, you buy for the peak: enough hardware for Black Friday, idle the other 364 days. The cloud's promise was to stop doing that, and autoscale is how you cash it in. Microsoft's definition is plain: it is "a service that you can use to automatically add and remove resources according to the load on your application." Busy? It adds instances. Quiet? It removes them, and your bill shrinks. You describe the rules once; the platform matches capacity to demand from then on.
Scale out, not up: the distinction that matters
There are two ways to give an app more power, and autoscale does exactly one of them:
- Horizontal scaling (out/in) — change the number of instances. Add three more VMs to the scale set under load; remove them when it passes. This is what autoscale does.
- Vertical scaling (up/down) — keep the same count but make each instance bigger (more CPU, memory). The docs are explicit: "Autoscale does not support vertical scaling." Vertical scaling hits a hardware ceiling and often needs a restart.
So autoscale is about more copies, not bigger boxes — which is exactly why cloud apps are designed to run as several interchangeable instances behind a load balancer. Horizontal scaling is nearly limitless; vertical scaling runs out of bigger hardware.
What triggers it: metrics and schedules
Autoscale acts on rules, and rules fire on one of two things:
- Metrics — a live signal like CPU usage, memory, or queue length. "Scale out by adding VMs when average CPU per VM is above 70%; scale back in when it drops to 40%."
- Schedules — a time pattern you know in advance. "Every Saturday at 8am, scale out for the weekend rush." Schedule-based rules let you grow before an anticipated spike rather than reacting after it hits.
Every autoscale setting has a minimum, maximum, and default instance count — the floor keeps the app alive, the ceiling protects your budget from a runaway scale-out. Between those bounds, the rules move the number.
With multiple rules, autoscale is deliberately cautious about growing and eager to be safe about shrinking: it scales out if any rule is met, but scales in only if all rules are met. In other words, any single sign of pressure adds capacity, but it removes capacity only when every signal agrees things are quiet. That asymmetry is a safety feature — it errs toward keeping the app responsive rather than aggressively cutting instances.
You sized for the average and set a ceiling for the peak. The crowd, not you, decides how many instances run right now.
Where it works
Autoscale is built into the services designed to run many instances — most notably Virtual Machine Scale Sets and the Web Apps of App Service, plus others like API Management. (This is a good moment to note that some platforms scale themselves: serverless options like Functions and Container Apps scale on demand and to zero without you writing autoscale rules at all.) For the classic VM-fleet or web-app case, you attach an autoscale setting and let it run.
The takeaway
Autoscale is elasticity made concrete: define a floor and a ceiling, write a couple of metric or schedule rules, and let the app add instances when demand rises and hand them back when it falls. Remember it scales out, not up — so design your workload to run as several stateless instances — and lean on the "out on any, in on all" logic to stay responsive under pressure. Set it well and you stop paying for your worst hour around the clock, which is precisely the deal the cloud promised. "Autoscale rules on the scale set, metric-driven with a schedule for known peaks, floor and ceiling set" is the answer of someone who has right-sized a real workload.