AZ-900
Deep Dive
How Azure builds its datacenters, the real design of AZs, Availability Sets, Dedicated Hosts, and how to design for 99.99%+ SLAs. D2 goes beyond the concepts — here's the real architecture.
Contents
Before understanding AZs and SLAs, you need to understand what Azure physically protects.
Physical infrastructure of an Azure datacenter
Redundant power sources
Electrical power from multiple independent substations. UPS (Uninterruptible Power Supply) for every rack. Diesel generators with fuel for 72h of autonomous operation.
Independent cooling
Separate climate control systems. If one module's cooling fails, the others keep running. PUE efficiency of ~1.12 (vs. 1.5 typical for enterprise).
Redundant fiber network
Multiple fiber optic routes entering the datacenter through different physical conduits. No single point of failure in connectivity.
Multi-layer physical security
Physical perimeter, biometrics (iris, fingerprint), mandatory escorted access, 24/7 cameras, security guards. Only certified personnel with a specific need get in.
Azure vs. typical enterprise datacenter
What physically separates AZs
Physical distance
AZs are at least several kilometers apart within the same metropolitan region. Enough that a local incident (flood, fire) won't affect all of them.
Independent network
Each AZ has its own fiber entry points, edge switches, and routers. They share no physical network component with the other AZs.
Guaranteed latency
Microsoft guarantees < 2ms one-way latency between any pair of AZs in the same region. This enables synchronous active-active architectures.
Services with AZ support
Not all Azure services support AZs. Three categories:
You deploy to a specific AZ (Zone 1, 2, or 3). You control the zone.
Examples: VMs, Managed Disks, Standard IPs
Azure automatically deploys across multiple AZs. No zone configuration needed.
Examples: Azure SQL DB, Zone-redundant Storage, App Gateway v2
Global services with no AZ. Always available, no zone association.
Examples: Entra ID, Azure DNS, Azure Front Door
SLA by deployment architecture
Maximum downtime: ~8.7h/year
Maximum downtime: ~4.4h/year
Maximum downtime: ~52min/year
Maximum downtime: ~5min/year
Both improve VM availability, but they protect against different types of failures. It's one of the most common points of confusion in the AZ-900.
Availability Sets (AS)
Distributes VMs across Fault Domains (distinct physical racks) and Update Domains (groups for planned maintenance) within the same datacenter.
Fault Domains (FD)
Max. 3 FDs per region. Each FD = a separate physical rack with its own power and network. If a rack goes down (power outage) → only VMs in that FD are affected.
Update Domains (UD)
Max. 20 UDs. When Azure performs physical host maintenance, it only restarts one UD at a time. With 2 UDs: while UD1 restarts, UD2 keeps serving.
SLA with AS
99.95% for VMs with Premium SSD in an Availability Set
Availability Zones (AZ)
Distributes VMs across physically separate datacenters (different buildings, different power, different network) within the same metropolitan region.
Protects against
Complete failure of a datacenter: fire, flood, total power outage, massive hardware failure. The other AZ keeps running.
Latency between AZs
< 2ms guaranteed. Enables synchronous replication (data in two AZs = always consistent). The app can run in AZ1 with the DB in AZ1 and AZ2.
SLA with AZs
99.99% for VMs deployed across multiple AZs
| Characteristic | Availability Sets | Availability Zones |
|---|---|---|
| Protection scope | Within the same datacenter | Across distinct datacenters |
| Protects against rack failure | ✓ (Fault Domains) | ✓ (each AZ = a distinct datacenter) |
| Protects against datacenter failure | ✗ | ✓ |
| VM SLA | 99.95% | 99.99% |
| Granularity | Rack / maintenance group | Full datacenter |
| Extra cost | None (same region) | Minimal egress between AZs |
| Availability | All regions | Only in regions with AZs (~40+) |
| When to use | Legacy apps, regions without AZs, rack granularity | Recommended by default when available |
Can you combine AS and AZs?
NO. A VM belongs to an Availability Set OR to an Availability Zone — not both. If your region has AZs, use AZs (better protection). If it doesn't have AZs, or for legacy app compatibility, use Availability Sets. Microsoft recommends AZs over AS for new deployments.
Create a virtual machine explicitly choosing an Availability Zone, and understand how this reduces the risk of a datacenter failure.
+1 more...
Azure Dedicated Hosts
A complete physical server dedicated exclusively to your organization. Only your VMs run on that hardware.
When to use it?
Limitations
Proximity Placement Groups (PPG)
Groups VMs as physically close together as possible (same datacenter, same rack if possible) to minimize latency between them.
Why does intra-cluster latency matter?
An HPC (High Performance Computing) cluster or a database cluster needs node-to-node communication in microseconds, not milliseconds. Without a PPG, two VMs can end up in different racks of the same AZ → 0.5–2ms latency. With a PPG → <0.1ms.
Use cases
When your architecture has multiple components, the total SLA is the product of the individual SLAs. This is fundamental for design and a frequent AZ-900 exam question.
Formula: composite SLA = SLA₁ × SLA₂ × SLA₃
For components in series (if one fails, the service fails), SLAs are multiplied.
Classic 3-tier web app (in series)
Azure Load Balancer
99.99%
Azure App Service (Standard)
99.95%
Azure SQL Database (General Purpose)
99.99%
99.93%
0.9999 × 0.9995 × 0.9999 = 0.9993 ≈ 99.93%
Even though each component has a high SLA, the composite SLA GOES DOWN. This is the cumulative effect.
Web app with redundancy in App Service
Azure Load Balancer
99.99%
App Service × 2 AZs (parallel)
99.9999%*
Azure SQL Database (Zone Redundant)
99.995%
99.985%
0.9999 × 0.999999 × 0.99995 ≈ 99.985%
*App Service SLA with Zone Redundancy. For parallel: 1 - (1-SLA)^n
The cumulative effect — a rule for the exam
More components in series = composite SLA ALWAYS lower than the lowest individual SLA. If someone says "our architecture has a 100% SLA because all the components have 99.99%", they're wrong. There's no such thing as a 100% SLA.
Active-Passive
One active instance handles all the traffic. A passive instance stays on standby, ready to take over if the active one fails.
Advantages
Disadvantages
In Azure
Azure Site Recovery, SQL Server AlwaysOn in asynchronous mode, Azure SQL Database Business Critical with geo-replica
Active-Active
Multiple active instances handle traffic simultaneously. If one fails, the others absorb its load.
Advantages
Disadvantages
In Azure
VM Scale Sets with Load Balancer, App Service with multiple instances, Cosmos DB multi-region write
N+1 Redundancy
You have the N instances needed to handle the load + 1 extra instance. If one fails, the remaining N keep handling the full load.
Advantages
Disadvantages
In Azure
VM Scale Sets with a minimum of 2 instances, AKS with a minimum of 3 nodes, App Service with 2 instances on Standard+
Create a Recovery Services vault with geo-redundancy and enable daily backup for a VM.
+1 more...
Did you get this topic?
Test what you just learned
What is the main purpose of region pairs in Azure?
Put what you learned to the test with original AZ-900 exam questions.
Start AZ-900 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.