In one sentence. If both your web servers sit in the same rack and the rack loses power, both die. An availability set tells Azure "keep these apart on different racks, and never patch them at the same time". Availability zones go further: different buildings in the same city. A scale set is a group of identical servers that Azure can add to or remove from automatically.
Availability set · same building, different racks · 99.95%
VM1rack (fault domain) 0 · patch group (update domain) 0
→different rack
VM2rack 1 · patch group 1
→different rack
VM3rack 2 · patch group 2
Protects against
- One rack losing power or its switch
- Azure patching the host: VMs in different update domains are never rebooted together
- Up to 3 fault domains and 20 update domains
- Chosen only when the VM is created; existing VMs cannot join
Availability zones · different buildings in the same city · 99.99%
Zone 1VM1
→separate power, cooling, network
Zone 2VM2
→separate power, cooling, network
Zone 3VM3
Protects against
- A whole datacentre going dark
- Everything a set protects against, too
- Needs a zone-redundant Standard load balancer in front and ZRS storage
- Pick the zone number on the Basics tab when creating the VM
Which is better?
"Highest SLA without using separate datacentres" = availability set. "Must survive the loss of a datacentre" = availability zones. A single VM on Premium SSD gets 99.9% on its own; on standard HDD it gets no SLA.
| You choose (Basics tab › Availability options) | Protects against | Microsoft SLA | Catch |
|---|---|---|---|
| No infrastructure redundancy | Nothing structural | 99.9% if Premium SSD; none on HDD | — |
| Availability set (make it first: Availability sets › + Create, 2 or 3 fault domains, up to 20 update domains) | Rack failure and Azure patching inside one datacentre | 99.95% with 2+ VMs | Chosen only when the VM is created; existing VMs cannot join |
| Availability zone 1, 2 or 3 | A whole datacentre | 99.99% with VMs in 2+ zones | Put a zone-redundant Standard load balancer in front; use ZRS storage |
Virtual Machine Scale Sets
You, the admin: a web tier that grows at lunchtime
- Virtual machine scale sets › + Create. Orchestration mode Flexible (recommended; Uniform is the older identical-only mode). Image, size, zones 1-3, initial instance count 2.
- Scaling tab: Autoscale. Rule: if average Percentage CPU > 75% for 10 minutes, increase count by 2; if < 25% for 10 minutes, decrease by 1; min 2, max 10. Add a schedule profile if load is predictable.
- Networking: put a Standard load balancer in front so one address serves all instances.
- After creation, Scale set › Scaling is where rules live; Instances shows each VM; Upgrade policy (Manual / Automatic / Rolling) decides how a new image rolls out; Scale-in policy decides which instance is removed first (default, newest, oldest).
Trap wording. "Cannot add the VM to the availability set" = by design, recreate it. "Highest SLA without different datacentres" = availability set. "Must survive loss of a datacentre" = zones. "Add servers automatically when CPU is high" = scale set autoscale rule, not upgrade policy.