Availability set vs availability zone: what each one survives
Both spread your VMs so one failure doesn't take the whole application down — but a set spreads them across racks inside one building, and a zone spreads them across separate buildings, and that difference is the whole point.
New to cloud? CAMPUX is a free, build-first course. Start here →
An availability set spreads your VMs across fault and update domains inside a single datacenter, so it survives a dead rack or a host maintenance reboot, at a 99.95% VM SLA. An availability zone spreads the same VMs across physically separate datacenters in the region, so it survives an entire datacenter going dark, at 99.99%. Zones are the stronger choice wherever the region has them.
That is the whole comparison in two sentences. The rest of this note is the part the one-line answers skip: what a fault domain and an update domain actually are, what a set still cannot cover, what the SLA gap costs you in real minutes of downtime a year, and the handful of cases where a set is still the right call. Microsoft's own wording is the tiebreaker — availability sets "provide high availability but don't offer the same level of resiliency as availability zones."
Two identical web servers behind a load balancer buys you nothing if Azure puts them on the same rack and that rack loses power. Availability sets and availability zones both exist to stop that — they take your VM instances and pull them apart onto independent hardware so a single fault can't reach all of them at once. The question a junior engineer gets wrong is how far apart. A set separates VMs within a single datacenter. A zone separates them across datacenters. Same instinct, very different blast radius.
What an availability set survives: the rack and the reboot
An availability set is a logical grouping. You put two or more VMs in it, and Azure spreads them across two things. The first is fault domains: groups of hardware that share a power source and a network switch. Put your VMs across up to three fault domains and a failed power supply or a dead top-of-rack switch takes out one domain, not all of them. The second is update domains: Azure reboots one update domain at a time during planned host maintenance, and a rebooted domain gets 30 minutes to recover before the next one goes. So when Microsoft patches the physical hosts underneath you, your instances don't all reboot together — some stay up and serve traffic while others cycle.
That is the entire scope of a set: hardware faults and maintenance reboots inside one datacenter. The VMs are close together on purpose, which gives you low VM-to-VM latency. But they share the building. A datacenter-level network outage, or a loss of power or cooling to the whole facility, hits every fault domain at once. A set does nothing for that.
Up to 3 fault domains (separate power and network) and up to 20 update domains (staggered reboots). Two or more VMs in a set meets Azure's 99.95% VM SLA. There is no charge for the set itself — you pay only for the VMs. The fault and update domain counts are fixed when you create the set and can't be changed after. It protects hardware and maintenance; it does not protect the operating system or your app from their own bugs.
What a zone survives: the whole datacenter going dark
An availability zone is a physically separate group of one or more datacenters within a region, each with its own independent power, cooling, and networking. Zones in a region sit kilometers apart — far enough that a flood, a fire, or a power event at one is unlikely to touch another, close enough (a target of roughly two milliseconds round-trip) that you can still run synchronous work across them. You place your VM instances in different zones — zone 1, zone 2, zone 3 — and when an entire datacenter loses power, the instances in the other zones keep serving. That is the failure a set can't cover and a zone can.
A set asks "what if a rack dies?" A zone asks "what if the building dies?" You pick based on which failure would cost you the outage.
Availability sets vs availability zones, side by side
Read the table by the row that matches the failure you are worried about. The two are not tiers of the same product — they separate your VMs at different distances, and every other difference falls out of that one.
| Availability set | Availability zone | |
|---|---|---|
| What it separates | VMs across racks inside one datacenter. | VMs across physically separate datacenters in the same region. |
| What it survives | A failed power supply, a dead top-of-rack switch, a planned host reboot. | All of that, plus the loss of power, cooling, or networking to a whole facility. |
| What it does not survive | A datacenter-level network outage, which can hit multiple fault domains at once. | A full-region outage. Zones are in-region redundancy only. |
| The unit you configure | Up to 3 fault domains (shared power source and network switch) and up to 20 update domains (restarted one at a time). Managed-disk fault domains are two or three depending on the region. | Three zones per supported region. You either pin a VM to a zone (zonal) or let the service spread it for you (zone-redundant). |
| Planned maintenance | One update domain restarts at a time, and a restarted domain gets 30 minutes to recover before the next one goes. | Microsoft aims to deploy updates to one availability zone at a time per region, so a multi-zone workload keeps serving. |
| Physical distance | Same building, deliberately close. | Typically several kilometers apart, usually within 100 km. |
| Latency between instances | Lower — the VMs sit in closer physical proximity. | Higher, but small: Microsoft targets a round trip of under roughly 2 ms between zones. |
| SLA, two or more VMs | 99.95% — about 4 hours 22 minutes of permitted downtime a year. | 99.99% — about 52 minutes a year. |
| Cost | No charge for the set. You pay only for the VM instances. | No price difference between a zonal and a nonzonal VM, and no charge for data transfer between zones in the same region. |
| Availability | Every region. Especially useful in regions with no zones. | Many regions, not all — and support varies by service, tier, and SKU. |
| Pick this when | The region has no zones; or the workload is chatty and you want the lowest VM-to-VM latency; or you need rack-and-reboot protection and nothing more. | Any production workload in a region that supports zones. Microsoft's guidance is direct: production workloads should be configured to use multiple availability zones if the region supports them. |
The SLA difference, and why it's not a rounding error
Both figures come from the Azure Virtual Machines SLA, and both require two or more instances — a single VM sits on a lower tier that depends on the disks attached to it. Two or more VMs in an availability set carry a 99.95% SLA. Spread those VMs across two or more availability zones and the SLA rises to 99.99%. That gap looks small on paper and is not small in downtime: 99.95% permits about 4 hours 22 minutes of allowed downtime a year, while 99.99% permits about 52 minutes. Microsoft's own guidance is blunt — availability sets provide high availability but don't offer the same resiliency as zones, because zone deployment puts your VMs in physically separate datacenters. You are buying protection against a strictly bigger failure, and the SLA reflects it.
Which one to reach for: availability zones vs availability sets
Where zones are available, they are the modern default for a production workload, and Microsoft says so directly: production should use multiple availability zones if the region supports them. Zones cover the datacenter-loss failure a set can't, for the same shape of deployment. Reach for an availability set when the region has no zones (not every region does), when you want rack-and-maintenance resilience with the lowest VM-to-VM latency, or when you're keeping instances deliberately close for a chatty workload. Reach for zones whenever you can and the outage of a whole datacenter is a cost you can't wear.
One caveat that trips people in the portal: zone support varies by service and by region. Not every Azure region offers zones, and not every service supports them the same way — some are zone-redundant, some are zonal, some need a particular tier or SKU. Check the region and the service before you design around zones, the same way you'd check whether a region versus a zone is the boundary you actually need. And if you're running more than a handful of instances, you'll likely stop hand-placing VMs into sets or zones at all and let a Virtual Machine Scale Set spread them across zones for you.
The takeaway
An availability set spreads VMs across fault and update domains inside one datacenter — it survives a dead rack and a maintenance reboot, at 99.95%. An availability zone spreads VMs across physically separate datacenters in a region — it survives a whole datacenter going dark, at 99.99%. Both spread instances; the difference is how far. So match the tool to the failure you can't afford: zones where the region supports them, a set when it doesn't, and a scale set to place the instances once there are more than a few. Get that mapping right and the resiliency takes care of itself.
Questions people also ask
What is the difference between an availability set and an availability zone?
An availability set spreads your VMs across fault and update domains inside one datacenter, so it survives a dead rack or a maintenance reboot and carries a 99.95% SLA. An availability zone spreads them across physically separate datacenters in a region, so it survives a whole datacenter going dark and carries a 99.99% SLA.
What is the difference between a fault domain and an update domain?
A fault domain is a group of hardware that shares one power source and one network switch, so spreading VMs across fault domains protects you from a rack-level hardware failure. An update domain is a group Azure reboots together during planned host maintenance, one domain at a time, so your instances never all cycle at once.
Do I need availability zones?
Where the region supports them, you want zones for any production workload, because they cover the loss of an entire datacenter that a set cannot. You reach for an availability set instead when the region has no zones, or when you want rack-and-reboot resilience with the lowest VM-to-VM latency for a chatty workload.
Does an availability set protect against a datacenter outage?
No. A set keeps your VMs inside one datacenter, so a facility-wide loss of power, cooling, or networking hits every fault domain at once and takes down all of your instances. To survive a datacenter outage you place the instances in different availability zones, which sit in physically separate datacenters within the region.
Is an availability zone the same as a data center?
Not quite. An availability zone is a logical grouping of one or more physically separate datacenters within a region, so one zone can be a single datacenter or several of them. Each zone has its own power, cooling, and networking, which is what makes it independent of the others. A single datacenter on its own offers no such separation, and that is exactly why an availability set — which keeps every VM inside one datacenter — cannot survive the loss of the building.
Do availability zones replace availability sets?
In practice they are the better default, and Microsoft says so: production workloads should be configured to use multiple availability zones if the region supports them, and availability sets provide high availability without the same level of resiliency as zones. Availability sets are still the answer in regions that have no zones. For a group of similar VMs, Microsoft recommends Virtual Machine Scale Sets in Flexible orchestration mode instead of hand-placing instances at all.