AWS Lost a Region for Good: Multi-AZ Is Not Disaster Recovery

AWS has said it cannot restore access to resources and data hosted exclusively in its Middle East (Bahrain) me-south-1 region, or in the mec1-az2 availability zone of the UAE me-central-1 region, after damage from drone strikes in March 2026. The damage in Bahrain, AWS wrote, "exceeded what our regional and multi-AZ services are designed to withstand." If your only copy of anything lived there, it is gone. Multi-AZ is an availability feature. It was never disaster recovery.

What AWS actually said, and when#

We are being careful with dates because the coverage disagrees. CNBC reported on 15 September 2026 that AWS had posted updates to its health dashboard for both Bahrain and the UAE, the first public update since April, more than six months after the strikes. InfoQ's write-up dates AWS's confirmation of the UAE data loss to 21 September. We could not open the AWS health dashboard entries directly, so we treat 15 September as the date the Bahrain and UAE statements first drew press coverage 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 resumed operations in other regions by restoring backups, copying data that remained accessible, or using alternative solutions. Its advice to the rest is to migrate to another region and rebuild from backups or accessible data.

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. 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.

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 with aws rds create-db-instance-read-replica --region eu-west-1 --source-region me-south-1, adding --kms-key-id if the source is encrypted. 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 recovered by restoring backups. That means 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.

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.