4.1.3.1. Design for Azure Availability Zones
4.1.3.1. Design for Azure Availability Zones
💡 First Principle: Distributing resources across physically separate locations within a single region, each with independent infrastructure, is the fundamental strategy for achieving high availability and resilience against datacenter-level failures.
Scenario: You are designing a mission-critical web application. This application needs to maintain continuous availability even if an entire datacenter in an Azure Region experiences an outage. You need to ensure both your Virtual Machines and your database (Azure SQL Database) are protected.
Availability Zones are unique physical locations within an Azure Region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking.
Key Design Considerations:
- Fault Isolation: Each zone is an independent datacenter. Deploying resources across zones protects against localized failures.
- Zone-Redundant vs. Zonal Resources:
- Zone-redundant resources (e.g., Azure SQL Database, zone-redundant storage) are automatically replicated across multiple zones by Azure.
- Zonal resources (e.g., Virtual Machines) are pinned to a specific zone, requiring manual distribution for redundancy.
- Latency: While zones are close enough to support low-latency synchronous replication, some intra-zone latency may exist.
- Supported Services: Not all Azure services support Availability Zones. Key services include Virtual Machines, Azure Kubernetes Service, Load Balancer, SQL Database, and Storage Accounts.
- Cost Implications: Zone-redundant deployments may incur higher costs due to cross-zone data transfer and resource replication.
Design decisions in practice:
| Decision | Guidance |
|---|---|
| Zonal or zone-redundant | Zonal pins a resource to one named zone, which you choose deliberately when co-locating for latency. Zone-redundant spreads it across zones automatically and is the default for availability |
| Capacity headroom | Spreading across three zones only helps if the surviving two can carry the whole load. Size for N+1 zones, or the failure of one zone saturates the rest |
| Which services | Some are zone-redundant by configuration (Storage via ZRS, Azure SQL via a setting), some require you to place instances per zone (VMs, scale sets), and some are zone-redundant inherently |
| Paired resources | A zone-redundant application in front of a zonal database inherits the database's exposure. The weakest tier sets the availability of the whole |
Inter-zone latency is low enough for SYNCHRONOUS replication, and that is the entire reason zones exist. It means the loss of a datacenter can be absorbed with no data loss and no failover event, which no cross-region design can offer — the distance makes cross-region replication asynchronous, and therefore lossy.
⚠️ Exam Trap: zone numbers are logical per subscription. Zone 1 in your subscription is not necessarily the same physical datacenter as Zone 1 in someone else's, which matters when co-locating resources across subscriptions.
⚠️ Common Pitfall: Not all Azure Regions support Availability Zones. Always verify regional capabilities before designing a solution that depends on them.
Key Trade-Offs:
- Resilience vs. Cost: A multi-AZ deployment is more resilient than a single-zone deployment but incurs costs for data transfer between zones.
Reflection Question: How does designing for Azure Availability Zones, specifically by distributing zonal resources (VMs) and leveraging zone-redundant resources (SQL Database), fundamentally provide high availability and fault tolerance against datacenter-level failures, ensuring application continuity?
