4.1.3.2. Design for Azure Availability Sets
4.1.3.2. Design for Azure Availability Sets
💡 First Principle: Distributing virtual machines across isolated hardware clusters within a single datacenter provides a crucial layer of redundancy against localized hardware failures and planned maintenance events.
Scenario: You are designing a solution for a critical application running on multiple Virtual Machines. This application cannot be easily refactored to span Availability Zones, but you need to ensure it remains available even if the underlying hardware (e.g., server rack, network switch) within a single datacenter fails, or during planned Azure maintenance.
An Availability Set is a logical grouping capability for virtual machines that allows Azure to understand how your application is built to provide redundancy and availability.
Key Design Considerations:
- Fault Domains: Each Availability Set splits VMs into fault domains, which are physically separate groups of hardware (power, network, servers).
- Update Domains: VMs are also distributed across update domains. During planned maintenance, Azure updates one update domain at a time.
- VM Deployment: All VMs in an Availability Set must reside in the same resource group and virtual network.
- Limitations: Availability Sets provide high availability only within a single Azure datacenter. They do not protect against datacenter-wide or regional outages.
- Use Cases: Ideal for legacy workloads or applications that cannot use Availability Zones, but still require improved uptime within a datacenter.
Design decisions in practice:
| Concept | What it protects against |
|---|---|
| Fault domain | A rack with shared power and network. Spreading across fault domains survives a rack-level hardware failure |
| Update domain | A group rebooted together during planned host maintenance. Spreading across update domains means maintenance never takes every instance at once |
Everything an Availability Set does happens inside ONE datacenter, and that single fact decides when it is the right answer. It covers hardware failure and host patching — the everyday causes of a VM restarting — but a flood, fire or power loss affecting the building takes every fault and update domain with it. Availability Zones exist precisely to cover that case.
The two are mutually exclusive for the same VM set, so this is a choice rather than a combination. Prefer zones where the region offers them; reach for an Availability Set when the region has no zones, when an existing deployment already uses one, or when a workload must stay physically close for latency and cannot be spread.
⚠️ Exam Trap: an Availability Set must be specified when the VM is CREATED — a running VM cannot be moved into one. A scenario describing VMs already deployed is asking you to recognise that they must be redeployed, not reconfigured.
⚠️ Common Pitfall: Placing a single VM in an Availability Set. An Availability Set provides no benefit unless it contains at least two VMs distributed across different fault and update domains.
Key Trade-Offs:
- Availability vs. Control: When using an Availability Set, you cede some control over the exact physical placement of your VMs to Azure, in exchange for the guarantee of hardware isolation.
Reflection Question: How does designing for Azure Availability Sets, by distributing VMs across isolated fault domains and update domains, fundamentally minimize downtime from hardware failures or maintenance, ensuring application availability within a single datacenter?
