Two zones or three? A design framework for zone-resilient Azure workloads

The material describes a departure from treating zone resiliency as a single, workload-wide setting. Instead of asking 'how many zones should this workload use?', the framework directs engineers to ask 'how many zones does each component need to survive the loss of one?' This change reflects a more nuanced understanding of failure domains, where not all components share the same availability requirements or recovery objectives.

By advocating for per-component decisions, the framework allows engineers to avoid over-provisioning zones for non-critical or easily recoverable components. This can reduce costs and operational overhead, but it also introduces complexity. Engineers must now perform a detailed analysis of each component’s role, dependencies, and failure impact, which may require additional documentation, testing, and monitoring to ensure the design meets overall resiliency goals.

The framework also encourages the use of service-managed zone redundancy where it fits. This suggests that Azure may offer built-in redundancy options for certain services, simplifying implementation for components that align with those patterns. However, the material does not specify which services or components are eligible, leaving engineers to determine applicability on a case-by-case basis. This could create gaps where assumptions about service-managed redundancy do not hold, leading to unexpected failure modes.

Where the framework stops working is in workloads with tightly coupled components or those that rely on synchronous replication across zones. In such cases, the per-component approach may not be sufficient, as the failure of one zone could still cascade through the system despite individual component resiliency. Engineers will need to validate that their chosen zone patterns align with the workload’s overall recovery time and recovery point objectives, particularly in scenarios where multiple components must fail over in concert.