AWS Lost a Region for Good: Multi-AZ Is Not Disaster Recovery
AWS says it cannot restore data held only in Bahrain (me-south-1) or in one UAE zone. Multi-AZ gave availability, not recovery, and only cross-region copies survived.
Key takeaways
- AWS says it cannot restore resources and data held only in its Bahrain region, me-south-1, or only in the UAE zone mec1-az2 after drone-strike damage in March 2026.
- Multi-AZ protects against losing a facility, not a region.
- Disaster recovery needs a restorable copy of your data in a second region.
On this page
AWS says it cannot restore resources and data held only in its Bahrain region (me-south-1) or only in the UAE zone mec1-az2, after drone-strike damage that began in March 2026. If your only copy lived there, it is gone. Multi-AZ is an availability feature. It was never disaster recovery: that takes a restorable copy in another region.
Verified against
AWS CLI 2.39.3, against the AWS docs for S3 replication, AWS Backup cross-Region copies and RDS cross-Region read replicas, plus press reports of AWS's 15 September health updates. Checked October 2026.
The damage in Bahrain, AWS wrote, "exceeded what our regional and multi-AZ services are designed to withstand." That sentence is the whole lesson.
What AWS actually said, and when
We are being careful with dates because we could not open the AWS health dashboard entries directly. Press coverage (Help Net Security, among others) reports that AWS posted two health-dashboard updates on 15 September 2026, covering both Bahrain and the UAE, more than six months after the strikes began. InfoQ's write-up ran on 21 September. We treat 15 September as the date of AWS's statements and leave it there.
The facts that every outlet agrees on: the damage began in March 2026. In Bahrain, AWS determined it could not restore resources and data hosted exclusively in the region. In the UAE, the unrecoverable scope is a single zone, mec1-az2, while AWS says it continues working on mec1-az1 and mec1-az3. AWS also said most affected customers had already moved out, "using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data." Its advice to the rest is to migrate to another region and rebuild from backups or accessible data. AWS has said it expects to share more on Bahrain in early 2027.
Multi-AZ answers a different question
Multi-AZ synchronous replication protects you from a rack, a power feed, or a single facility going dark. That is the failure it was designed for, and it is very good at it when failover is actually tested, which the eu-south-2 single-AZ brownout suggests is rarer than teams assume. Availability zones in a region sit close together for latency, share a control plane, and share a legal jurisdiction. A single event large enough to hit several zones defeats the design, which is exactly what AWS says happened in Bahrain. Even one zone can drag a region down: the europe-west2 power outage stalled London for six hours.
The mistake we see is treating "Multi-AZ: enabled" on an RDS instance as a line item under disaster recovery. It belongs under high availability. Disaster recovery starts at the question "what if this entire region is unreachable, permanently, and I cannot ask AWS for anything?" Only a copy in another region, ideally under a separate account or vault, answers that question. Most teams do not need to run hot in two regions, which we cover in multi-region active-active versus active-passive. Almost all of them need a cold copy of their data in a second one.
Find the data that exists in exactly one region
Start with an inventory, because nobody knows offhand which buckets and databases have a copy elsewhere. S3 is the easy first pass. This lists every bucket with no replication configuration:
for b in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
aws s3api get-bucket-replication --bucket "$b" >/dev/null 2>&1 || echo "NO-CRR $b"
done
Some listed data is reproducible, so make the call deliberately. Then check RDS for instances with no cross-region replica:
aws rds describe-db-instances \
--query 'DBInstances[].[DBInstanceIdentifier,MultiAZ,ReadReplicaDBInstanceIdentifiers]' \
--output table
A True in the MultiAZ column with an empty replica list is the exact pattern that does not survive a region loss. Repeat for EBS snapshots, DynamoDB tables, and anything in EFS. If regulation pins the data to one country, a second in-country region may not exist, so plan a customer-held copy instead.
Put a copy somewhere else, this week
For S3, enable versioning on both buckets and add a replication rule. S3 Cross-Region Replication only copies objects written after the rule exists, so use S3 Batch Replication for the backlog.
aws s3api put-bucket-versioning --bucket my-dr-bucket-eu \
--versioning-configuration Status=Enabled
aws s3api put-bucket-replication --bucket my-prod-bucket \
--replication-configuration file://replication.json
Here replication.json holds an IAM Role that S3 can assume and one rule whose Destination.Bucket is the ARN of the target bucket. For everything else, AWS Backup is the least effort: add a copy action to your backup plan that targets a vault in another region, or run one by hand with aws backup start-copy-job --recovery-point-arn <arn> --source-backup-vault-name Default --destination-backup-vault-arn <arn> --iam-role-arn <arn>. For a database you want warm rather than merely restorable, create a cross-region RDS read replica. You run it from the destination region and pass the source as an ARN:
aws rds create-db-instance-read-replica \
--region eu-west-1 \
--db-instance-identifier orders-dr \
--source-db-instance-identifier arn:aws:rds:me-central-1:123456789012:db:orders \
--kms-key-id <key-in-eu-west-1> # required if the source is encrypted
AWS notes the initial copy can take hours, and cross-region replicas lag more than in-region ones. Route 53 health checks can then drive the actual cutover, which we walked through in multi-region failover with Route 53 health checks.
A copy you have never restored is a hope
AWS said most affected customers moved using backups where they had them. That only works if the backups existed and could be restored into a different region with different KMS keys, VPCs, and quotas. Regional resources such as KMS keys, IAM roles, and AMIs do not follow the data unless you made them. Schedule a restore into the second region, time it, and write the number down. Our guide to testing database backup restores has a runnable drill. Whatever the drill takes is your real recovery time, whatever the runbook claims.
Questions people ask
Is Multi-AZ enough for disaster recovery on AWS?
No. Multi-AZ keeps a synchronous standby in another availability zone of the same region, which covers a failed rack, power feed or facility. It does nothing if the whole region is lost or unreachable, which is what AWS says happened in Bahrain. Disaster recovery needs at least one copy of your data in a second region, restored on a schedule.
What happened to the AWS Bahrain region?
Drone strikes in March 2026 damaged AWS facilities in Bahrain and the UAE. On 15 September 2026, AWS said it cannot restore resources and data hosted exclusively in me-south-1, or exclusively in the UAE zone mec1-az2. Customers with backups or replicas in other regions could rebuild; data held only there has no recovery path.
What is the cheapest way to get cross-region DR on AWS?
A cold copy. Add a copy rule to an AWS Backup plan that targets a vault in another region, and turn on S3 Cross-Region Replication plus a one-off Batch Replication for existing objects. You pay for storage and transfer, not idle compute. Warm replicas and active-active setups cost more and are optional for most workloads.
The decision, concretely
- Is any production data stored in one region only? List it with the commands above and assign each item an owner and a decision: replicate, back up cross-region, or accept the loss in writing.
- Is "Multi-AZ" the entire DR plan for a database? No. Add a cross-region replica or an AWS Backup copy to another region this week.
- Are your cross-region copies untested? Restore one into the target region, with its keys and network, and record the elapsed time.
- Does residency law block a second region? Then design the exit plan now: a customer-held encrypted export, or a second provider in the same country.
The call we'd make
Treat a region as a failure domain that can be lost permanently, because AWS has now said in public that one was. Keep multi-AZ for availability and add one cross-region copy of every dataset you cannot recreate, restored on a schedule. Hot multi-region is optional and expensive. The cold copy is not optional. The caveat is residency: where the law keeps data in one country, the exit plan is the DR plan, and it needs to exist before you need it.
Sources
Cite this article
Kiril Urbonas (2026). AWS Lost a Region for Good: Multi-AZ Is Not Disaster Recovery. DevOpsNess. Updated 2026-10-31. https://www.devopsness.com/blog/aws-bahrain-region-lost-multi-az-is-not-dr
[AWS Lost a Region for Good: Multi-AZ Is Not Disaster Recovery](https://www.devopsness.com/blog/aws-bahrain-region-lost-multi-az-is-not-dr) (Kiril Urbonas, DevOpsNess, updated 2026-10-31)
More from Cloud
Explore more articles in this category
.NET 8 Support Ends November 10: The Lambda and Azure Functions Checklist
.NET 8, .NET 9, the Lambda dotnet8 runtime and the Azure Functions in-process model all lose support on November 10, 2026. Inventory commands, the isolated-worker migration and a CI gate.
Google Cloud's europe-west2 Outage: One Zone Lost Power and the Region Stalled for 6 Hours
On October 20, 2026, europe-west2-b lost power when its generators never started. Cross-zone control-plane timeouts then degraded the whole London region. What happened and the gcloud audit to run now.
Lambda Python 3.10 Is Deprecated Today: Find Every Function and Move to 3.13
AWS deprecated the Lambda python3.10 runtime on October 31, 2026. Functions keep running, patches stop. The inventory commands, IaC diffs and AL2023 gotchas for moving to python3.13.
You might have missed
Evergreen posts worth revisiting.