Every cloud architecture review we've sat in ends the same way. Someone asks about disaster recovery, someone else says "it's multi-AZ", and the room moves on. On 15 September 2026 AWS posted the sentence that retires that answer. Its Middle East (Bahrain) region, me-south-1, took drone strike damage across more than one Availability Zone during the Iran war, and after six months of trying, AWS says the resources and data hosted exclusively there can't be restored. Not delayed. Gone. One zone of the UAE region is written off the same way. We've read the dashboard wording, the earlier April update and the reporting from the day, because the difference between "data lost" and "data safe" here comes down to one adverb.
The short answer
AWS says the damage in Bahrain "spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand", and that it's "unable to restore access to the resources and data hosted exclusively" in the region. In the UAE region, me-central-1, the mec1-az2 zone is written off the same way while recovery continues on mec1-az1 and mec1-az3. Customers were told to migrate in March, billing was suspended on 30 April, and the next Bahrain update isn't due until early 2027. If you kept a copy of anything in another region, you're fine. If your only copy sat in me-south-1, it isn't coming back.
What AWS said, and how long it took
The Bahrain region opened in July 2019 with three Availability Zones. The US and Israeli offensive against Iran began on 28 February 2026, and in early March a drone strike near one of the Bahrain facilities damaged the first zone. Two data centres in the UAE region were hit directly in the same period. AWS moved fast on the advice: the Health Dashboard told customers it "strongly recommend[s]" migrating all accessible resources to other Regions and restoring anything inaccessible from remote backups. Most did, according to the September statement, before a second Bahrain zone went down in April and the region stopped being usable at all.
The 30 April update is the one people remember. The region "has suffered damage due to the conflict in the Middle East and is currently unavailable", billing suspended, restoration "expected to take several months". Then nothing on the open issues list for four and a half months. The Service History tab just showed every Bahrain service red, week after week. Honestly, we'd assumed the silence meant a slow rebuild.
It meant an assessment. On 15 September the dashboard entry changed from prolonged recovery to a conclusion, first reported by Reuters. For Bahrain, AWS is unable to restore access to resources and data hosted exclusively in the region, and it says it has "supported the remaining customers in re-establishing their operations in alternate regions". For the UAE, mec1-az2 gets the same verdict while AWS keeps working on regional resources and on the zonal ones in mec1-az1 and mec1-az3. Another UAE update is promised in the coming months. Bahrain gets one in early 2027, with no rebuild date and no reopening promise attached. AWS hasn't published how many customers lost data or how much, and we couldn't find any mention of credits beyond the billing suspension. The MTurk shutdown came with a dated FAQ. This came with a paragraph.
What multi-AZ was ever designed to survive
Here's the line to reread: "exceeded what our regional and multi-AZ services are designed to withstand". That isn't an admission of a design flaw. It's a description of the design. An Availability Zone is one or more data centres with its own power and networking, placed far enough from the region's other zones that a fire or a substation failure takes out one and not the rest. Far enough for a local disaster. Not far enough for a country. The whole region sits inside one small state, and a campaign that targets the facilities themselves hits all of it.
So a Multi-AZ RDS instance and an S3 bucket (which stores objects across at least three zones by default) both did exactly what they were built for, and it wasn't enough. S3's eleven nines of durability is a statement about disk failure inside a region. It has never been a promise about the region existing.
Which brings us back to the adverb. "Hosted exclusively." Cross-Region Replication on the bucket, a snapshot copied to Frankfurt, an RDS automated backup replicated to Ireland, an AWS Backup plan with a copy rule: any one of those makes the data not exclusive to me-south-1, and those customers restored and moved on in March. The ones who lost data are the ones for whom multi-AZ was the entire plan. I might be wrong about the proportion, but from what we've seen of Gulf deployments, data residency rules pushed a lot of teams to keep everything inside the country on purpose. That's a legal constraint colliding with a physical one, and it deserves its own conversation with whoever writes your residency policy.
What to check on your own account this week
None of this needs a new region or a new bill. It needs an inventory of what's exclusive. Start with S3, because that's where the irreplaceable stuff usually lives. List every bucket with the region it sits in:
for b in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do echo "$b $(aws s3api get-bucket-location --bucket "$b" --query LocationConstraint --output text)"; done
Then ask each bucket that matters whether it replicates anywhere. A bucket with no rule returns a ReplicationConfigurationNotFoundError, which is the answer you're looking for, just not the one you want:
aws s3api get-bucket-replication --bucket my-bucket
For EBS, the snapshot lives in the region where you took it. Copying one elsewhere is a single call, run against the destination region, and later copies of the same volume's snapshots are incremental:
aws ec2 copy-snapshot --region eu-west-1 --source-region eu-west-3 --source-snapshot-id snap-0123456789abcdef0 --description "offsite copy"
RDS has cross-Region automated backup replication and cross-Region read replicas. AWS Backup plans take a copy action that targets a second region and can run on a schedule you never think about again. Whichever you pick, the test isn't "do we have backups". It's "delete the region in your head and list what's left". We ran that exercise on our own account after reading the dashboard and found one bucket of build artefacts that would've been gone. Small. Still gone.
One more practical point. Restoring a few terabytes across regions is a bandwidth problem before it's anything else, and the March migration window was measured in weeks, not days. Our data transfer calculator will tell you how long your copy takes at the throughput you actually get. Run it before you need it.
Sources
AWS, AWS Health Dashboard, updates of 30 April and 15 September 2026 (the "unable to restore access" wording, the "exceeded what our regional and multi-AZ services are designed to withstand" sentence, the mec1-az2 verdict, the billing suspension). The National, Amazon Web Services unable to restore Bahrain data network knocked out by Iran, 15 September 2026 (the 28 February start of the offensive, the two March disruptions, the April strike, the early 2027 update). Bloomberg via Insurance Journal, Amazon's AWS Facilities in Bahrain, UAE Still Not Restored From Iran War Damage, 16 September 2026 (the Reuters first report, the coming months UAE update). CircleID, AWS Says Iran Strikes Caused Permanent Customer Data Loss in Bahrain and UAE, 16 September 2026 (the 30 April timeline, the unquantified customer impact). Developing Telecoms, AWS says restoring UAE and Bahrain cloud regions will take several months, 4 May 2026 (the "strongly recommend" migration wording, the two UAE data centres hit directly, the "several months" estimate). CNBC, AWS says it can't restore service to Bahrain, UAE facilities 6 months after Iran strikes, 15 September 2026. The S3 and EBS behaviour is from the AWS documentation as read on 17 September 2026.
Frequently asked questions
Did AWS lose all customer data in the Bahrain region?
AWS says it can't restore resources and data hosted exclusively in me-south-1, meaning data that had no copy in another region. Anything replicated or backed up elsewhere was restorable, and AWS says most customers re-established operations in other regions after the March advice to migrate. The company hasn't said how many customers lost data or how much.
Is the UAE region, me-central-1, also gone?
No. One of its three zones, mec1-az2, is written off with the same "unable to restore" wording. AWS says it's still working on regional resources and on zonal resources in mec1-az1 and mec1-az3, with a further update promised in the coming months. Treat the region as degraded rather than closed until that update lands.
Doesn't multi-AZ protect against this kind of failure?
It protects against one zone failing, which is what zones are placed and powered for. AWS's own wording is that the damage spanned multiple zones and exceeded what multi-AZ services are designed to withstand. Surviving the loss of a whole region needs a copy in another region, through S3 Cross-Region Replication, snapshot copies, RDS cross-Region backups or an AWS Backup copy rule.
Will AWS rebuild or reopen the Bahrain region?
It hasn't said. The 15 September update promises a further Bahrain update in early 2027 and gives no rebuild date and no statement either way on reopening. Billing for the region has been suspended since 30 April 2026.
