Azure Availability Set vs Availability Zone:
What's the Difference?
Both promise the same thing — keep your application running when something underneath it fails. But "something" means very different things at each scale. An availability set protects you from a rack losing power. An availability zone protects you from the entire datacenter that rack sits in going dark. Confusing the two, or assuming one subsumes the other, is how "highly available" architectures turn out not to be.
Every Azure high-availability design eventually asks the same question: what, specifically, are we protecting this workload from? A power supply failing in one rack is a different event from a fire or flood taking out an entire datacenter, and Azure gives you two distinct, purpose-built constructs to guard against each. An Availability Set is a logical grouping that spreads your VMs across different physical racks — different power sources, different network switches — inside a single datacenter, so a hardware fault in one rack doesn't take down every instance of your application. An Availability Zone operates at a much larger scale: each zone is one or more physically separate datacenters within a region, each with its own independent power, cooling, and networking, so an event that takes out an entire datacenter — not just a rack — still leaves your application running in another zone. Both exist to eliminate single points of failure. They just draw the boundary of "single point" at completely different sizes, and that size difference is what determines everything else: the SLA you get, the latency between your VMs, which regions support the option at all, and how you should actually design around each one.
Before the terminology, the one idea that makes everything else make sense: both constructs exist to shrink the "blast radius" of a failure — how much of your application goes down when something breaks — but they operate at two completely different physical scales.
| Construct | Protects against | Physical scope |
|---|---|---|
| Availability Set | A rack's power supply or network switch failing | Within a single datacenter |
| Availability Zone | An entire datacenter failing — power, cooling, networking, or a physical event | Across multiple, physically separate datacenters in a region |
Neither one protects against everything. Both are explicitly about hardware and infrastructure-level failures — a rack losing power, a datacenter losing connectivity — not about your operating system crashing or your application throwing an unhandled exception. Those failure modes need a different set of tools (health probes, auto-restart policies, application-level redundancy) layered on top of whichever infrastructure resiliency model you choose.
An Availability Set is a logical grouping capability for VMs that ensures the VMs you place in it are spread across different underlying physical hardware within a single Azure datacenter — different power sources, different network switches — so a hardware-level failure doesn't take every instance of your application down simultaneously.
- Fault domains (up to 3): Each fault domain represents a group of hardware sharing a common power source and network switch — think of it as one rack. VMs in different fault domains are physically isolated from a single rack-level hardware failure.
- Update domains (up to 20): A logical grouping used to stagger planned maintenance. Azure reboots only one update domain at a time during platform maintenance, giving each a 30-minute recovery window before moving to the next — so a rolling platform update never restarts your entire fleet simultaneously.
- No extra cost. There's no charge for the Availability Set construct itself — you pay only for the VM instances you create within it.
- Set at creation, not changeable after. A VM can only be added to an Availability Set when it's created. To move an existing VM into one, you have to delete and recreate it (retaining its disks).
- Lower latency. Because everything in an Availability Set lives in the same datacenter, VM-to-VM latency is lower than it would be across Availability Zones, where physical distance between datacenters is real.
When using managed disks (the default and recommended approach today), Azure aligns each VM's disk fault domain with its compute fault domain, ensuring the OS and data disks attached to a VM share the same resiliency boundary as the VM itself. The number of available managed-disk fault domains varies by region — either 2 or 3 — and you can check the actual number for a given region with az vm list-skus --resource-type availabilitySets.
An Availability Zone is a physically separate location within an Azure region — one or more datacenters equipped with their own independent power, cooling, and networking infrastructure. Regions that support Availability Zones typically offer three (or more) of them, connected by high-speed, low-latency networking, but physically isolated enough that a failure affecting one zone — a power outage, a fire, a flood, or even a larger regional event — doesn't propagate to the others.
- Datacenter-scale isolation. Where an Availability Set's fault domain is a rack, an Availability Zone's isolation boundary is an entire datacenter (or cluster of them).
- Tolerant of larger-scale events. Beyond ordinary hardware failure, zones are explicitly designed to be resilient to events like earthquakes, floods, and fires that could plausibly take out a single physical facility.
- Not available in every region. Availability Zone support depends on the specific Azure region — newer and smaller regions may not yet offer it. Always confirm zone support for your target region before designing around it.
- Two usage patterns: zonal and zone-redundant. Some resources are deployed zonal — pinned to one specific zone you choose. Others are zone-redundant — the platform automatically replicates the resource across multiple zones without you managing the placement directly.
- Slightly higher latency than an Availability Set. Because zones are physically separate datacenters, not racks in the same building, cross-zone network latency is real, even though it's engineered to stay low.
The fault-domain/update-domain concept from Availability Sets has a direct, if larger-scale, analog here: in an Availability Zone architecture, each zone functions as both a fault domain and an update domain simultaneously. A region with three Availability Zones effectively gives you three independent fault domains and three independent update domains — but each one is an entire datacenter rather than a rack, which is the whole point.
Both models use the same underlying vocabulary — fault domain and update domain — but at very different physical scales. Seeing them side by side makes the relationship clear.
| Concept | In an Availability Set | In an Availability Zone deployment |
|---|---|---|
| Fault domain | A rack: shared power source + network switch, within one datacenter | The entire zone (one or more full datacenters) |
| Update domain | A logical group of VMs/hosts rebooted together during maintenance, up to 20 per set | The zone itself acts as an update domain — Azure staggers maintenance across zones |
| Maximum count | 3 fault domains, 20 update domains, fixed at set creation | As many as the region offers — commonly 3 zones per supported region |
| Isolation guarantee | Rack-level: survives one rack's power/network failure | Datacenter-level: survives one entire facility's failure |
A common point of confusion: can you combine Availability Sets and Availability Zones for the same VM tier? In practice, the two are alternative approaches to the same problem at different scales, and the standard modern pattern is to pick the one that matches your resiliency requirement for a given workload tier — Availability Zones where zone support exists and datacenter-level resiliency is required, Availability Sets where zones aren't available in the target region or the workload doesn't need that scale of protection. Trying to layer both (an Availability Set whose members are somehow also spread across zones) isn't how either construct is designed to work — an Availability Set's fault domains are inherently scoped to a single datacenter.
Every major dimension the two constructs differ on, in one bookmarkable table.
| Category | Availability Set | Availability Zone |
|---|---|---|
| Physical scope | Racks within a single datacenter | Physically separate datacenters within a region |
| Protects against | Rack-level power/network switch failure | Datacenter-level failure — power, cooling, network, physical events |
| SLA (multi-instance) | 99.95% | 99.99% |
| Fault domains | Up to 3, fixed at creation | One per zone (commonly 3 per region) |
| Update domains | Up to 20, fixed at creation | The zone itself functions as the update domain |
| VM-to-VM latency | Lower — same datacenter | Slightly higher — real physical distance, low-latency backbone |
| Regional availability | Available in every Azure region | Only in regions that support Availability Zones |
| Cost | Free — pay only for VM instances | Free for the zone construct — pay only for VM instances (some zone-redundant services carry their own pricing) |
| Can add existing VM? | No — must be set at VM creation | No — zone must be set at resource creation |
| Typical use case | Regions without zone support; workloads needing lowest possible inter-VM latency | Mission-critical workloads needing the highest SLA and datacenter-level resiliency |
The SLA percentages translate to concrete, easy-to-misjudge amounts of allowed downtime per year. Seeing the actual numbers makes the gap between 99.95% and 99.99% feel more real than the percentages alone suggest.
| Configuration | SLA | Allowed downtime / month | Allowed downtime / year |
|---|---|---|---|
| Single VM (no set, no zone) | 99.9%* | ~43.8 minutes | ~8.76 hours |
| 2+ VMs in an Availability Set | 99.95% | ~21.9 minutes | ~4.38 hours |
| 2+ VMs across Availability Zones | 99.99% | ~4.38 minutes | ~52.6 minutes |
*Single-VM SLA depends on disk type (e.g. requires Premium SSD or Ultra Disk) — always confirm the specific SLA terms for your configuration on Microsoft's official SLA page before relying on a number for a production commitment.
An Azure SLA is a contractual commitment about service credits if Microsoft fails to meet the stated availability percentage — it is not a technical promise that your application will never experience an outage. Meeting the SLA's prerequisites (2+ VMs correctly distributed across fault domains, or correctly spread across zones) is necessary to qualify for the SLA at all, but the SLA describes Microsoft's infrastructure commitment, not your application's resilience to its own bugs, misconfigurations, or dependencies outside Azure's control.
In practice, the decision usually resolves quickly once you ask these questions in order.
| Question | If yes... |
|---|---|
| Does your target region support Availability Zones? | Check first — if not, Availability Zones aren't on the table regardless of preference, and an Availability Set is your only infrastructure-level HA option |
| Does the workload need to survive a full datacenter outage? | Use Availability Zones — this is the scale of failure only zones protect against |
| Is ultra-low VM-to-VM latency more critical than datacenter-level resiliency? | Consider an Availability Set — same-datacenter proximity keeps latency lower than cross-zone traffic |
| Is this a tightly-coupled cluster (e.g. certain database replication topologies) sensitive to inter-node latency? | Evaluate carefully — some clustering technologies have documented latency tolerances that matter more than the SLA difference |
| Does the business requirement explicitly call for the highest available SLA? | Availability Zones (99.99%) — if the region supports it, this is the stronger commitment |
For new deployments in a region that supports Availability Zones, they're generally the better default for production workloads — the higher SLA and datacenter-level resiliency outweigh the modest latency cost for most applications. Reach for Availability Sets specifically when the target region doesn't support zones, or when a specific, measured latency requirement genuinely can't tolerate the small additional cross-zone network hop.
A hands-on walkthrough using Azure CLI — create the Availability Set first, then create VMs into it.
Create a resource group (if you don't already have one)
Azure CLIaz group create \ --name rg-ha-demo \ --location eastusCreate the Availability Set, specifying fault and update domain counts
Set both explicitly rather than relying on defaults, so the resiliency properties are visible and intentional in your deployment code.
Azure CLIaz vm availability-set create \ --resource-group rg-ha-demo \ --name avset-web-tier \ --platform-fault-domain-count 3 \ --platform-update-domain-count 5Create the first VM, placing it into the Availability Set at creation time
This is the step that can't be undone later — the --availability-set flag has to be present when the VM is created.
Azure CLIaz vm create \ --resource-group rg-ha-demo \ --name vm-web-01 \ --availability-set avset-web-tier \ --image Ubuntu2204 \ --admin-username azureuser \ --generate-ssh-keys \ --size Standard_D2s_v5Create a second VM into the same Availability Set
Two or more VMs in the set is what actually qualifies you for the 99.95% SLA — a set containing only one VM provides no protection and doesn't meet the SLA's prerequisite.
Azure CLIaz vm create \ --resource-group rg-ha-demo \ --name vm-web-02 \ --availability-set avset-web-tier \ --image Ubuntu2204 \ --admin-username azureuser \ --generate-ssh-keys \ --size Standard_D2s_v5Confirm both VMs landed in different fault domains
Verify the platform actually distributed the VMs as expected, rather than assuming it.
Azure CLIaz vm availability-set list-sizes \ --resource-group rg-ha-demo \ --name avset-web-tier # Or check each VM's assigned fault/update domain directly: az vm get-instance-view \ --resource-group rg-ha-demo \ --name vm-web-01 \ --query "instanceView.platformFaultDomain"
The equivalent walkthrough for zone-distributed VMs. There's no separate "zone resource" to create first — you specify the target zone directly on each VM at creation time.
Confirm the target region actually supports Availability Zones
Not every region does. Check before designing around zones.
Azure CLIaz vm list-skus \ --location eastus \ --zone \ --size Standard_D2s_v5 \ --output table # A non-empty result listing zones confirms zone support for that # region and VM size combination.Create a resource group in a zone-supported region
Azure CLIaz group create \ --name rg-ha-zones-demo \ --location eastusCreate the first VM, pinned explicitly to Zone 1
Azure CLIaz vm create \ --resource-group rg-ha-zones-demo \ --name vm-web-z1 \ --zone 1 \ --image Ubuntu2204 \ --admin-username azureuser \ --generate-ssh-keys \ --size Standard_D2s_v5Create a second VM, pinned to a different zone
This is what actually earns you the 99.99% SLA — VMs must be deployed across two or more zones, not just in a zone-capable region while all landing in the same one.
Azure CLIaz vm create \ --resource-group rg-ha-zones-demo \ --name vm-web-z2 \ --zone 2 \ --image Ubuntu2204 \ --admin-username azureuser \ --generate-ssh-keys \ --size Standard_D2s_v5Put a zone-redundant load balancer in front of both
A Standard SKU Azure Load Balancer is zone-redundant by default, meaning it can direct traffic to backend VMs in any zone and itself survives a single zone's failure. This is what makes the zone-distributed backend actually useful for a live application, rather than just two independently-placed VMs.
Azure CLI — zone-redundant public IP and load balanceraz network public-ip create \ --resource-group rg-ha-zones-demo \ --name pip-web-lb \ --sku Standard \ --zone 1 2 3 az network lb create \ --resource-group rg-ha-zones-demo \ --name lb-web-tier \ --sku Standard \ --public-ip-address pip-web-lb \ --frontend-ip-name feConfig \ --backend-pool-name bePoolConfirm each VM's actual zone assignment
Azure CLIaz vm show \ --resource-group rg-ha-zones-demo \ --name vm-web-z1 \ --query "zones" az vm show \ --resource-group rg-ha-zones-demo \ --name vm-web-z2 \ --query "zones"
Azure's zone numbering (1, 2, 3) is a logical mapping that can correspond to different physical datacenters for different subscriptions in the same region — this is by design, to distribute load evenly across Microsoft's physical infrastructure rather than having every customer's "Zone 1" pile onto the same physical facility. Don't assume your "Zone 1" is the same physical location as another subscription's "Zone 1" in the same region.
Key Takeaways
Frequently Asked Questions
Related FAVRITE Articles
- How Azure Resource Manager Differs from the Classic Deployment Model
- Azure OpenAI to Microsoft Foundry: Fixing Private Endpoint & DNS Failures
- Top 100 Azure Cloud Engineer Interview Questions
- Azure Certification Resources