Autoscale

What it is

Autoscale automatically adds or removes instances of a supported Azure resource as demand changes. It uses metric-based rules, schedules, or both, together with a minimum and maximum instance count. It is usually horizontal scaling: adding or removing copies of a workload, not making one VM larger.

Why it exists

Demand changes. Northwind’s ordering site needs more application instances during a lunch-time surge, but paying for the peak number all night wastes money. Autoscale can increase capacity when a meaningful signal says demand is high, then reduce it when capacity is no longer needed.

Key ideas

• Scale out adds instances. Scale in removes them. Scale up changes an instance’s size and is not the same Azure Monitor autoscale action.
• A rule can use a metric, such as CPU or queue length, or a schedule. Each profile defines default, minimum, and maximum capacity so autoscale has safe boundaries.
• A supported resource must be able to start useful new instances. New instances need an image, configuration, network access, identity, and a health path before they can serve real traffic.
• With multiple rules, Azure Monitor can scale out when any scale-out condition is met and scale in only when all scale-in conditions are met. Review the exact rules rather than assuming they cancel each other symmetrically.

Northwind example

Northwind’s order-processing workers run in a VM scale set. When the receipt-processing queue stays above a tested threshold, autoscale adds workers up to a maximum. When the backlog is low for long enough, it removes workers but never goes below the minimum needed for normal operations. Each worker processes messages idempotently because a new worker or a retry can see work more than once.

Common confusion

• Autoscale does not repair a broken application, database, or dependency. More failing instances can create more cost and noise.
• Autoscale is not an alert, though it can use metrics and send notifications. An alert tells people; autoscale changes configured capacity.
• Autoscale does not work for every Azure resource or every hosting plan. Confirm support and limits for the target resource.
• Scale-in can interrupt work. Design graceful shutdown, durable state, and queue handling before enabling it.

Design checklist

Choose a signal that represents demand, set tested minimums and maximums, allow for instance startup time, protect state outside instances, and test both scale-out and scale-in. Monitor actual scaling events and costs, then tune the rules from evidence.

Related

virtual-machine-scale-set · app-service-plan · azure-monitor · azure-monitor-metrics · queue-storage · northwind-traders-case-study

Sources and re-audit

• Microsoft Learn — Overview of autoscale in Azure Monitor, checked 2026-09-16.