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

Takeaway: Zone resiliency isn’t a single number you apply to a whole workload. The useful question isn’t “how many zones?” but “how many zones does each component need to survive the loss of one?” Decide zone patterns component by component, use service-managed zone redundancy wherever it fits, and reserve three-zone designs for the components that genuinely require a third failure domain. For a deeper, decision-oriented walkthrough on choosing between two-zone and three-zone patterns for your specific workloads, see the companion post, Choosing two-zone and three-zone patterns for zone-resilient Azure workloads.

Ask a room of architects how many Microsoft Azure availability zones a production workload needs, and most will answer “three.” It’s a reasonable instinct, but “three zones everywhere” is a rule of thumb standing in for a decision that deserves more thought. Treating it as a default quietly costs you capacity, money, and operational complexity you may not need while occasionally giving you less protection than you assumed.

Zone resiliency is not a property you switch on for an entire workload. It’s a set of decisions you make component by component. Some components are fully protected across two zones. Some genuinely need a third. And for a growing number, Azure manages zone redundancy for you, and the best decision is to let it. This post is about how to tell the difference.

What availability zones protect against (and what they don’t)