Azure Fault Domains and Update Domains Explained
for High-Availability Virtual Machines
Two VMs in the same Availability Set can still go down together — not because the feature failed, but because two independent grids were involved, and only one of them was configured with enough room to keep the VMs apart. Fault domains and update domains are not the same axis measured twice. They're a genuine two-dimensional grid, and understanding both dimensions — not just the word "fault domain" — is what separates a deployment that's actually fault-tolerant from one that only looks like it on a diagram.
Most explanations of Availability Sets mention fault domains and update domains as if they were roughly the same idea wearing two names — spread your VMs out, redundancy achieved. They aren't the same idea, and treating them that way is how a team ends up with an Availability Set that looks correctly configured and still loses every instance of an application to a single event. A fault domain is a physical concept: a group of servers sharing one power source and one network switch, so a hardware failure in that group can't reach VMs in a different one. An update domain is a logical concept: a group of VMs Azure will restart together during planned maintenance, so a platform update never touches your entire fleet at once. They are assigned to each VM independently and simultaneously — every VM in an Availability Set gets a fault domain coordinate and an update domain coordinate, and real fault tolerance depends on understanding both axes of that grid, not just picking a bigger number for one of them.
A fault domain is a physical grouping — a set of hardware that shares a common power source and network switch. Picture a single server rack: everything plugged into that rack's power distribution unit and connected through that rack's top-of-rack network switch is one fault domain. If that power supply fails or that switch dies, every VM physically hosted on hardware in that fault domain is affected, regardless of anything else about how those VMs are configured.
- It's about physical failure isolation. Fault domains exist specifically to contain the blast radius of hardware-level failures — a bad power supply, a failed network switch, localized physical issues within a single rack.
- Up to 3 per Availability Set, by default. When you create an Availability Set, Azure separates VMs across up to 3 fault domains automatically, unless region-specific constraints apply.
- You don't choose which physical rack. Azure assigns the actual physical hardware; you're choosing how many logical fault domain "slots" to spread your VMs across, not the specific rack itself.
- Fixed at Availability Set creation. The fault domain count for an Availability Set is set when the set is created and can't be changed afterward — get this decision right up front.
Not every region can offer the maximum fault domain count, and Microsoft's own guidance notes explicitly that selecting three fault domains may not always be possible depending on the region. If your design assumes 3 fault domains specifically, verify it against the actual region you're deploying into — az vm list-skus --resource-type availabilitySets returns the maximum fault domain count Azure will actually honor for a given location.
An update domain is a logical grouping — a set of VMs and their underlying physical hardware that Azure will restart together during planned platform maintenance. This has nothing to do with physical racks directly; it's an operational grouping Azure uses to stagger maintenance-related reboots so an entire fleet is never restarted simultaneously.
- It's about planned-maintenance isolation. When Azure needs to patch or update the underlying host infrastructure, only one update domain is rebooted at a time.
- Up to 20 per Availability Set, by default. Compared to the 3-fault-domain ceiling, update domains offer far more granularity for spreading out maintenance impact.
- A 30-minute recovery window between update domains. After Azure restarts one update domain for maintenance, it allows 30 minutes for that domain's VMs to recover before beginning maintenance on the next update domain.
- The order isn't strictly sequential. Azure may not restart update domain 0, then 1, then 2 in that exact order during a given maintenance cycle — but it guarantees only one update domain is being restarted at any given time.
A fault domain failure and an update-domain-driven reboot are genuinely different event types, and conflating them is the most common source of a false sense of security. A hardware failure in one rack has nothing to do with which update domain a VM belongs to. A planned platform maintenance reboot has nothing to do with which rack a VM's hardware sits in. An Availability Set with a strong fault domain spread but only 1 effective update domain (because too few VMs are spread across too many update domain slots to matter, or the count was never configured deliberately) is still exposed to every VM restarting for maintenance at the same time.
The detail Figure 1 is built to make visible: fault domain assignment and update domain assignment are not the same operation performed twice, and they're not sequential steps — every VM added to an Availability Set receives both coordinates simultaneously, independently, on two grids of different sizes (up to 3 columns... or rows, however you draw it... for fault domains; up to 20 for update domains).
| Scenario | What's actually protected | What's NOT protected |
|---|---|---|
| Rack power supply fails | VMs in other fault domains keep running | Every VM sharing that fault domain goes down, regardless of their update domain |
| Planned maintenance reboot | VMs in other update domains keep running | Every VM sharing that update domain restarts, regardless of their fault domain |
| Both, correctly spread | No single rack failure OR maintenance event takes out every instance | Nothing structural — this is the actually-correct design |
This is why a two-VM Availability Set, correctly configured, already provides meaningful protection against both event types simultaneously — Azure will place those two VMs in different fault domains and different update domains by default, protecting against a rack failure and a maintenance reboot with the same two-VM deployment. The value compounds, not doubles, as you add more VMs correctly spread across both grids.
Both fault domains and update domains have a finite count — up to 3 and up to 20 respectively in a standard Availability Set. Once your VM count exceeds either ceiling, Azure doesn't refuse the deployment or create additional domains; it wraps around and starts reusing domains from the beginning, round-robin style.
| Example | Domains configured | VM count | Result |
|---|---|---|---|
| Within capacity | 5 update domains | 5 VMs | Each VM gets a unique update domain — a maintenance reboot affects exactly 1 VM at a time |
| Overflow by 1 | 5 update domains | 6 VMs | VM6 shares an update domain with VM1 — a maintenance reboot of that domain now affects 2 VMs |
| Overflow by 2 | 5 update domains | 7 VMs | VM6 and VM7 share domains with VM1 and VM2 respectively — the same pattern continues |
This is entirely expected, documented Azure behavior — not a defect — but it has a real design consequence worth internalizing: an Availability Set with far more VMs than update domains doesn't actually deliver "1 VM affected per maintenance event" once the VM count climbs past the domain count. The math is straightforward — VM number N is assigned to update domain (N-1) mod (number of update domains) — and knowing it lets you deliberately choose an update domain count that keeps your maximum expected VM count within capacity, rather than discovering the overlap after a maintenance window affects more instances than the architecture diagram implied.
Beyond the expected round-robin overflow, there's a documented edge case worth knowing: if you deploy a first VM, then stop or deallocate it, then deploy a second VM into the same Availability Set, the second VM's OS disk can land in the same fault domain as the first — even if both would otherwise have been correctly separated. The fix is procedural: don't stop or deallocate VMs between deployments into the same set. Verify actual fault domain assignment (Section 8's validation step) rather than assuming correct separation just because the set was configured correctly.
Availability Zones use the same fault-domain-and-update-domain vocabulary, but at a completely different physical scale — worth understanding precisely rather than assuming it's "the same thing but bigger."
| Concept | In an Availability Set | In an Availability Zone deployment |
|---|---|---|
| Fault domain | A rack — shared power/network switch within one datacenter | The entire zone — one or more complete, physically separate datacenters |
| Update domain | A logical reboot group, up to 20 per set | The zone itself functions as both the fault AND update domain simultaneously |
| Count | Up to 3 fault domains, up to 20 update domains | As many as the region offers — commonly 3 zones |
The practical consequence for VMSS specifically: a zonal or zone-spanning Flexible-orchestration scale set is documented to only support a fault domain count of 1 with max spreading — because at that scale, the zone assignment is already doing the fault-isolation work that fault domain count would otherwise handle within a single datacenter. Configuring additional fault domain spreading within a single zone would be solving a problem the zone boundary has already solved at a coarser, more effective level.
Virtual Machine Scale Sets extend fault domain spreading to auto-scaling fleets, but the two orchestration modes — Uniform and Flexible — handle fault domains differently, and the distinction is more than cosmetic. Microsoft's current guidance recommends Flexible orchestration for new workloads.
| Aspect | Uniform Orchestration | Flexible Orchestration |
|---|---|---|
| Regional (non-zonal) fault domain options | 2, 3, 4, or 5 | 2 or 3 |
| Zonal / zone-spanning fault domain count | N/A — zone provides isolation | Only 1, with max spreading — the zone already handles isolation |
| VM API compatibility | Not compatible with standard IaaS VM API, ARM tagging, RBAC, Azure Backup, or Azure Site Recovery | Fully compatible — each instance is a standard, individually addressable VM resource |
| Fault domain assignment visibility | Exposed via standard VMSS APIs | Instances ARE distributed across fault domains, but this isn't exposed through the Instance View REST API |
| Recommended for new workloads | No — described as the legacy approach | Yes — Microsoft's current default recommendation |
| VM size constraints | Broad support | Excludes G, H, L, M, and N-series — sizes that don't support memory-preserving updates or live migration |
When adding a VM to a Flexible-orchestration scale set, Azure evenly spreads instances across the configured fault domains automatically by default, and Microsoft's own guidance recommends letting this default behavior stand. You can override it and pin a specific instance to a specific fault domain (az vm create --vmss "myVMSS" --platform-fault-domain 1), but this is intended for advanced or troubleshooting scenarios — deliberately forcing uneven distribution in a production scale set undermines the fault tolerance the feature exists to provide, and should be a conscious, documented exception rather than a routine practice.
Beyond choosing a fault domain count, VMSS supports a distinction between fixed spreading (a predictable, specific number of fault domains — useful when a workload genuinely needs exactly N domains, such as database replicas requiring exactly 3) and max spreading (spread across as many fault domains as the platform makes available). Choose fixed spreading when your application logic depends on a specific, known fault domain count; choose max spreading when you simply want the best distribution the platform can offer without a hard requirement on the exact number.
A detail easy to overlook: a VM's compute and its attached disks need to share the same fault domain for the VM's resiliency to actually mean anything — a VM correctly spread across fault domains does no good if its OS disk is physically vulnerable to a failure the compute layer was protected against.
- Managed disks are automatically aligned to their VM's fault domain. When you use managed disks (the default and recommended approach for virtually all modern deployments), Azure ensures every disk attached to a VM shares that VM's fault domain — compute and storage fail together as intended, not independently.
- Only VMs with managed disks can be created in a managed Availability Set. This alignment guarantee is specifically a managed-disk capability; it's part of why managed disks have been the standard recommendation for years.
- The number of available disk fault domains varies by region — 2 or 3. Not every region offers the same disk fault domain ceiling, mirroring the same regional variability that applies to compute fault domains.
Check the actual fault domain maximum for your target region
Don't assume 3 fault domains are available everywhere — run az vm list-skus --resource-type availabilitySets against your specific region first, since this varies and directly determines what you can request in the next step.
Create the Availability Set with explicit fault and update domain counts
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 your VMs into the set, all at once and without stopping any between deployments
Deploy every VM destined for this Availability Set in the same session, without stopping or deallocating any VM in between — this avoids the documented shared-fault-domain edge case from Section 4.
Verify actual fault domain and update domain assignment — don't assume correct spreading
Azure CLIaz vm get-instance-view \ --resource-group rg-ha-demo \ --name vm-web-01 \ --query "instanceView.platformFaultDomain" az vm get-instance-view \ --resource-group rg-ha-demo \ --name vm-web-01 \ --query "instanceView.platformUpdateDomain" # Repeat for every VM in the set. Confirm no two VMs meant to be # independently protected share BOTH the same fault domain AND the # same update domain.Confirm managed disk alignment for the region you're deploying into
Run the az vm list-skus --resource-type availabilitySets --query "[?name=='Aligned']..." query from Section 7 to confirm the disk fault domain ceiling matches your compute fault domain assumptions for this specific region.
Calculate your safe VM ceiling before scaling the set further
Using the round-robin formula from Section 4, determine how many VMs you can add before update domain overlap begins — and decide deliberately whether that overlap is acceptable for this specific workload's risk tolerance, rather than discovering it after scaling.
| Anti-pattern | Why it feels right | Why it isn't |
|---|---|---|
| Treating "in an Availability Set" as automatically fully protected | "We used an Availability Set, so we're covered" | Fault domains and update domains are two independent axes — genuine protection requires both to actually separate your critical VM pairs, not just membership in the set |
| Scaling VM count without checking update domain overlap | "More VMs means more redundancy" | Past the configured update domain count, VMs start sharing domains via round-robin — a maintenance event can affect more instances than the architecture assumed |
| Stopping and deallocating a VM between deployments into the same set | "Just a routine pause, shouldn't matter" | This specific sequence is documented to sometimes cause the next VM's disk to land in the same fault domain as the stopped one — verify, don't assume |
| Assuming 3 fault domains are available in every region | "That's the standard maximum" | Microsoft's own guidance notes 3 fault domains may not always be possible depending on region — verify with the actual SKU query before designing around it |
| Using Uniform orchestration for new VMSS workloads by default | "It's the original, well-established mode" | Microsoft explicitly recommends Flexible orchestration for new workloads, and Uniform-mode instances lack compatibility with standard IaaS VM APIs, Backup, and Site Recovery |
| Manually overriding fault domain placement in production without a specific reason | "I want more control over exactly where things land" | Manual fault domain pinning is intended for advanced or troubleshooting scenarios — routine use in production undermines the automatic, even distribution the platform provides by default |
Key Takeaways
Frequently Asked Questions
Related FAVRITE Articles
- Azure Availability Set vs Availability Zone: The Complete Guide
- Designing a Multi-Region Azure Architecture for High Availability and Disaster Recovery
- How Azure Resource Manager Differs from the Classic Deployment Model
- Enterprise Network Segmentation in Azure: Architecture Patterns That Actually Scale