Amazon Web Services (AWS) cannot give customers their data back from its Middle East (Bahrain) region. Its status page says the damage spanned multiple Availability Zones (AZs) and “exceeded what our regional and multi-AZ services are designed to withstand” [1]. Its service list runs to 144 disrupted items. AWS adds that it is “unable to restore access to the resources and data hosted exclusively in this Region” [1].

The same 15 September 2026 statement declared one zone in the United Arab Emirates (UAE) region lost as well [1]. The loss is narrow but total: AWS cannot recover data that lacks a copy outside the region.

The big picture:

This is not an outage that ran long. AWS has not run out of time. It is simply out of options. The status page says the company checked every damaged site and “exhausted every option” to restore data [1]. More detail is promised in early 2027.

I keep coming back to what this backup plan was built to survive. AWS’s own fault-isolation paper spaces AZs “up to 60 miles (~100 km)” apart [2]. The dangers they are made to outlast are listed there: power cuts, water loss, fiber cuts, earthquakes, fires, tornadoes, floods [2].

Every one of those is an accident of gear or nature. What arrived in March 2026 was physical damage to several buildings in one night. AWS ties this to the conflict in the Middle East [1].

The company had written down exactly what its design could take. Amazon Simple Storage Service (S3) is “designed to withstand the total loss of a single Availability Zone (AZ)” [1]. That held at first. When a second zone in the UAE went dark, S3 error rates spiked.

Buyers of multi-zone cover inside one provider paid to beat a short list of disasters. The failure that arrived was not on the list.

By the numbers

  • 144 — Disrupted Bahrain services: AWS lists 144 services as disrupted for the Bahrain event, and 135 for the UAE event [1]. It states that the region’s data cannot be recovered.
  • ~100 km — Design distance: Zones sit up to 60 miles apart [2]. That is close enough for live copying, but far enough to beat the dangers AWS lists in its design paper.
  • 12 hours 30 minutes — Second ceiling: Google’s us-central1 Cloud Storage writes fell over for 12 hours and 30 minutes on October 8, 2026. Staff tried to add emergency space but were “blocked by systemic regional capacity limits” [3].
  • Early 2027 — Next answer: AWS paused billing for the region and expects repairs to take months [1]. Detail on Bahrain follows in early 2027.

What I’d watch:

The reflex after a story like this is to buy a second zone or a second vendor. Both are real moves, but neither is the one that gets tested. I am watching the data copy, and where that copy is legally allowed to sit.

AWS points customers to other regions and tells them to rebuild from “remote backups.” It says to pick regions based on “your latency and data residency requirements” [1]. That last clause is the whole problem. It is a legal question wearing an engineering costume.

  • The residency limit: For regulated data, the backup that saves a company may sit in a country that will not let them store it. Where that is true, the gap is a limit on the design, and it belongs in a risk list [4].
  • The restore, not the copy: Live copying keeps a second version warm. A backup nobody has ever rebuilt from is just a hope with a calendar entry.
  • The way back: A rebuild that needs the dead region’s own console or keys is not a way back at all. AWS worked to restore the tools that let customers move data out [1].
  • Who owns what: The provider runs the building, but the customer owns the data inside it. The Bahrain statement draws that line in public [1].

The catch

My read is that the market will over-read this in one direction and under-read it in the other.

This is not proof that the cloud is a bad buy. Cost is why most of this work sits there. The fair counter-argument is that moving back to private servers often does not pay. Northdoor’s Martin Summerhayes told a trade paper that “a lot of cloud repatriation projects are actually FinOps projects in disguise” — financial operations work, not design [6].

The part I keep circling is what the event does not prove. Zones were never sold as cover against a physical strike on several buildings in one night. The design paper clearly states it covers a fixed list of accidents [2].

No provider can promise to beat an attacker. What a provider can promise is honesty about the scope of cover, and this statement is unusually clear on that point.

Where I have landed: the useful question is not whether a region can fail. It is whether anything you own lives in exactly one place, and whether the rules let you put a second copy somewhere else. A multi-zone setup answers the first question well, but it cannot answer the second one at all.

At a glance

  • The Big Shift: AWS told customers that data kept only in its Middle East (Bahrain) region cannot be recovered [1]. It also declared a zone in its United Arab Emirates (UAE) region lost, after damage beat what its services were built to survive.
  • Why It Matters: The safety promise behind multi-zone cover is written against a fixed list of dangers. The event that broke it was not on that list. A region’s data, not just its uptime, can be a single point of failure.
  • What I’d Watch: Whether teams test the way back, rather than just the live copy. And whether the second copy may legally sit where it is needed.
  • Rebuild drills: Moving a backup into another region and starting it, on a clock, on a schedule. This is the only proof a backup works.
  • Residency checks: Getting a legal answer, not an engineering guess, on which countries a data copy may sit in.
  • Region independence: Making sure the way back does not lean on the console, keys or network of the region being recovered.
  • The Catch: Moving everything back to private servers is not automatically the fix. The cost case for staying in the cloud is often strong. And the copies that save you may be the copies your data rules forbid.

Related reading

Sources

[1] AWS Health Dashboard, service health — continued-disruption entries for Middle East (Bahrain) me-south-1 and Middle East (UAE) me-central-1, including the 2026-09-15 determinations, the 2026-04-30 billing suspension and the 2026-03-02 physical-cause statement — https://health.aws.amazon.com/health/status [2] AWS, Fault Isolation Boundaries whitepaper, “Availability Zones” — https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html [3] Google Cloud Service Health, incident report, Cloud Storage, us-central1, 2026-10-08 — https://status.cloud.google.com/incidents/mSFVt6PiP557bjRyYsut [4] InfoQ, “AWS Cannot Restore Data Held Only in Damaged Middle East Availability Zones”, 2026-09-21 — https://www.infoq.com/news/2026/09/aws-middle-east-data-loss [5] Reuters, “Amazon’s AWS is unable to restore access to Bahrain, one UAE cloud data zone after war”, 2026-09-15 — https://www.reuters.com/world/middle-east/amazons-aws-is-unable-restore-access-bahrain-one-uae-cloud-data-zone-after-war-2026-09-15 [6] ZDNET, “Companies are ditching the cloud to save millions – should you?”, 2026-10-05 — https://www.zdnet.com/tech/cloud-repatriation-enterprise-cost-optimization