VM Availability Sets and Zones

An Availability Set is a logical grouping of VMs that Azure distributes across multiple fault domains and update domains within a single Azure datacenter (a region's availability zone or a regional datacenter). The purpose is to ensure that during planned maintenance (e.g., OS updates) or unplanned hardware failures (e.g., disk failure, rack power loss), not all VMs in the set are impacted simultaneously. This raises the SLA for VM uptime: VMs in an Availability Set are eligible for a 99.95% monthly uptime SLA, compared to 99.9% for single-instance VMs. Availability Zones take this further by placing VMs in physically separate datacenters within a region, each with independent power, cooling, and networking, achieving a 99.99% SLA for zonal deployments.

When you create a VM and assign it to an Availability Set, Azure automatically places the VM into one of the fault domains and one of the update domains defined in the set. The set itself has two key properties: - Fault Domain (FD): A logical group of hardware that shares a common power source and network switch. In Azure, each Availability Set has a default of 2 fault domains, but you can configure up to 3 (the maximum). FDs are numbered 0, 1, (and optionally 2). Azure ensures that VMs in the same Availability Set are placed into different FDs to avoid a single point of failure. - Update Domain (UD): A logical group of hardware that undergoes planned maintenance (e.g., patching) at the same time. Azure has a default of 5 update domains per Availability Set, but you can configure up to 20. VMs in different UDs are rebooted sequentially during maintenance, with a 30-minute pause between each UD reboot (this is not user-configurable).

The total number of VMs you can place in an Availability Set is limited by the product of FDs and UDs. For example, with 2 FDs and 5 UDs, you can have up to 10 VMs (2 x 5) without any two VMs sharing the same FD and UD combination. However, you can have more VMs than UDs; Azure will still distribute them across UDs as evenly as possible, but some UDs may contain multiple VMs. The critical rule is that VMs in the same FD and UD combination share the same physical rack and power/cooling.

Availability Zones are physically separate locations within an Azure region. Each zone has its own independent power source, cooling system, and network. A region may have 2 or 3 zones (e.g., East US 2 has 3 zones). When you deploy a VM into a specific zone (Zone 1, 2, or 3), Azure places the VM in that zone's datacenter. There is no automatic distribution across zones; you must manually deploy multiple VMs into different zones to achieve zone redundancy. You can also use a Zone-Redundant Storage (ZRS) account to replicate data across zones. The network latency between zones is typically less than 2 milliseconds round-trip, but this is higher than within a single datacenter.

To create an Availability Set via Azure CLI:

az vm availability-set create \
  --name myAVSet \
  --resource-group myRG \
  --location eastus \
  --platform-fault-domain-count 2 \
  --platform-update-domain-count 5

To create a VM in an Availability Set:

az vm create \
  --name myVM \
  --resource-group myRG \
  --availability-set myAVSet \
  --image UbuntuLTS \
  --admin-username azureuser

To create a VM in a specific Availability Zone:

az vm create \
  --name myVMZone1 \
  --resource-group myRG \
  --zone 1 \
  --image UbuntuLTS \
  --admin-username azureuser

To verify placement, use:

az vm show --name myVM --resource-group myRG --query "instanceView"

Look for platformFaultDomain and platformUpdateDomain fields for Availability Sets, or zones field for zonal VMs.

A Proximity Placement Group (PPG) is a separate construct that reduces network latency between VMs by co-locating them in the same datacenter. This is often confused with Availability Sets. PPGs do NOT provide fault tolerance; they only minimize latency. You can combine PPGs with Availability Sets or Zones, but the exam may ask which to use for low latency vs. high availability.

Azure's fabric controller is responsible for placing VMs into fault and update domains. When a VM is created in an Availability Set, the fabric controller checks the existing VMs in the set and places the new VM into the FD and UD with the fewest VMs. This ensures even distribution. During planned maintenance, Azure reboots VMs one update domain at a time, waiting 30 minutes between domains. Unplanned failures affect only one fault domain. In Availability Zones, the fabric controller places the VM in the specified zone's datacenter; no automatic distribution across zones occurs.

A large e-commerce company runs a critical web application on Azure. They need to maintain 99.99% uptime. They deploy two VMs running the web server across two Availability Zones (Zone 1 and Zone 2) in the East US region. They also deploy two VMs for the database layer in the same zones, using SQL Server Always On Availability Groups. The load balancer is a Standard Load Balancer with a zone-redundant frontend IP. This setup ensures that if one entire datacenter goes down (e.g., power failure), the other zone continues serving traffic. The team monitors latency between zones (typically <2ms) and ensures that the application can handle the slight latency increase. They also configure Azure Site Recovery to replicate VMs to a secondary region for disaster recovery. In production, they have auto-scaling configured via Virtual Machine Scale Sets with zones, but they started with static VMs to control costs. Common mistake: initially they deployed all VMs in the same Availability Set within one zone, thinking that was sufficient. After a zone-wide outage, they learned the hard way and migrated to a multi-zone architecture.

A financial services firm runs a latency-sensitive trading application. They cannot tolerate the extra milliseconds of cross-zone latency. They choose Availability Sets instead of Zones. They deploy 4 VMs in an Availability Set with 2 fault domains and 5 update domains. All VMs are in the same datacenter, so latency is minimal. They use managed disks and a Standard Load Balancer to distribute traffic. The application is not mission-critical enough to need zone redundancy, but they want protection against rack-level failures. During planned maintenance, Azure reboots VMs one update domain at a time, so the application remains available with reduced capacity. They test this by triggering a simulated maintenance event and monitoring application performance. The main challenge is ensuring that the application can handle the loss of one fault domain (e.g., 2 VMs out of 4) without crashing. They configure health probes on the load balancer to remove unhealthy VMs. A common misconfiguration: they initially used unmanaged disks, which caused all VMs to depend on a single storage account, creating a single point of failure. Switching to managed disks resolved this.

A media company runs a video rendering farm that requires high throughput between VMs. They use Proximity Placement Groups to co-locate VMs in the same datacenter, combined with an Availability Set to ensure fault tolerance. They deploy 10 VMs in a single PPG, with an Availability Set configured with 3 fault domains and 10 update domains. This ensures low latency (since all VMs are physically close) and protection against rack failures. However, they cannot achieve zone-level redundancy because PPGs are confined to one datacenter. They accept this trade-off because the application is not critical enough to require multi-datacenter resilience. The team uses Azure CLI to create the PPG and associate it with the Availability Set. They monitor latency metrics and ensure that the PPG does not become too large (max 100 VMs per PPG). A pitfall: if they need to expand to another region, they must create a new PPG in that region.