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.
New to cloud? CAMPUX is a free, build-first course. Start here →
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. Write the rules once and the instance count stops being a number you guess at midnight; the crowd sets it, and your bill finally tracks the load instead of the peak.
Questions people also ask
What is autoscaling in Azure?
Autoscale is a service that automatically adds and removes resources to match the load on your application. When demand rises it adds instances; when demand falls it removes them. You set the rules once, and Azure Monitor watches the metrics or schedule and acts on your behalf from then on.
How does autoscaling work in Azure?
Azure Monitor tracks a metric, such as CPU usage, or a schedule you define, then compares it against the rules in your autoscale setting. When a rule's condition is met, it changes the instance count within your configured minimum and maximum, adding capacity on the way up and removing it on the way down.
What is the difference between scaling up and scaling out in Azure?
Scaling up (vertical) makes an existing instance bigger — more CPU or memory — and often needs a restart. Scaling out (horizontal) adds more instances of the same size, running behind a load balancer with no restart required. Azure autoscale only scales out and in; it does not support vertical scaling.
Which Azure services support autoscale?
Autoscale settings apply to Virtual Machine Scale Sets, the Web Apps feature of App Service, and API Management, among others. Serverless options like Functions and Container Apps scale on demand and to zero on their own, without you writing autoscale rules.
Does Azure autoscale save money?
Yes. Instead of provisioning for peak load and paying for that capacity around the clock, autoscale removes instances once demand drops, so you pay for capacity closer to what you are actually using. The minimum and maximum instance counts keep the app alive without letting a runaway scale-out blow your budget.