DevOps PeachThree situations affect VMs: unplanned hardware maintenance (Azure predicts a failure and live-migrates), unexpected downtime (the VM fails and is healed/restarted on another host), and planned maintenance (periodic platform updates).
Availability sets
- Group VMs with the same role (one set per application tier), combine with a Load Balancer, use managed disks.
- Fault domain (FD): hardware sharing power/switches — a single point of failure. 2 FDs by default (up to 3 depending on region).
- Update domain (UD): VMs rebooted together during maintenance; only one UD at a time (5 by default, up to 20).
- Protects only within one datacenter; it can only be chosen when the VM is created.
flowchart TB
subgraph AS["avset-web (1 datacenter)"]
subgraph FD0["Fault domain 0"]
W1["web1 (UD0)"]
W3["web3 (UD2)"]
end
subgraph FD1["Fault domain 1"]
W2["web2 (UD1)"]
end
end
subgraph R["Region: 3 availability zones"]
Z1["Zone 1: web-z1"]
Z2["Zone 2: web-z2"]
Z3["Zone 3: web-z3"]
end
Availability zones
Separate physical locations in a region with independent power, cooling and networking. VMs in ≥2 zones (with a zone-redundant Standard LB) survive losing a whole datacenter; the multi-zone VM SLA is 99.99%.
| Availability set | Availability zone | |
|---|---|---|
| Protects against | Rack/host failures, maintenance | Losing an entire datacenter |
| Scope | One datacenter | Several datacenters in the region |
| SLA (≥2 VMs) | 99.95% | 99.99% |
Traps: mixing up fault domains (hardware) and update domains (maintenance); an existing VM cannot be added to an availability set (it must be recreated).
| Command | Meaning |
|---|---|
az vm availability-set create -g rg-devops-lab -n avset-web --platform-fault-domain-count 2 --platform-update-domain-count 5 |
Create a set |
az vm create ... --zone 1 |
VM in zone 1 |
Choosing a level of protection
| Design | Survives | Typical SLA |
|---|---|---|
| Single VM with Premium SSD disks | Host repair by live migration | 99.9% |
| Availability set (2+ VMs) | Rack or host failure, planned maintenance | 99.95% |
| VMs across availability zones | Loss of a datacenter | 99.99% |
| Second region with replication | Loss of a whole region | Depends on your failover design |
An SLA only counts platform availability; the application must also handle a VM disappearing, for example by keeping state in a database rather than on the VM.
Scale sets as an alternative
A Flexible scale set can spread VMs across fault domains or zones automatically, combining the placement of an availability set with easy scaling. Microsoft recommends Flexible scale sets over availability sets for new designs.
Handling maintenance
Scheduled Events is a metadata endpoint inside the VM (http://169.254.169.254/metadata/scheduledevents) that warns an application a few minutes before a reboot or freeze, so it can drain connections. Maintenance configurations let you choose a window for some platform updates, and guest OS patching can be scheduled with Azure Update Manager.
Disaster recovery and backup
- Azure Site Recovery replicates VMs to another region and runs a failover with a recovery plan; test it with non-disruptive test failovers.
- Azure Backup stores restore points in a Recovery Services vault and can restore a whole VM, a disk, or single files.
High availability keeps the service running; backup lets you go back in time after deletion, corruption, or ransomware. You need both.
Latency-sensitive groups
A proximity placement group keeps VMs physically close for the lowest network latency, which trades away some availability spread. Use it only when the application truly needs it.