Azure Workload Zone Resiliency: Component-Based Design for Two or Three Zones

Rethinking Azure Zone Resiliency

The common assumption that all production Azure workloads require three availability zones is an oversimplification. This approach can lead to unnecessary costs, increased operational complexity, and sometimes provide less protection than anticipated. Instead, zone resiliency should be determined on a component-by-component basis within a workload.

Component-Specific Zone Decisions

Not all workload components have the same resiliency requirements. Some components may be adequately protected across two zones, while others genuinely necessitate a third failure domain. Additionally, a growing number of Azure services offer service-managed zone redundancy, where Azure handles replication, request distribution, and failover, which should be the default choice when it meets requirements.

Understanding Availability Zone Protection

Azure availability zones consist of separate datacenter groups within a region, each with independent power, cooling, and networking. Zone resiliency protects against the loss of a single zone, but it does not protect against the loss of an entire region. Mission-critical workloads requiring disaster recovery also need a multi-region strategy.

Azure services implement zone usage in two ways: zone-redundant resources are spread and managed across zones by Azure, while zonal resources are pinned to a single zone, offering isolation from other zone failures but not automatic failover.

Strategic Zone Implementation

The framework suggests prioritizing service-managed zone redundancy for components where it is available and meets requirements. Two-zone designs are sufficient for many components. Three-zone designs should be reserved for components that have a clear and genuine need for a third failure domain to ensure survival against a single zone loss.