One definition, several virtual machines
At opening time, forty stores send order work into the same queue. One worker falls behind; Ada adds another. By lunchtime the queue is empty, but the extra workers are still running. A scale set helps manage that changing fleet. It needs boundaries and a useful signal, not just an instruction to add machines whenever something looks busy. Let the waiting orders tell you what the capacity change achieved.
An AKS node pool commonly uses a VM scale set for its worker machines. App Service also runs on worker VM instances, but it is a managed platform with its own scaling interface; you do not create or operate its workers as your own VMSS. This distinction matters: the same idea of adding capacity appears in both products, but ownership of the guest OS and fleet operations differs.
Autoscale — on a metric, on a clock, or both
Two plain words before the rules. A queue is a waiting line of work: the shop drops each new order into it and moves on. A worker is a program, here on its own VM, that takes the next order off the line and processes it. More workers empty the line faster. A scale set is how you decide how many worker VMs exist at any moment.
A scale set's count stays fixed until you change it or configure autoscale. A metric rule might watch CPU, a storage queue's message count, or another supported signal. When it crosses a threshold for a configured period, Azure can add VMs; a separate rule can remove them as load falls. The new VM still takes time to provision and become healthy, so autoscale cannot instantly erase a backlog. Set a minimum that meets the application's availability needs, a maximum that respects quota and budget, and a safe default if the metric cannot be read.
A schedule adjusts the capacity profile before a known busy period, such as a weekday rush. Metric rules can then respond to unexpected demand within that profile's bounds. In the order-worker example, use a schedule to raise the minimum before a predictable sale, and a queue-length rule for the unplanned extra orders. Test scale-out time, queue drain rate, scale-in behavior, and the bill; the numbers below are a teaching example, not a guarantee of how many VMs any workload needs.1
Scale out on the metric; set a floor and a ceiling so it stays sane.
Play it through
Three minutes. Watch an order-processing fleet with a fixed count, add a queue-length rule, then set minimum and maximum capacity. The counts illustrate a decision; your own workload needs measurement and testing.
Orchestration modes — Flexible and Uniform
Orchestration mode describes how Azure manages the instances. In Uniform mode, instances follow a common VM model and are managed mainly through scale-set controls. In Flexible mode, instances can use standard VM management APIs and offer more control over individual machines and placement. Both modes can span zones; the choice depends on the needed management features and limits.
Microsoft recommends Flexible for most new workloads. Uniform still supports some features and deployment patterns that require its common-instance model, including many AKS node pools. Choose the mode when creating the scale set; changing it later requires a migration. Check the current feature matrix and instance limits for your region and design, rather than memorising one maximum.2 The scale-set blog note gives more examples.
| Mode | Instances | Best for | Standing |
|---|---|---|---|
| Flexible | Standard VM management APIs; individual VM control | Most new workloads where VM-level management matters | Microsoft's general recommendation; verify current limits |
| Uniform | Common scale-set VM model | Features and workloads that need Uniform, including many AKS node pools | Check its current feature support and limits |
Rolling upgrades — changing the fleet without dropping it
When the VM model or OS image changes, replacing every instance at once risks taking the whole service offline. A rolling upgrade updates a limited batch, checks its health, then continues. Keep enough healthy instances to serve traffic while one batch changes. This reduces disruption, but does not promise that users will never see an error; test the app, traffic routing, health signal, and capacity under a failed batch.
A useful health probe tests whether the application can serve real work, not merely whether the VM booted. Configure the applicable upgrade policy and health reporting for your orchestration mode. Automatic OS-image upgrades are a separate feature from guest OS patching; their support and restrictions differ by mode, so verify the current Microsoft documentation before enabling them. Monitor a rollout and have a recovery plan for a bad image.
If Campux had to operate its own order workers
Imagine the reconciliation software requires VM-level control. Campux puts the order workers in a scale set and measures how quickly one worker drains messages. It starts with a minimum of two for this example, sets a maximum based on budget and quota, and watches the order queue. A schedule raises the minimum before a known sale; a queue rule requests more workers when the measured backlog grows. Workers need enough time to start and become healthy, so the team tests the rush rather than assuming the queue disappears immediately.
For an image change, the team updates a small batch and checks whether those workers process real orders before continuing. It also keeps guest OS patching, backups, alerts, and recovery ownership. App Service would be a better fit for a simple web frontend without VM-specific needs; this scale set is justified only by the worker's requirement for VM control.
Where the scale set sits on the spectrum
A scale set remains IaaS. It helps add, remove, and manage VM instances together, but your team still owns the guest OS, image, application, monitoring, backup, and recovery plan. Use it when the workload needs VM-level control and a fleet that changes size. If you only need a scalable web app, compare App Service or another managed service first.
Part 11f compares this choice with App Service, Container Apps, Functions, and other options. A scale set can have zero VM instances in some configurations, but zero workers cannot process a queue until capacity starts. Other resources may still cost money, and the behavior is not the same as a consumption Function. Choose the product based on the job's start-time, control, and availability needs.
Rolling out a new worker image
A new worker image must reach forty VMs. First confirm the image, backup, and recovery path. Then update a small batch and inspect application health and actual queue processing before moving on. Keep enough healthy workers for the backlog. If the batch fails, stop the rollout and recover those workers. This is a controlled release, not a promise of invisible updates.
Size workers from supplied evidence
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Queue: 1,200 orders Measured training capacity: 100 orders/worker/minute Target drain time: 4 minutes Current workers: 1; training upper bound: 4
Calculate the worker count assuming no new arrivals and constant throughput.
Choose a lower and upper bound and name why that simple model may fail.
Write the queue-age observation you would check after scaling.
Check your reasoning after you finish
1,200 ÷ (100 × 4) = 3 workers in the simplified model. Arrival rate, startup time and downstream limits can change it. Set bounds from the workload and budget, then check oldest-message age and processing failures.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. A scale set manages VM instances together. A metric-based autoscale rule changes the instance count when the measured signal meets its threshold. Resizing one VM changes its capacity, not the number of serving copies. An availability set helps place VMs across hardware and update groups but does not itself add and remove them. A disk is storage, not compute capacity.
A. Microsoft recommends Flexible for most new scale sets because its instances can use standard VM management APIs and individual placement. Uniform uses a common scale-set VM model and remains useful when a required feature or deployment pattern calls for it. Check the current feature and scale limits before choosing; changing mode later requires a migration.
Autoscale rules, controlled batches, and AKS worker nodes are the three true statements. A scale set remains IaaS, so guest OS patching is still your responsibility. Some configurations can have zero VM instances, but no worker processes orders until capacity starts; zero VM compute also does not mean every attached resource is free. App Service has its own managed worker scaling, which you do not operate as your own VMSS.
SCALE SET — web fleet
1. Flexible mode, spread across three availability zones.
2. Autoscale: schedule floor for peak + CPU rules on top.
3. Upgrades: replace all instances at once for speed.
4. Health probe gates instance health after replacement.
Line three. Replacing every serving instance at once removes the healthy capacity you need during a failed release. Use a supported rolling policy, small batches, application health checks, and enough remaining capacity. The mode, zone placement, and layered autoscale can be sensible, but verify the exact feature combination for the selected orchestration mode. A health probe helps only when it tests meaningful app behavior and the rollout responds to failures.
Consider the consequence. On a good release, all-at-once looks faster and gets praised. Then one bad image ships, every instance is replaced with it simultaneously, the health probe marks them all unhealthy — and the service is fully down with no healthy instances to fall back to. The batched rollout that seemed slower is what would have caught the same bad image after one batch. Speed bought by removing the safety net is a debt paid in a full outage.
Name the two separate risks. A very high maximum can turn a bad metric or traffic flood into a large bill and may run into quota. A minimum of zero conflicts with this service's explicit requirement for two ready copies. Zero is possible for some batch designs, but it is not suitable for this always-ready web service.
Set both bounds from evidence. The maximum should be the most capacity the workload could sanely need plus headroom — high enough to absorb a real peak, low enough that a runaway is capped before it becomes a budget incident. The minimum should be the floor that serves normal load without a cold scramble, raised on a schedule for known peaks like November. Bounded autoscale is elastic; unbounded autoscale is just a faster way to an outage or an invoice.
Tune the direction of the rules too. Scale out quickly so a real spike is met before users suffer, and scale in slowly so a brief dip does not tear down capacity you are about to need again. "Elastic within sane bounds, aggressive out and gentle in" is the shape of an autoscale rule you can defend — which is the same evidence-and-bounds discipline every sizing decision in this track has come back to.
Grant the goal, then question the rung. Autoscale is a reasonable thing to want, and a scale set genuinely provides it. But a scale set is IaaS: choosing it means the team signs up for the whole Part D chore list — OS patching, images, agents, health — now across a fleet, and then has to run their containers on top of that by hand. The question is whether autoscale is worth re-acquiring all the ownership the containers were meant to shed.
Compare the platforms that run containers. Azure Container Apps can scale a suitable service with less infrastructure management. AKS fits when the team needs Kubernetes control, but the team still has node and cluster responsibilities; it is not hands-off. Compare their startup, scaling, networking, and operations needs before choosing either. A raw VMSS makes sense only if the containers require VM-level control the managed options cannot provide.
Reserve the scale set for its real case. A scale set of VMs is right when you need raw virtual machines that flex — a workload that genuinely requires OS-level control and also elasticity. Running containers is usually not that case. So reason out loud: "You want autoscale, you already have containers, and there are rungs that give you both without a VM fleet — price Container Apps and AKS before we sign up to operate machines." That is Part 11f's decision, arriving one part early.
Five things worth carrying out of Part E
- A scale set manages VM instances together and can change their count. AKS node pools commonly use it; App Service's managed worker scaling is a separate interface.
- Autoscale runs on a metric, a schedule, or both — a schedule sets the baseline for known patterns, metric rules absorb the surprises. Always bound the range.
- Flexible is Microsoft's general starting point; Uniform has its own feature set. Check current capabilities and limits for your design, and plan a migration if you later need a different mode.
- Rolling upgrades can limit changes to a batch and use health signals to stop a bad rollout. Keep enough healthy capacity and a recovery plan; zero downtime is not automatic.
- A scale set remains IaaS: guest OS, app, and recovery remain your responsibility. Zero VM instances is possible in some configurations, but startup takes time and other resources may still bill.
- Microsoft's autoscale overview explains metric rules, schedules, and delay. Azure Monitor's metric examples include Storage and Service Bus queue length for VM scale sets. ↩
- Microsoft's orchestration-modes guide compares Flexible and Uniform. Recheck its feature table and limits before choosing a mode; those details change. ↩
Explain how a scale set changes its VM count, bounds autoscale, and checks a rollout's health.
Play the lesson above to stamp this class.