Azure VMs, Availability Sets and Scale Sets
A single Azure virtual machine gives you one instance with full OS control, an availability set spreads a handful of hand-built VMs across fault domains, and a Virtual Machine Scale Set (VMSS) manages a group of VMs that can grow and shrink automatically. The decision rule is to ask whether the number of instances must change on its own: if yes, use a scale set; if the VMs are fixed, different from each other and long-lived, use individual VMs placed across availability zones or, where zones do not exist, in an availability set.
Three ways to run the same workload
| Need | Single VM | Availability set | Scale set (Flexible) |
|---|---|---|---|
| One server, no redundancy | Fits | Pointless with one VM | Overkill |
| Two or more VMs that must survive host failures | No | Fits, in one datacenter | Fits |
| Survive loss of a datacenter | No | No | Fits, with zones |
| Instance count follows demand | No | No | Yes (autoscale) |
| Each VM configured differently | Yes | Yes | Possible in Flexible mode |
| Extra charge for the grouping | n/a | None | None |
Both the grouping features are free: you pay for the VMs, disks and network resources, not for the availability set or scale set itself. For the failure model behind the middle and right columns, see availability sets vs availability zones.
Availability sets in one paragraph
An availability set is a logical grouping that tells Azure to keep VMs from sharing the same hardware failure. It supports up to 3 fault domains (shared power and network switch) and up to 20 update domains (groups restarted one at a time during planned maintenance), and those settings cannot be changed after creation. Two or more VMs in a set qualify for the 99.95% VM SLA. Microsoft’s availability set overview now recommends scale sets with Flexible orchestration for high availability with the widest range of features, and positions availability sets as useful in regions without availability zones. Neither protects you from an operating system or application failure inside the VM.
Scale sets and the two orchestration modes
A scale set is a logical grouping of platform-managed VMs created from one configuration, with autoscaling by metrics or schedule, instance repair, and load balancer integration. Azure Load Balancer gives layer-4 distribution and Application Gateway gives layer-7 distribution and TLS termination. The orchestration mode is chosen at creation and cannot be changed later. See the scale sets overview and the orchestration modes page.
| Aspect | Flexible (recommended) | Uniform |
|---|---|---|
| What the instances are | Standard Azure VMs, managed with the normal VM APIs | Scale-set-specific VMs, managed with the VMSS VM APIs |
| Instance mix | Different sizes, and Spot with on-demand together (for most VM sizes) | Identical instances; all Spot or all regular |
| Autoscale | Yes | Yes |
| Per-instance RBAC, tagging, Azure Backup, Site Recovery | Yes | Not compatible at instance level, per Microsoft’s description |
| Automatic OS image upgrades | Not supported | Supported |
| Default outbound internet access | None; configure explicit outbound | Yes |
| Fault domain spread | Max spreading or fixed 2 to 3 domains; update domains deprecated | Update domains up to 5 |
| Availability zones | Spread across 1, 2 or 3 | Spread across 1, 2 or 3 |
Flexible orchestration keeps fault domain guarantees up to 1,000 instances and publishes an SLA of 99.95% for instances spread across fault domains and 99.99% for instances spread across multiple zones. A scale set on its own does not protect against a datacenter failure; deploying it across availability zones does. Treat Uniform as the older model you still meet in exam scenarios (Microsoft’s comparison table lists Service Fabric and AKS as supported with Uniform and not with Flexible), and Flexible as the default answer for a new design.
Worked example: a web tier that follows the working day
A company runs an internal web application that needs two instances at night and up to ten at the start of the business day.
- Create a Flexible scale set and spread instances across three availability zones. This covers the “survive a datacenter” requirement; the scale set alone would not.
- Set instance limits: minimum 2, maximum 10, default 2. A scale-out rule adds instances when average CPU stays above a threshold, and a matching scale-in rule removes them. A schedule profile can raise the minimum before 08:00 so capacity exists before the load arrives.
- Put a Standard-SKU load balancer in front for layer-4 distribution, or Application Gateway if the requirement says URL-based routing or TLS termination. Choosing among these is covered in Azure load balancing options.
- Because Flexible instances have no default outbound access, add explicit outbound connectivity (for example a NAT gateway or load balancer outbound rule) so the VMs can reach package repositories.
- Back up through the VM tooling, which works with Flexible instances; see Azure Backup and Site Recovery.
When this application is a plain web app with no OS dependencies, choosing an Azure compute service will often point to App Service instead, and a question that says “OS-level control” or “lift and shift” points back to VMs.
Which exams test this
| Exam | How the topic appears | Where on this site |
|---|---|---|
| AZ-900 | Describe Azure architecture and services (35 to 40%): VM options including VMs, scale sets, availability sets and Azure Virtual Desktop, plus the resources a VM needs | Architecture and services explained |
| AZ-104 | Deploy and manage compute resources (20 to 25%): create VMs, manage sizes and disks, deploy to availability zones and sets, deploy and configure scale sets | Compute resources explained |
| AZ-305 | Design infrastructure solutions (30 to 35%): recommend a virtual machine-based solution; high availability for compute (business continuity domain) | Infrastructure explained |
| AZ-802 | Manage Windows Server VMs in Azure: capacity including resizing and scale sets, availability sets and zones | Virtual machines explained |
AZ-900 and AZ-104 outlines name “Virtual Machine Scale Sets” explicitly. The AZ-305 outline does not name scale sets; it asks you to recommend a VM-based solution and a high-availability design for compute.
How exam questions are built around this
- “Automatically add instances.” Only a scale set autoscales. Availability sets and zones add resilience, not elasticity.
- “Datacenter failure” versus “rack failure”. Zones for the first; availability set or fault domains for the second. A scale set without zones still lives in one datacenter.
- “Different VM sizes in one group”. Points to Flexible orchestration.
- “Existing VM, join it to the group”. Flexible supports adding an existing VM; Uniform does not.
- Changing the mode. Not possible after creation; the answer is a new scale set.
- Fault domains. Availability set maximum is 3 fault domains and 20 update domains; do not apply those limits to a scale set.
Practice questions
Question 1. An application runs on VMs and the number of instances must increase automatically when average CPU stays high and decrease in the evening. The VMs must be spread over three availability zones. What should you deploy?
- A. An availability set with three VMs
- B. A Virtual Machine Scale Set spread across three zones with autoscale rules
- C. Three standalone VMs, one in each zone
- D. One VM resized to a larger size
Show answer
Answer: B
A Virtual Machine Scale Set supports autoscale by metrics or schedule and can distribute instances across availability zones. An availability set provides fault and update domains inside one datacenter and has no autoscale. Three standalone VMs in zones give resilience but do not scale automatically. A larger VM size is vertical scaling and has no zone spread.
Question 2. You are designing a new scale set that must mix several VM sizes and combine Spot and on-demand instances. Which orchestration mode should you use, and when can the mode be changed?
- A. Uniform; it can be changed to Flexible later
- B. Uniform; the mode can never be changed
- C. Flexible; the mode is fixed at creation and cannot be changed later
- D. Flexible; it can be switched to Uniform at any time
Show answer
Answer: C
Flexible orchestration allows different VM sizes and a mix of Spot and on-demand instances for most VM sizes, and it is the mode Microsoft recommends. Uniform instances are identical and must be all Spot or all regular. The orchestration mode is set at creation and cannot be changed, so a wrong choice means building a new scale set.
Go deeper
- Azure Virtual Machine Scale Sets overview (Microsoft Learn)
- Orchestration modes for Virtual Machine Scale Sets (Microsoft Learn)
- Availability sets overview (Microsoft Learn)
- Related guide: the AZ-104 study plan.