Availability sets vs availability zones

An availability set spreads virtual machines across fault domains and update domains inside one datacenter, while availability zones spread them across physically separate datacenters in one region. The decision rule is to read the failure the scenario names: a rack, power or maintenance problem is covered by an availability set, the loss of a whole datacenter needs zones, and the loss of a whole region needs a second region, which neither option provides.

Decision table: which failure each option survives

The last row matters. Neither option protects against a crash or a bad deployment inside the guest; that needs load balancing, health checks and backup. See Azure Backup and Site Recovery for the recovery half of the story.

How an availability set works

An availability set is a logical grouping that tells Azure the VMs belong to one application. Azure assigns each VM a fault domain and an update domain.

• Fault domain: VMs that share a power source and network switch. A set supports up to 3 fault domains.
• Update domain: VMs that can be restarted together during planned maintenance. A set supports up to 20 update domains, and only one is restarted at a time. With five update domains and six VMs, the sixth VM shares a domain with the first.
• Fixed at creation: the domain counts cannot be changed after the set exists, and in practice a VM is placed in a set when it is created. Plan this before deployment.
• Cost and SLA: the set itself is free, and two or more VMs in a set meet the 99.95% VM SLA on Microsoft’s availability page.

Everything stays in one datacenter, so a datacenter-level network or power failure can still affect several fault domains. Microsoft says availability sets provide high availability but not the same resiliency as zones. Their one advantage is lower VM-to-VM latency, because the machines sit physically close.

How availability zones work

An availability zone is a group of one or more datacenters inside a region with independent power, cooling and networking. Most zone-enabled regions have three zones, though a few have more or are adding one in preview. The practical consequences:

• Zonal versus zone-redundant: a zonal resource, such as a VM, is pinned to the one zone you pick and gives no resilience alone. You get resilience by deploying separate resources in two or more zones and sending traffic to both. A zone-redundant service, such as zone-redundant storage, is spread across zones by the platform, which handles the failover.
• Nonzonal is the default risk: a VM with no zone selected can be placed in any zone, and you cannot see which. An outage in any zone can take it down.
• Zone numbers are per subscription: logical zone 1 in your subscription may be a different physical zone than logical zone 1 in another subscription.
• Network: zones are linked by a fast network (Microsoft targets round-trip latency under about 2 ms) and Azure does not charge for data transfer between zones in a region.
• Not every region has zones, and a service may support zones only in some SKUs. Check before designing.

For new deployments Microsoft recommends scale sets with flexible orchestration for high availability, which can themselves span zones. Availability sets remain useful in regions without zones, and they remain on the exam. The load balancer in front must also be zone-aware; see Azure load-balancing options and choosing an Azure compute service.

Worked example: a three-tier app with four requirements

A company runs a web tier, an application tier and a database on VMs in West Europe.

1. “Survive a host failure and monthly maintenance.” Two web VMs in an availability set behind a load balancer. They land in different fault and update domains, and the 99.95% SLA applies.
2. “Survive the loss of a datacenter.” Move to zones: web VM 1 in zone 1, VM 2 in zone 2, same for the app tier. Use a Standard load balancer, which supports zones. An availability set cannot be changed into this design; the VMs are redeployed into zones.
3. “Keep storage usable if a zone fails.” Zone-redundant storage; see storage redundancy for ZRS versus GRS.
4. “Keep running if the whole region fails.” Zones do not help. Add a second region with Site Recovery or an active-active design.

Each requirement adds exactly one layer, and the cheapest layer that satisfies the stated failure is the right answer.

Which exams test this

How exam questions are built around this

The scenario nearly always contains a failure word, and the options always contain both features. The constraint words that decide the answer:

• “Datacenter”, “building”, “power and cooling for a facility” point to zones.
• “Rack”, “host”, “planned maintenance”, “update domain”, “region does not support zones” point to an availability set.
• “Region” or “disaster” rules out both; look for a paired-region design.
• “Existing VM” is the trap. A set is chosen at creation, so a question about adding resilience to an already running VM usually expects a redeploy or a recreate from disks, not a checkbox.
• “Lowest latency between VMs” hints at an availability set or a single zone, not spreading across zones.
• “Least cost”: sets and zones themselves are free; you pay for the extra VMs either way. Cross-zone traffic is not charged.

Practice questions

Go deeper

• Availability options for Azure virtual machines, the comparison Microsoft publishes.
• Availability sets overview, for fault and update domain details.
• What are Azure availability zones?, including zonal versus zone-redundant.
• On this site: Azure Backup and Site Recovery, storage redundancy, and the AZ-104 cheat sheet.