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.
Learn architecture strategies for availability zones and regions What availability zones protect against (and what they don’t) An Azure region that supports availability zones is made up of separate groups of datacenters, each with independent power, cooling, and networking. Zone resiliency protects you against the loss of one of those zones. It does not protect you against the loss of the entire region.
If your workload is mission-critical or carries strict disaster-recovery requirements, zones are necessary but not sufficient: you also need a multi-region conversation, and that’s a separate design exercise. It’s worth being precise about what “using zones” means, because Azure services expose it in two different ways: Zone-redundant resources are spread or replicated across zones by Azure itself.
Azure handles the replication, request distribution, and failover. Where a service offers zone redundancy and it meets your requirements, it should generally be the starting point, especially for production workloads. Zonal resources are pinned to one zone.
A zonal resource is isolated from failures in other zones, but it is not automatically resilient to a failure in its own. To make a zonal design resilient, you deploy instances across zones yourself and own the routing, replication, failure detection, and recovery. That distinction matters, because reliability on Azure is a shared responsibility.
The resilience of a zone-redundant service is Microsoft’s responsibility to deliver; the resilience of a zonal design you assemble yourself is largely yours to configure and prove. No layer makes up for a gap in another. Decide at the component level, not the workload level The reason “three zones everywhere” may not be the correct starting point is that a workload is not one thing.
It’s a stateless front end, an application tier, a queue, a cache, a relational database, an object store, and often a quorum-based system or two each with different failure behavior. Applying one zone count to all of them optimizes for none of them. Break the workload down by critical flow, then by component, and ask three questions of each: Resource availability: If one zone goes down, can the remaining zone or zones carry the operating state you need?
For a single-zone failure, two zones and three zones can both meet the objective. The third zone does not, by itself, make a component resilient to more than one zone failure in the same region. Data consistency and durability: Does the component’s correctness depend on a third failure domain?
Quorum, consensus, leader election, split-brain prevention, and the highest durability targets often do. Cost and capacity: For the same post-failure performance, recovery capacity is distributed differently across two zones versus three. Decide the resiliency objective first, then optimize cost, not the other way around.
One subtlety worth flagging: If more than one zone is unavailable in the same region at once, your problem has usually stopped being a workload problem and become a regional one: foundational regional services themselves depend on surviving zones. Designing past a single-zone failure puts you in disaster-recovery territory, which is a different conversation.
A starting point: Where common components tend to land Most components fall into one of a few buckets. Treat this as a first read, not a support matrix. Zone behavior varies by service, SKU, tier, region, and configuration, so always validate against the service’s own reliability guidance.
Component type Typical zone decision Stateless compute, application, or network components (no persistent data) Two or three zones, based on remaining capacity, routing, latency, and operations. Both can meet a single-zone objective. Stateful systems using quorum, consensus, or leader election Three zones, a third failure domain, or a product-specific witness pattern to avoid split-brain and quorum loss.
Critical data stores needing three replicas for the highest durability targets Three-zone replication is often required to reach the intended durability level. Validate the service’s specific claims. Other stateful resources Two-zone, three-zone, or service-managed, depending on recovery time objective (RTO), recovery point objective (RPO), durability, and failover behavior.
Anything Azure can make zone-redundant for you Use service-managed zone redundancy when it meets your requirements. Where two zones are enough Two zones is not a compromise.
Originally published at azure.microsoft.com
