What's changed: Deepened AZ-104 Chapter 3 to Associate depth (tables, scenarios, FAQ, traps; localized figures)
3.2Scaling and High Availability
Understand scaling and availability: autoscale with virtual machine scale sets (VMSS) and the difference between availability sets (fault/update domains) and availability zones.
To handle load changes and failures, design to scale (add/remove instances automatically) and stay up under failure (high availability).
3.2.1Scale and availability
- Virtual machine scale set (VMSS): a group of identical VMs that autoscales by load.
- Availability set: spreads across fault domains (power/network) and update domains (maintenance units) to handle failures/updates within a datacenter.
- Availability zones: spread across physically separate datacenters, surviving a datacenter-level failure.
Common on AZ-104: autoscale by load = VMSS, handle in-DC failure/updates = availability set, survive a DC-level failure = availability zones.
Scale and availability are distinct. Scaling is "horizontal (instance count)" or "vertical (resize)"; a virtual machine scale set (VMSS) auto-scales identical VMs horizontally by metrics (CPU, etc.)/schedule (with Flexible/Uniform orchestration modes). Availability ties to SLA and is determined by placement: an availability set spreads within one datacenter across fault domains (power/network/rack) and update domains (maintenance units) to avoid simultaneous impact from unplanned failures and planned maintenance. Availability zones spread across physically separate datacenters, surviving a DC-level failure (higher SLA). Front instances with a Load Balancer (L4)/Application Gateway (L7) to distribute to healthy instances, using health probes to drop unhealthy ones. For cross-region DR, use Azure Site Recovery or Front Door/Traffic Manager. The axes: "follow load = VMSS," "in-DC failure/updates = availability set," "survive a DC failure = availability zones," "distribute = LB/App Gateway."
| Goal | Use |
|---|---|
| Autoscale count by load | VMSS (horizontal) |
| In-DC failure/maintenance | Availability set (fault/update domains) |
| Survive a DC failure | Availability zones |
| Distribute to healthy targets | Load Balancer / Application Gateway |
Scenario: make the web tier follow sudden spikes and survive a DC failure. Autoscale the web tier with a VMSS on CPU metrics and spread instances across availability zones (DC-failure resilience, higher SLA). Front it with an Application Gateway (L7, WAF) or Load Balancer (L4), using health probes to exclude unhealthy instances. For regional disasters, route across regions with Front Door.
Q. Autoscale by load? VMSS. Q. In-DC failure/updates? Availability set (fault/update domains). Q. Survive a DC failure? Availability zones. Q. Distribute to healthy targets? Load Balancer/Application Gateway. Q. Cross-region DR? Site Recovery / Front Door.
Watch the mix-ups: (1) Scaling (count) ≠ availability (placement)—VMSS can raise availability but its purpose is autoscaling. (2) Availability set (in-DC) ≠ availability zones (DC separation)—a DC failure needs zones. (3) A single VM has limited SLA—meeting SLA needs zones or multiple instances. (4) Don’t confuse L4 (LB) with L7 (App Gateway)—path routing/WAF is L7.
For higher availability, choose zones (datacenter separation). If in-datacenter redundancy suffices, an availability set is enough.
3.2.2Section summary
- Autoscale with VMSS; use availability sets/zones for HA
- Zones = DC separation; availability set = handle in-DC failure/updates
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to autoscale identical VMs by load. What do you use?
Q2. You want VMs placed to survive a datacenter-level failure. What fits best?
Q3. Across what units does an availability set distribute VMs?