The estate had “three zones” written into its landing zone standard like scripture. Every subscription, every tier, every resource. When I traced it through, a chunk of that spend was buying nothing — stateless components spread across three zones that would have survived a zone loss on two, and a couple of stateful services pinned to a single zone because nobody had actually asked the question. The three-zone rule felt safe. It was mostly just expensive, and in the wrong places it was a false sense of security.
Microsoft’s new decision framework this week — Two zones or three — finally says the quiet part out loud: zone resiliency is a per-component decision, not a per-workload one. And the honest answer to “how many zones?” for most of your stack is “two, if you design for it.”
The question isn’t “how resilient do I want to be.” It’s “how many zones does this component need to survive the loss of one and still function?” Those are different questions and they have different answers depending on what the component holds.
Stateless things are easy. A web front end, an API tier, a stateless container app — spread it across two zones with the capacity to run on one, and losing a zone costs you nothing but headroom. There’s no data to reconcile, no vote to lose. Two zones plus n+1 capacity planning meets the RTO because failover is just “the load balancer stops sending traffic to the dead zone.” If you’re running these across three zones, you’re paying for a third copy of compute that does nothing on a normal day and isn’t required on a bad one.
Stateful, replicated systems are where three earns its keep — and it’s not about being extra careful, it’s arithmetic. Anything that maintains consistency through a quorum needs a majority of its members alive to make progress. A three-member cluster survives one loss and still has two of three. A two-member cluster that loses one has no majority, and now you’re in split-brain territory or frozen writes. This is the trap: someone reads “two zones is fine” as workload-wide policy and applies it to a quorum-based database. That’s the component that takes the whole thing down. Consensus systems, primary-with-witness patterns, anything that votes — three zones, non-negotiable.
The part I’d push hardest: for a lot of the stateful layer, you shouldn’t be counting zones at all. When Azure offers service-managed zone redundancy — zone-redundant storage, zone-redundant SQL, a platform tier that handles replication and failover for you — take it. You’re buying the “survive one zone” property as a service SLA instead of engineering it yourself with VMs and hand-rolled quorum. That’s the right default for most teams. Reserve the explicit, self-managed three-zone deployments for the workloads where you genuinely own the data plane.
On cost — I’m not going to quote deltas Microsoft hasn’t published, and neither should the vendor decks you’ve been reading. But the shape is obvious: a third zone of an active-active stateless tier is roughly a third more compute for a resiliency property you already had at two. Regulatory or contractual requirements can override the math — some regimes want the extra margin and that’s a valid reason. “It felt safer” is not.
Where this lands in Cloud Adoption Framework terms: stop encoding “three zones everywhere” as a landing zone guardrail. Encode the question instead. Make component classification — stateless, service-managed-stateful, self-managed-quorum, regulated — part of the architecture review, and let each class carry its own zone target. Your Azure Policy should enforce zone awareness, not a blanket zone count.
The framework isn’t telling you to spend less. It’s telling you to spend where a zone failure would actually hurt. Most estates I’ve seen have that exactly backwards — three zones on the tier that didn’t need it, one zone on the tier that quietly did.
