One image, many machines, managed as a group
A virtual machine scale set is the managed fleet from the hub: a group of identical VMs, all built from the same image and configuration, that you create and operate as a single object. Instead of provisioning ten machines by hand and hoping they match, you define one and say "give me ten of these," and the scale set stamps them out identically. It is the elasticity Part D's single VM could not offer — the number of instances is a property you can change, by hand, on a metric, or on a clock, without touching any individual machine.
Scale sets are also the quiet foundation of rungs you have already used. An App Service plan scales out across instances that are, underneath, a scale set; an AKS node pool from Class Twenty-Seven is a scale set of worker nodes. So this part is not an exotic corner — it is the machinery that makes "add more instances" real everywhere on the spectrum. When you understand the scale set directly, you understand what App Service and AKS are doing for you when they scale out on your behalf.
Autoscale — on a metric, on a clock, or both
The point of a scale set is that the instance count moves itself. Metric-based autoscale watches a signal — CPU across the fleet, a queue depth, a custom metric — and adds instances when it crosses a threshold, removes them when it falls back. This is elasticity reacting to real demand: the fleet grows because the machines are actually busy and shrinks when the crowd leaves, so you pay for capacity roughly in proportion to load. Sensible rules scale out aggressively and scale in gently, and set a minimum and maximum so a runaway metric cannot take the fleet to zero or to bankruptcy.
Schedule-based autoscale moves the count by the clock instead: more instances during business hours, fewer overnight, a larger floor across a known peak season. The two combine — a schedule sets the baseline for a predictable pattern, and metric rules handle the surprises on top. For Campux's shape, a November schedule raises the floor for the season while CPU rules absorb the daily spikes within it. The discipline is the same as every sizing decision so far: let evidence and known patterns set the numbers, not fear, and always bound the range so autoscale is elastic, not unlimited.1
Scale out on the metric; set a floor and a ceiling so it stays sane.
Orchestration modes — Flexible and Uniform
A scale set runs in one of two orchestration modes, and the choice shapes what the fleet can do. Uniform is the original mode: every instance is identical, managed as a faceless group optimised for large-scale, stateless, all-the-same workloads. It scales to very high instance counts and is what you picture when you imagine a thousand identical web front-ends. Flexible is the newer, now-default mode: it manages VMs with more of the individuality of standalone machines — you can mix sizes, spread explicitly across availability zones, and treat instances more like the VMs of Part D while still managing them as a set.
The practical guidance is short. Flexible is the modern default for most workloads because it combines scale-set elasticity with the flexibility and zone-spreading of ordinary VMs; Uniform remains for very large, strictly-identical, stateless fleets that need its scale and its Uniform-only features. Knowing both exist — and that Flexible is where new designs generally start — is enough to avoid the two mistakes: defaulting to Uniform out of habit, or assuming a scale set forces every instance to be interchangeable when Flexible deliberately loosens that. The scale-set blog note on this site walks the modes with concrete examples.
| Mode | Instances | Best for | Standing |
|---|---|---|---|
| Flexible | Can mix sizes; VM-like individuality; explicit zone spread | Most workloads, including mixed and zone-resilient fleets | Modern default |
| Uniform | Strictly identical, managed as a faceless group | Very large, stateless, all-identical fleets | Original; specific cases |
Rolling upgrades — changing the fleet without dropping it
When the image changes — a new application version, a patched OS — a scale set does not have to replace every instance at once, which would take the whole fleet down together. A rolling upgrade replaces instances in batches: a fraction at a time, pausing between batches, checking a health signal before moving on. At any moment most of the fleet is still serving, so the upgrade is invisible to users, and if a batch comes up unhealthy the rollout can stop before it has touched the rest. This is the Deployment rolling update from Class Twenty-Seven, one layer down at the raw-VM level.
The safety depends on a real health probe: the upgrade only advances when the newly-replaced instances report healthy, so a broken image stalls the rollout instead of propagating. You set the batch size and the pause, trading speed against caution — small batches and longer pauses for a risky change, larger batches for a routine one. Automatic OS-image upgrades can ride the same mechanism, keeping the fleet patched in the background without a maintenance window. The whole feature exists so that "update the fleet" is never a synonym for "take the fleet down," which on the single VM of Part D it inevitably was.
If the storefront had needed VMs — the fleet Campux did not build
Campux's storefront lives on App Service, and that was the right call — but it is worth walking the fleet it would have been on raw compute, because App Service is running exactly this underneath. In the VM version, the storefront is a Flexible-mode scale set spread across availability zones, built from one hardened image. A schedule raises the instance floor for the November season, and CPU autoscale rules add instances on the daily spikes within it and remove them overnight — the Class Two arithmetic, spent directly on machines.
Releases go out as rolling upgrades: a new image rolls across the fleet a batch at a time, gated on a health probe, so the storefront never drops to zero and a bad build stalls instead of spreading. Read that paragraph back and it is a description of what App Service's Standard plan did for Campux in one checkbox — which is the lesson. The scale set is the machinery; App Service is that machinery with the chores removed. Campux stayed on App Service precisely because it did not need to operate the fleet by hand — but now you can see the fleet it was standing on.
Where the scale set sits on the spectrum
A scale set is still IaaS: it multiplies the machine but not the chores. Every responsibility from Part D — the OS, the image, patching, the agents, the health of the app — is still yours, now across a fleet instead of a single box. What the scale set adds is elasticity and safe fleet-wide operations, not relief from ownership. That is the honest place it occupies: a rung up from a lone VM in capability, on exactly the same rung in chore-count. You reach for it when you need real virtual machines that flex — full OS control the workload genuinely requires, plus the ability to grow and shrink.
Which is precisely the tension the final part resolves. If you need elasticity but not the OS control, App Service or Container Apps give you the flexing without the fleet to operate; if you need containers orchestrated at scale, AKS is standing on scale sets already; if the work is bursty and event-driven, Functions scales to zero in a way no VM fleet can. Part 11f puts the scale set beside all of them and gives you the single question that decides between them — so you choose a fleet of VMs because a requirement demanded raw machines, not because "it scales" sounded like enough.
Patching a fleet without a maintenance window
A security patch needs to reach forty identical VMs. The old way was a weekend maintenance window and a long night. Because the fleet is a scale set, you update the image and let a rolling upgrade replace instances a batch at a time, gated on a health probe — most of the fleet serves throughout, and a bad batch stalls the rollout instead of taking the service down. The patch lands during business hours and nobody notices, because "update the fleet" stopped meaning "take the fleet offline."
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 identical VMs as one elastic group, and metric-based autoscale is exactly the feature that grows and shrinks the instance count on a signal like fleet CPU. A single VM cannot add instances at all — resizing changes one machine's size, not the number of machines. An availability set spreads risk but does not autoscale; it is about resilience, not elasticity, and its VMs are managed individually. D is storage, unrelated to scaling compute. The tell is "automatically adds and removes instances on a metric": that is the scale set plus an autoscale rule.
A. Flexible is the newer, now-default mode: it gives instances more of the individuality of standalone VMs — mixed sizes, explicit zone spread — while still managing them as an elastic set, which suits most workloads. Uniform is the original mode, still correct for very large, strictly-identical, stateless fleets, but not the default you should reach for first. C is a resilience construct, not an orchestration mode. D is a Functions billing plan, borrowed here as a distractor. The point is to know both real modes exist and that new designs generally start on Flexible unless a Uniform-specific need appears.
Metric-or-schedule autoscale, batched rolling upgrades, and the scale set under App Service and AKS. Those three place the feature correctly. The two rejects are the IaaS illusions: a scale set is still IaaS, so patching the guest OS across the fleet remains your chore — it multiplies the machine, not the responsibility. And it does not scale to zero the serverless way; even at its minimum it runs and bills whatever floor you set. Believing either is how a "cheap, hands-off" fleet turns into an always-on bill with unpatched machines on it.
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 all instances at once throws away the entire point of a rolling upgrade — it takes the whole fleet down together, and if the new image is broken, there is nothing left serving and nothing to stall the rollout against. The correct setting is a rolling upgrade in batches with a pause, so most of the fleet serves throughout and a bad batch halts before it spreads. Lines one, two and four are exactly right: zone-spread Flexible mode, layered autoscale, and a health probe — which line three's all-at-once replacement renders useless, since there is no "next batch" to gate.
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 failures. An effectively unlimited maximum means a runaway metric — a traffic flood, a stuck loop, an attack — can scale the fleet, and the bill, without any ceiling to stop it; "never run out of capacity" is also "never stop spending." A missing minimum means the fleet can scale in below what the baseline actually needs, so the first spike after a quiet period hits an under-provisioned fleet and users feel the lag while it catches up. The teammate protected one edge and left both open.
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.
Point at the lighter rungs that already autoscale. Since the workload is already containerised, the fitting rungs are the ones built to run containers elastically without a VM fleet to operate: Azure Container Apps for a straightforward scale-to-demand (and even to zero) serverless container platform, or AKS from Class Twenty-Seven when they need full Kubernetes orchestration. Both give the autoscale they asked for while keeping the OS chores off their plate — which is the entire reason to have containerised in the first place.
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 — let's 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 is many identical VMs from one image, managed as one elastic resource. The same object underpins App Service scale-out and AKS node pools.
- 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 the modern default mode (VM-like instances, zone spread); Uniform suits very large, strictly-identical, stateless fleets.
- Rolling upgrades replace instances in batches, gated on a health probe, so a fleet update is never a fleet outage — and a bad image stalls instead of spreading.
- A scale set multiplies the machine, not the chores. It is still IaaS: patching and OS ownership remain yours, and it does not scale to zero.
- Autoscale reacts on a delay — it takes a little time to notice a metric cross a threshold, provision new instances, and have them start serving — so a truly instantaneous spike can still cause a brief stretch of strain before capacity arrives. This is why a schedule is valuable for predictable peaks: you raise the floor before the crowd rather than chasing it after. Treat metric autoscale as excellent for sustained load changes and imperfect for knife-edge spikes; combine it with a schedule and generous scale-out rules where the timing is known. ↩
- The two orchestration modes have accumulated feature differences over time, and Flexible was not always the default — older material will describe Uniform as the norm. Microsoft has steadily moved recommendation toward Flexible for general use, but specific capabilities occasionally live in one mode and not the other, so if a design depends on a particular feature, confirm which mode currently supports it rather than assuming parity. The durable lesson is that two modes exist and Flexible is the modern starting point; the exact feature matrix is worth re-checking. ↩