# AWS Lost a Region for Good: Multi-AZ Is Not Disaster Recovery URL: https://www.devopsness.com/blog/aws-bahrain-region-lost-multi-az-is-not-dr Author: Kiril Urbonas Published: 2026-09-15 Updated: 2026-10-31 Categories: Cloud Tags: AWS, Disaster Recovery, Reliability, Operations, Cloud Summary: 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. --- # AWS Lost a Region for Good: Multi-AZ Is Not Disaster Recovery 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] > 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](/blog/aws-eu-south-2-packet-loss-single-az-lesson) 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](/blog/google-cloud-europe-west2-power-outage-october-20-zonal-lessons) 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](/blog/multi-region-active-active-vs-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: ```bash $ 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: ```bash $ 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. ```bash $ 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 --source-backup-vault-name Default --destination-backup-vault-arn --iam-role-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: ```bash $ 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 # 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](/blog/multi-region-failover-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](/blog/database-backup-restoration-testing-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 - [Replicating objects within and across Regions (Amazon S3 User Guide)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) - [Creating backup copies across AWS Regions (AWS Backup Developer Guide)](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html) - [Creating a read replica in a different AWS Region (Amazon RDS User Guide)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html) - [Disaster recovery options in the cloud (AWS whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)