AWS Confirms Permanent Data Loss in Bahrain and UAE After War Damage — What Multi-AZ Doesn't Cover

On September 15, 2026, Amazon Web Services confirmed that customer data and resources held only in its Middle East (Bahrain) region — me-south-1 — and in one availability zone of its Middle East (UAE) region — me-central-1 — are permanently unrecoverable. The cause was not a software bug or a misconfiguration. It was physical damage from Iranian drone strikes on AWS facilities in the Gulf in March 2026, carried out in retaliation for US-Israeli military operations against Iran. In its Health Dashboard update on Bahrain, AWS says the damage "spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand."

This is a genuinely unusual event for a hyperscaler. Cloud outages happen regularly — bad deploys, DNS failures, control-plane bugs — and are almost always measured in hours, with data intact once services come back. This is different: a hyperscaler is publicly telling customers that data held only in an entire region is gone for good, and the proximate cause was warfare, not engineering failure. We are not aware of a precedent at this scale.

What actually happened, in order

• March 2026: Iranian drone strikes hit AWS infrastructure in the Gulf. In the UAE, AWS says "two of our facilities were directly struck," impairing two of the three availability zones in me-central-1; in Bahrain, "a drone strike in close proximity to one of our facilities caused physical impacts" in me-south-1. AWS advised customers to move workloads to other regions.
• April 2026: A second Bahrain availability zone was disrupted, which took the entire Bahrain region offline, per The Register and Help Net Security. AWS says most customers relocated before the losses became permanent, using backups where available. (InfoQ also reports that Iran's Islamic Revolutionary Guard Corps claimed a second attack on the Bahrain region in July.)
• September 15, 2026: After completing its assessment, AWS posted Health Dashboard updates (reported by CNBC, The Register, InfoQ and others) stating it is "unable to restore access to the resources and data hosted exclusively in this Region" for Bahrain, and specifically unable to restore the mec1-az2 availability zone in the UAE region, while work continues on the other two UAE zones (mec1-az1, mec1-az3) and shared regional infrastructure.

AWS's own framing is worth reading closely: the loss applies to data "hosted exclusively" in the destroyed facilities. Customers who had cross-region replication, off-region backups, or multi-region architectures did not lose data — they lost access to one region and failed over. Customers whose data lived only in Bahrain, or only in that one UAE zone, do not get it back.

Why this isn't just "another outage"

AWS's regional and multi-AZ resilience model is built around correlated failures inside a metro area — a power substation failure, a fiber cut, a single data center fire. Multiple availability zones are deliberately built on physically separate power and network infrastructure so that no single local event takes all of them down at once. In this event, military strikes damaged infrastructure across zones that were meant to be independent for resilience purposes. AWS's statement that the damage "exceeded what our regional and multi-AZ services are designed to withstand" is effectively an admission that the threat model behind multi-AZ availability guarantees — accidents and localized disasters — does not cover coordinated, large-scale physical destruction.

That's the part worth sitting with if you run infrastructure in any region located in a geopolitically volatile area, not just Bahrain or the UAE. Multi-AZ redundancy inside a single region has never been a substitute for a second, geographically distant region for anything you can't afford to lose. This event just made that fact concrete and public instead of theoretical.

The data residency complication

Some coverage (LowEndBox, for one) connected the "hosted exclusively in this Region" phrasing to a real constraint: data residency rules that require certain data to stay within a country's borders. The UAE's health data law is a concrete example — Article 13 of Federal Law No. 2 of 2019 says health data related to health services provided in the UAE may not be stored, processed or transferred outside the UAE unless the health authority or the Minister approves it. For workloads under rules like that, cross-border replication to, say, Europe isn't just an engineering choice — it may not have been legally permitted without an approved exception.

That creates a real tension that doesn't have a clean answer: regulators want sensitive data to stay local for sovereignty and jurisdiction reasons, but "local" now demonstrably includes exposure to catastrophic, unrecoverable loss if the single permitted region is physically destroyed. In-region backup-to-a-second-facility strategies (a second data center in-country, encrypted offline backups held domestically) are the practical mitigation where cross-border replication isn't allowed, but they add cost and operational complexity that many teams skip because "the cloud already replicates my data" is a common and, in this case, false assumption.

What this changes

For teams with anything in me-south-1 or the affected UAE zone: if you have not already treated this as a total loss and rebuilt from your last known-good backup outside the region, do that now — AWS has been explicit that recovery is not coming.

For everyone else, the practical takeaways are less dramatic but more durable:

• Multi-AZ is not disaster recovery. It protects against local infrastructure failure, not regional destruction. If a workload matters, its backups or replicas need to live somewhere that doesn't share a blast radius — a different metro area at minimum, a different country or continent for anything critical.
• "The provider handles resilience" is a shared-responsibility myth. AWS's own shared responsibility model has always put backup and recovery of customer data on the customer, not AWS. This event is the sharpest possible illustration of why that boundary exists — AWS operates the facilities, but data durability beyond a single region's infrastructure is the customer's job.
• Data residency and disaster recovery can conflict, and you need an explicit answer for which wins. If regulation forces single-region storage, the mitigation is in-country redundancy (a second facility, offline/cold backups), not "we'll deal with it later." Treat that gap as a named risk in your architecture review, not an oversight.
• Region selection carries a geopolitical risk dimension now. It was already true that some regions face higher likelihood of natural disaster, grid instability, or political instability. This event makes that a documented, cited factor rather than a hypothetical one when choosing where to run anything you can't afford to lose.

If you're reviewing your own architecture for exactly this kind of single-region exposure and want a second opinion on backup and failover design, see Wise Hustlers' cloud and DevOps services.

Sources

• AWS says it can't restore service to Bahrain, UAE facilities 6 months after Iran strikes - CNBC
• AWS says wartime damage means some Middle East cloud resources are gone for good - The Register
• New UAE Law Regulates Healthcare Data - Latham & Watkins
• AWS Cannot Restore Data Held Only in Damaged Middle East Availability Zones - InfoQ
• Iranian strikes on AWS facilities left customer data beyond recovery in Bahrain, UAE - Help Net Security
• AWS admits permanent data loss after Middle East datacentre strikes - Computing
• AWS confirms unrecoverable data loss in Bahrain and UAE - Inspenet
• When Data Sovereignty Rules Bite You Hard: Some AWS Data in UAE, Bahrain is Gone for Good - LowEndBox