Availability set or 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 →
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.
The SLA difference, and why it's not a rounding error
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
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.