D3 · Business Continuity

High Availability Design

High availability = surviving failures within a region (HA) or of an entire region (DR). The AZ-305 will ask you to calculate which architecture meets a target SLA ("99.99%") and choose between availability sets, zones and multi-region based on cost and requirements.

Contents

Building blocks: fault domains, sets and zones
SLAs and composite SLA
HA patterns by layer
Multi-region HA
Decision table

Building blocks: fault domains, availability sets and zones

Construct	Protects against	VM SLA (2+)
Single VM (premium SSD)	Nothing — only the hardware SLA	99.9%
Availability Set (fault/update domains)	Rack failure (FD) and planned maintenance (UD) — same datacenter	99.95%
Availability Zones	Loss of an entire datacenter (zone) — independent power, network, cooling	99.99%
Multi-region (+ Front Door/Traffic Manager)	Regional disaster	Composite >99.99%

Exam rules

• "99.99% for the VMs" → Availability Zones (sets only reach 99.95%)
• Availability set and zones are mutually exclusive for the same VM
• Zone-redundant services (Standard LB, App Gateway v2, ZRS, zonal SQL BC) automatically spread redundancy across zones
• VMSS with "zone balancing" spreads instances across zones — the modern default pattern

Zone trade-offs

• Inter-zone latency ~1-2 ms — relevant for chatty clusters
• Inter-zone traffic can incur cost
• Not every region has zones (fewer and fewer exceptions)
• Proximity placement groups (minimal latency) clash with spreading across zones — pick a priority

SLAs and composite SLA

The composite SLA of services in series multiplies: App Service (99.95%) × SQL Database (99.99%) = 99.94% — always LOWER than the weakest component. To raise it: redundancy in parallel (multi-instance, multi-zone, multi-region) or removing synchronous dependencies (queues).

Allowed downtime by tier

99.9%~8.7 hours/year

99.95%~4.4 hours/year

99.99%~52 minutes/year

99.999%~5 minutes/year

How to reason on the exam

• Chain in series: multiply the SLAs — if it misses the target, add redundancy
• Components in parallel: 1−(1−A)×(1−B) — two 99.9% paths ≈ 99.9999%
• Decoupling with queues turns hard dependencies into soft ones (the app survives if the backend is down for a while)
• The real business SLA includes YOUR code and operations — Azure's SLA is only the platform

HA patterns by layer

Layer	Intra-region HA design
Web/API (PaaS)	App Service plan with ≥2-3 instances + zone redundancy; autoscale
Compute (IaaS)	VMSS Flexible (modern default mode) spread across zones behind a zone-redundant Standard Load Balancer; VMSS Uniform only for legacy workloads
Containers	AKS with node pools across multiple zones; pod topology spread
SQL Database	Business Critical/GP with zone redundancy (replicas in different zones)
Storage	ZRS (or GZRS if also doing regional DR)
Messaging	Service Bus Premium (zone redundant by default)
Cache	Redis Standard/Premium with replica; Premium with zones
Regional load balancing	Standard LB / App Gateway v2 (both zone-redundant)

Multi-region HA

Active-Active

•Both regions serve traffic (Front Door/Traffic Manager distribute it)
•RTO ≈ 0: a region failure only reduces capacity
•More expensive; requires multi-region data (Cosmos multi-write, replication)

Active-Passive (hot standby)

•Secondary is deployed and running, receives failover
•RTO minutes; intermediate cost
•Typical pattern with SQL failover groups + Front Door priority routing

Active-Passive (cold / redeploy)

•Secondary is created on failure (IaC + backups/ASR)
•RTO hours; the cheapest
•For tolerant workloads with a tight budget

Global entry point

Azure Front Door (L7: HTTP/S, near-instant failover, WAF, CDN) vs Traffic Manager (DNS: any protocol, failover depends on TTL). For multi-region web apps, the modern answer is Front Door.

Decision table

Requirement	Design
99.99% SLA for a VM layer in one region	VMs/VMSS in Availability Zones + Standard LB
99.95% SLA is enough, region without zones	Availability Set
The composite SLA in series misses the target	Parallel redundancy or decouple with queues
Global web app that survives a regional outage with RTO≈0	Active-active multi-region + Front Door
Cheap regional DR, hours-long RTO acceptable	Cold standby: IaC + geo-redundant backups
Storage that survives a zone outage	ZRS
Minimal latency between cluster VMs	Proximity placement group (sacrificing zonal resilience)

Did you get this topic?

Test what you just learned

An app runs on 4 VMs behind a load balancer in West Europe. The business requires 99.99% SLA for the compute layer and the app must survive the complete failure of a datacenter while staying in a single region. Which design meets this?

Ready to test "High Availability Design"?

Put what you learned to the test with original AZ-305 exam questions.

Start AZ-305 mock exam

Unlimited mock exams with the Pro plan

PreviousData Protection and EncryptionData Storage NextBackup DesignBusiness Continuity