Multi-AZ Is Not a Recoverability Boundary

A recoverability boundary is not the same thing as an availability boundary, and AWS just proved it the expensive way. On September 15, 2026, AWS updated its Health Dashboard to confirm permanent, unrecoverable data loss across all three Availability Zones in its Bahrain region (me-south-1) and one Availability Zone in its UAE region (mec1-az2, part of me-central-1) — not a temporary outage, not degraded service, but data that will not come back. The company’s own language was unusually direct: the damage in Bahrain “exceeded what our regional and multi-AZ services are designed to withstand.”

That sentence is the entire architecture lesson. AWS isn’t describing a bug. It’s describing a boundary — the largest failure domain its multi-AZ design was built to survive — and confirming that this event sat outside it. Every enterprise that has ever pointed to “we run multi-AZ” as evidence of recovery readiness now has a concrete instance of that assumption failing in production, with a named cause: physical damage during strikes on Gulf infrastructure in March 2026, followed by further damage to a second Bahrain facility in April that took the entire region offline.

Redundancy can preserve availability without preserving recoverability. Bahrain is the proof, not the argument.

What Multi-AZ Actually Assumes

Multi-AZ architecture rests on a specific, usually unstated assumption: that the Availability Zones within a region are independent enough — electrically, physically, on the network — that no single event takes out more than one of them at a time. That assumption is what allows multi-AZ to preserve service continuity during localized failures. If AZs share nothing that matters, then a failure in one doesn’t propagate to the others, and the workload keeps running — or worst case, fails over cleanly within the region.

The assumption has a scope. It was built against a specific class of failure: power loss, hardware failure, a botched deployment, a single-facility fire. It was not designed to make multiple physical facilities across two regions immune to a common external cause. AWS’s own multi-AZ design tolerance has a ceiling, and every enterprise architecture built on top of it inherits that same ceiling whether or not anyone ever wrote it down.

Where the Recoverability Boundary Actually Sits

Bahrain exceeded that ceiling on two axes at once. First, scope: the damage was not confined to a single Availability Zone or a single facility. AWS ultimately confirmed unrecoverable resources across all three Bahrain Availability Zones and an affected UAE zone, placing the impact outside the failure domain most enterprises associate with multi-AZ resilience. Second, cause: this wasn’t a random hardware failure distributed by chance across independent facilities. It traces to three AWS facilities across two regions, damaged in connection with the same underlying conflict. A shared cause reaching multiple “independent” zones is exactly the scenario multi-AZ isolation is supposed to make statistically unlikely — and exactly the scenario that, once it happens, reveals the isolation was never absolute to begin with.

This is where the recoverability boundary question gets concrete. The recoverability boundary isn’t a marketing claim about how many AZs a service spans. It’s the actual, specific size and shape of the failure that the cloud architecture — provider design plus enterprise recovery plan layered on top — was built to survive. AWS’s had a boundary. Bahrain sat outside it.

That’s a different question than whether a recovery plan’s scope was complete — whether every dependency required to operate sat inside the boundary that was drawn. Bahrain is a magnitude question: the failure domain exceeded what the boundary, however completely drawn, was ever designed to survive.

Why Same-Region Copies Can Share a Failure Domain

Distance does not define the failure domain — shared dependency does. That’s not a new principle; it’s the same one a wildfire exposed in mission-critical infrastructure earlier this year, when geographic separation on paper turned out to share enough underlying infrastructure to fail together anyway. Bahrain is a different failure mechanism — infrastructure damage tied to conflict, not fire — arriving at the identical architectural conclusion: two facilities being in different buildings, or different AZs, or even different regions, tells you nothing about whether they share the dependency that actually breaks.

Three AWS facilities across two separate regions were affected by the same underlying cause. That’s not a multi-AZ failure in the narrow sense — it’s a failure-domain-modeling failure. The recovery plan assumed the boundary was regional distance. The actual boundary was something else: physical reachability by a single class of threat.

The same mapping gap surfaced in August at smaller scale. GCP’s us-west1 outage traced one compromised fiber path through shared consensus and metadata infrastructure into more than two dozen customer-facing services — a failure domain inside a single region that no service list showed. Bahrain asks the same question one level up: not which services share a region’s infrastructure, but whether the region itself sits inside a larger failure domain than the architecture assumed.

Backup and Redundancy Aren’t Interchangeable

Multi-AZ redundancy is designed to answer one question: does the workload stay available if one zone goes down? It answers that question well. It does not, on its own, answer a second and different question: if the data itself stops existing, is there an independent copy of it that survives the same event? Those are different failure modes, and conflating them is where “we have redundancy” quietly becomes “we assumed we had recovery.”

That’s a narrower, more upstream version of a gap already documented elsewhere on this site: most recovery plans get tested against systems that survive but can’t be restarted, not systems whose data has simply ceased to exist within the boundary the recovery plan was scoped to. Bahrain is the more severe case — not “recovery execution failed,” but “there was nothing left within reach to execute recovery against.” Redundancy protected availability while the event was survivable. It did not protect recoverability once the event exceeded what the region was designed to withstand.

AWS’s architecture defines the resilience boundary of the platform; enterprise recovery architecture determines whether an independent recoverability boundary exists beyond it.

Availability and Recoverability Are Different Design Goals

This is the sentence the rest of the piece has been building toward: an architecture can remain highly available under every failure it was designed for, and still be structurally incapable of recovery under a failure domain larger than the one its designers assumed.

Those aren’t two phrasings of the same property. Availability is a statement about uptime under expected failure classes. Recoverability is a statement about what survives when a failure exceeds that class entirely. Multi-AZ is genuinely excellent at the first. Bahrain is what happens when an enterprise’s recovery planning quietly borrowed the first as evidence for the second, without ever checking whether the provider’s own design tolerance and the enterprise’s own risk tolerance were the same number.

Why Residency Constraints Complicate the Answer

Even where this gets diagnosed correctly, “put another copy somewhere else” is incomplete advice the moment jurisdiction enters the picture. Data-residency requirements narrow where a recovery copy is legally allowed to live, which narrows the failure-domain size that copy can actually protect against, which in turn constrains the replication topology available to close the gap. A jurisdiction that requires data to remain inside a country may rule out the simplest answer — replicating to a distant geography outside the threat radius — before the architecture conversation even starts. Recovery geography stops being a technical convenience and becomes an architecture constraint in its own right.

Each layer protects against a progressively larger and more constrained class of failure. None of them are the same guarantee, and a provider’s own resilience messaging rarely tells you which layer you’re actually standing on — a limitation worth remembering the next time an SLA gets read as a recoverability commitment rather than an availability one.

The Architect’s Test

None of this requires distrusting AWS, or redundancy, or multi-AZ design generally. It requires one honest question, asked before the next Bahrain rather than after it:

Not the largest failure domain the marketing describes. Not the largest failure domain that’s ever actually occurred. The largest one the architecture — as built, as tested, as scoped by jurisdiction and topology — was deliberately designed to survive. Inside that boundary, you have a recovery architecture. Beyond it, you have an availability architecture being asked to solve a recovery problem it was never designed to handle.

Additional Resources

View 1 more resource ↓

>_ External Reference

Reuters: AWS facilities in Bahrain, UAE still not restored from Iran war damage

independent confirmation of the March/April 2026 strike timeline and the scope of AWS’s own status update.