Availability sets vs availability zones vs scale sets: keeping VMs running

You have an application on virtual machines and it has to stay up when something underneath it fails. Azure offers three features for this: an availability set, availability zones and a virtual machine scale set. They overlap enough to look interchangeable in an exam question. The useful question is always the same: what failure does this protect me from?

The one-line difference

• An availability set spreads VMs across separate racks of hardware inside one datacentre.
• Availability zones spread VMs across separate datacentres within one region.
• A scale set manages a group of VMs from one configuration and adds or removes them as demand changes. It can also spread them across fault domains or zones.

Availability sets: separate hardware, one datacentre

An availability set is a logical grouping that tells Azure your VMs do the same job, so it shouldn’t let one hardware problem take them all down. Azure gives every VM in the set two labels:

• A fault domain: hardware that shares a power source and a network switch. A set has up to three.
• An update domain: a group that can be restarted together during planned maintenance. A set has up to twenty. Only one update domain is restarted at a time, and each gets 30 minutes to recover before maintenance moves on.

Both counts are fixed when you create the set. Managed disks follow the same idea: each VM’s disks are aligned with its fault domain.

With two or more VMs in a set, Microsoft’s SLA is 99.95%. The set itself costs nothing; you pay for the VMs. Because the VMs sit physically close together, VM-to-VM latency is lower than across zones.

What a set doesn’t do: it doesn’t protect you from an operating system or application failure, and Learn is explicit that it’s still exposed to shared infrastructure failures such as a datacentre-level network outage, which can hit several fault domains at once. Learn also now recommends Flexible scale sets as the first choice for high availability, with availability sets most useful in regions that don’t have zones.

Availability zones: separate datacentres, one region

An availability zone is a group of one or more physically separate datacentres within a region, with independent power, cooling and networking. Zones are typically several kilometres apart and usually within 100 km of each other, so they’re close enough for low-latency replication but far enough apart that a local outage shouldn’t reach more than one. Most regions that support zones have three.

Two terms matter:

• Zonal: you pin a resource to one zone you choose. A VM is zonal. It isn’t protected from that zone failing; for that you deploy copies in other zones and handle the failover yourself.
• Zone-redundant: the service spreads the resource across zones and fails over for you.

A resource that doesn’t use zones at all is nonzonal (or regional). Azure can place it in any zone, so an outage in any zone could affect it.

Learn’s guidance is that production workloads should use multiple zones where the region supports them. Zones don’t protect against a whole region going down; that needs a second region.

Scale sets: a managed, autoscaling group

A scale set creates and manages a group of load-balanced VMs from one configuration. Autoscale adds or removes instances in response to demand or on a schedule. The scale set has no charge of its own; you pay for the VMs, disks and networking it uses.

Scale sets come in two orchestration modes, and you choose at creation; it can’t be changed later:

• Flexible (recommended): manages standard Azure VMs, so the normal VM APIs, Azure Backup and Site Recovery work. You can mix VM sizes and combine Spot and regular instances, and attach existing VMs. Up to 1,000 instances.
• Uniform: builds identical instances from one profile and manages them as a group through the scale set’s own VM APIs. Those instances don’t work with Azure Backup or Site Recovery.

A scale set can spread instances across fault domains in a region, or across one, two or three zones. Learn’s comparison table gives 99.95% for instances spread across fault domains and 99.99% for instances spread across multiple zones. One more thing to note: Learn says a scale set on its own can’t protect you from a datacentre failure; you get that by deploying it across zones.

How they combine

• A VM goes in an availability set or in a zone, never both. Availability sets don’t support availability zones.
• Scale sets and zones combine well. A zone-spanning Flexible scale set gives you autoscale and zone resilience together, which is why Learn steers new designs that way.
• Add a load balancer. Learn suggests combining Azure Load Balancer with zones and scale sets for the most resilient application.

Exam traps

1. “An availability set protects against a datacentre outage.” It doesn’t. Its fault domains guard against rack-level hardware, power and switch failures inside one datacentre. If the scenario says a datacentre might fail, the answer is zones.
2. You can only put a VM in an availability set when you create it. To add an existing VM, move it to another set or take it out, you delete the VM (keeping its disks) and create it again.
3. Zonal isn’t zone-redundant. One VM in zone 1 goes down with zone 1. Resilience needs instances in at least two zones.
4. Zone numbers are logical. Zone 1 in your subscription isn’t necessarily the same physical datacentres as zone 1 in someone else’s; each subscription gets its own mapping.
5. Zones stay inside one region. Surviving a regional outage is a job for a second region, not for zones.

Pick it in five seconds

Go deeper

VM availability is covered in the AZ-104 study guide and, from the design side, the AZ-305 study guide, with the traps called out like these. Facts checked against Microsoft Learn on 9 October 2026.