9.1 Compute High Availability: Availability Sets & Availability Zones

Why This Topic Matters

Domain 3 (Design business continuity solutions, 15-20% of AZ-305) devotes an entire official subgroup to high availability, and compute HA is the subgroup's first and most heavily tested cluster. Nearly every AZ-305 scenario question about VM resilience reduces to one design decision: Availability Set or Availability Zone — and how many instances, in how many zones? Getting the underlying mechanics wrong (fault domain vs. update domain, which SLA applies, whether a single VM is protected) is one of the most common ways candidates lose points on otherwise-straightforward infrastructure questions.

Core Terms and Rules

An Availability Set is a logical grouping of VMs that Azure spreads across isolated physical infrastructure within a single datacenter. Each set has two independent dimensions:

• Fault domains (FDs) — groups of VMs that share a common power source and network switch. Each Availability Set can have up to 3 fault domains (exact max varies slightly by region). Placing VMs across fault domains means a rack-level power or network failure doesn't take down every instance at once. VMs are also aligned to disk fault domains (2 or 3 per region, depending on the region) so a VM's attached managed disks fail over consistently with its compute.
• Update domains (UDs) — groups of VMs and underlying hardware that Azure can reboot together during planned maintenance. Each Availability Set can have up to 20 update domains. Azure only restarts one update domain at a time, and a restarted update domain gets 30 minutes to recover before the next one starts. If you have more VMs than update domains (e.g., 7 VMs in a 5-UD set), Azure wraps around — the 6th VM shares a UD with the 1st, the 7th with the 2nd, and so on.

Using 2 or more VMs in an Availability Set is what qualifies you for the 99.95% Azure SLA for VM availability — a single VM in a set (or with no redundancy construct at all, just on premium SSD) does not reach that bar.

An Availability Zone is a physically separate group of one or more datacenters within an Azure region, each with its own independent power, cooling, and network. Every region that supports zones has 3 Availability Zones. Zones are usually within about 100 km of each other, and Microsoft targets less than 2 milliseconds round-trip latency on the inter-zone network — close enough that most workloads see no meaningful performance penalty from spreading across zones, but far enough apart that a single flood, fire, or power-grid event is very unlikely to take out more than one zone.

Critically, a VM is what Microsoft calls a zonal resource: when you deploy a VM into a zone, that one instance lives in that one zone only. Azure does not automatically replicate a single VM's redundancy across zones for you. To get zone protection you must deploy separate VM instances into 2 or more different zones yourself (typically behind a Standard Load Balancer) — this combination is called being zone-resilient. Do that, and your VM tier qualifies for the 99.99% SLA, the highest availability tier Microsoft publishes for IaaS compute.

Comparing the Two Options

Exam Scenarios

Scenario 1: A company deploys a two-tier application to East US 2 (an Availability-Zone region) and needs the highest published Azure SLA for its web tier VMs at no extra licensing cost. Design decision: deploy at least 2 VM instances, one per zone, across 2 or 3 zones, behind a Standard Load Balancer — this reaches 99.99%, not 99.95%.

Scenario 2: The same company must also deploy to a region that does not support Availability Zones. Design decision: fall back to an Availability Set with 2+ VMs spread across the maximum fault domains — this is the only way to reach an SLA above the single-instance baseline in that region.

Scenario 3: A candidate deploys a single VM into "Zone 1" and assumes it is now protected against a regional datacenter outage. Trap: a lone zonal VM is exactly as exposed as before — zone resiliency requires multiple instances across multiple zones, not just placement in a zone.

Takeaways

• Fault domains isolate shared hardware (power/network); update domains isolate planned maintenance timing — they solve different problems and both apply only within Availability Sets.
• Memorize the SLA pairing: 99.95% for 2+ VMs in an Availability Set (or across fault domains generally), 99.99% for 2+ VMs across Availability Zones.
• Availability Zones are the default recommendation whenever the target region supports them; reach for Availability Sets only as the regional fallback.
• A single VM instance, regardless of which construct it sits in, never independently reaches the multi-instance SLA — AZ-305 scenario questions frequently test whether you notice a "single VM" detail that breaks an otherwise-plausible answer.