Skip to content
Quick summary
- In September 2026, more than six months after drones damaged data centers in the Middle East, AWS confirmed it can’t restore data held only in its Bahrain Region (me-south-1), or only in one zone of its UAE Region (mec1-az2).
- Multi-AZ protects you from losing one data center. A Region-wide loss takes out every AZ at once.
- The teams that had recoverable workloads had a copy in another Region, account or cloud, and a way to rebuild the environment around it.
When an Availability Zone isn’t enough
AWS designs Availability Zones (AZs) to withstand localized failures such as fires, floods, power outages, or cooling failures. Multi-AZ deployments distribute workloads across AZs within the same Region to keep applications running when one facility fails.
The March 2026 attacks in Bahrain and the UAE showed the limits of this approach. In Bahrain, multiple AZs were affected, taking down the entire Region. In the UAE, resources in mec1-az2 were reportedly unrecoverable, while recovery of the other AZs was complicated by capacity constraints.
The key lesson is that Multi-AZ protects against AZ-level failures, not Region-wide disasters. Organizations need multi-Region disaster recovery, with data and infrastructure replicated outside the primary Region.
Six months later, AWS confirmed it could not restore data hosted exclusively in Bahrain. Multi-AZ had worked as designed. The problem was that the multi-regional disaster recovery playbook, for many enterprise teams, was not put into place.
Multi-AZ vs multi-region: what each one survives
| Failure | Single AZ | Multi-AZ | Multi-region, same account | Cross-region + cross-account | Cross-cloud copy |
|---|---|---|---|---|---|
| One instance or disk fails | Recover from backup | Keeps running | Keeps running | Keeps running | Keeps running |
| One AZ is lost (UAE, mec1-az2) | Data held only there is lost | May run in the other AZs (provided they are not overloaded) | Survives | Survives | Survives |
| The whole Region is lost (Bahrain, me-south-1) | Lost | Lost | Survives if copies were replicated | Survives | Survives |
| Account credentials compromised | Exposed | Exposed | Exposed, same account | Survives, separate credentials | Survives, separate provider |
| Provider-wide control-plane failure | Exposed | Exposed | Exposed | Exposed | Survives |
AWS puts every Availability Zone in a Region within 100 km (60 miles) of the others, each with independent power, cooling and physical security. That design handles a power failure, a flood or a fire in one building very well. It was never meant to handle damage across a whole metro area, and AWS said exactly that about Bahrain.
What happened to AWS’s Middle East Regions
| When | What happened | Source |
|---|---|---|
| March 2026 | Drone strikes, which Iran’s Islamic Revolutionary Guard Corps claimed, directly hit two AWS facilities in the UAE and damaged a facility in Bahrain through a nearby blast. AWS advised customers to move their workloads to other Regions. | CNBC, The Register |
| April 2026 | A second Bahrain Availability Zone was disrupted, and me-south-1 went offline as a whole Region. | The Register, Help Net Security |
| September 2026 | In an AWS Health Dashboard update, AWS said it can’t restore access to resources and data hosted exclusively in me-south-1, or exclusively in mec1-az2 in the UAE. Work on the other two UAE zones continues. | The Register, DCD |
AWS’s own words on Bahrain:
“After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region.”
“The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand.”
And its advice to customers:
“Customers should enact their disaster recovery plans, recover from remote backups stored in other Regions, and update their applications to direct traffic away from the affected Regions.”
AWS also said most customers had relocated before the losses became permanent, “using backups where available or implementing alternative solutions.”
This is a different kind of event from the ones on most AWS outage timelines. The October 2025 us-east-1 outage lasted about 15 hours and hit thousands of companies, but when it ended, the data was still there. In Bahrain, a Region went down in April and customers got a final answer in September. Anyone whose plan was “wait for AWS to bring it back” waited five months to learn it wasn’t coming back.
Tier 1: losing one Availability Zone (the UAE case)
AWS’s wording is precise: it can’t restore data hosted exclusively in mec1-az2. So the question for your own estate is which resources live in exactly one AZ.
What lives in a single AZ
- EBS volumes. A volume belongs to the AZ it was created in.
- EC2 instance store. Gone the moment the host is.
- A Single-AZ RDS instance. RDS Multi-AZ exists because of this.
- S3 One Zone storage classes. Cheaper because they skip the multi-AZ copies.
- Subnets. Each one maps to a single AZ.
What’s regional, and would have outlived one zone
- S3 in the standard storage classes, which AWS stores across at least three AZs.
- EBS snapshots. They’re stored regionally, so you can restore a volume into a surviving AZ.
- AMIs and AWS Backup vaults, which are also regional.
One caveat from the UAE: AWS was still working to restore the other two zones months later. A regional copy survived, but “survived” and “available the same afternoon” turned out to be different things.
Tier 2: losing the whole Region (the Bahrain case)
Every item in that “regional” list shares one weakness. It lives in the Region.
Snapshots, AMIs, S3 buckets and AWS Backup vaults all sat in me-south-1. When the Region became unrecoverable, backups that lived only there went with it. The data and the backup of the data were in the same place.
Neither AWS Backup nor EBS does cross-Region copying by default. In AWS Backup, it’s a copy rule you add to a backup plan, pointing at a vault in another Region. For EBS, it’s a snapshot copy with a destination Region. Both work well. Both have to be set up before anything goes wrong.
Two things to budget for:
- The first cross-Region copy is a full copy, and cross-Region transfer is billed. Later copies are incremental only if the previous copy still exists in the destination and uses the same KMS key.
- Cross-account is a separate boundary. AWS’s own EBS documentation says it plainly: “Using a different account protects you if your main AWS account is compromised.” A second Region in the same account protects you from geography. A second account protects you from whoever has your credentials.
Rebuilding the environment in a second Region
A snapshot in a healthy Region is the start of a recovery. To run the workload, you still have to rebuild everything around it, and each of these has caught teams out during real failovers.
Encryption keys are regional. A KMS key lives in one Region, and AWS managed keys such as aws/ebs are always single-Region. An encrypted snapshot copied to another Region has to be encrypted with a key in the destination Region. And you can’t convert an existing key to a multi-Region key later. Decide this now.
The network has to exist. Your VPC, subnets, route tables, security groups and load balancers were defined in the Region you lost. Restored instances need somewhere to land. If the network isn’t in code you can deploy to another Region, someone is rebuilding it by hand during the incident.
Some configuration doesn’t travel. AWS Backup documents that a cross-Region RDS copy carries the default option group, not your custom one, and copies with persistent options fail until the matching option group exists in the destination.
Quotas are per Region. Your EC2 and EBS limits in the recovery Region are whatever they were before the event. When a Region fails, its customers move to the neighboring Regions at the same time. Raise your quotas before you need them.
Endpoints and DNS point at the old Region. Hardcoded regional endpoints, DNS records with long TTLs and Region-specific ARNs in config all need to change.
Your backup tool needs a plan too. If the software that runs your backups lived only in the lost Region, recovery starts with rebuilding the backup tool.
The data residency problem
Help Net Security raised another complication: data residency rules that required data to stay in-country turned into a liability.
Bahrain had one AWS Region. A workload legally required to stay in Bahrain had no second AWS Region to fail over to. It’s a real tradeoff, and there’s no clean answer:
- A second Region in the same country, where one exists
- A different provider with a data center in the same country
- A copy abroad, if the regulator allows a backup (as opposed to production data) to leave
That’s a question for your compliance team, and it should be answered before an incident.
Would your AWS estate have survived? A checklist
- For every production workload, name the Region where its newest backup copy lives.
- Confirm at least one copy is in another Region.
- Confirm at least one copy is in another account, with separate credentials.
- Check that the KMS keys for those copies can be used in the target Region.
- Check that your network is defined as code and has been deployed to the target Region at least once.
- Find out whether your backup tool’s own configuration survives the loss of its home Region.
- Look up when you last ran a failover test, and the RTO you actually measured.
- If a regulator limits where your data can live, write down where the second copy is allowed to be.
If any answer is “I’d have to check”, that’s where to start. The rest of our AWS disaster recovery guide goes deeper on each item.
How N2W handles a region loss
N2W runs inside your own AWS account, so every backup copy sits in storage you own, in the Regions and accounts you choose.
- Copies outside the Region and account. Policies copy snapshots across Regions and to separate DR accounts automatically, with backups as often as every 60 seconds.
- The environment comes back too. N2W captures your VPC, subnets, route tables, security groups, load balancers and IP ranges, and clones them into another Region or account through an editable CloudFormation template. Recovery Scenarios then bring up multi-tier applications in the order you set, app tier before database tier.
- A DR test that costs nothing. The dry run uses read-only AWS APIs and launches nothing. It checks subnets, IP address availability and IAM permissions in the target Region, so an “address in use” error shows up in a test instead of during an incident.
- The tool survives its own Region. N2W keeps its settings on a small data disk that replicates to your DR Region. If the home Region fails, you launch a fresh N2W instance there, attach the disk, and get the same console back.
- A copy outside AWS entirely. For a true air gap, N2W can archive to Azure Blob or Wasabi, locked with compliance-mode immutability (a locked time-based retention policy on Azure), so not even a root user can delete it before retention expires. N2W can also restore AWS backups as bootable VMs in Azure, for Ubuntu 22 and 24 (Windows restores as data disks only, and the direction is AWS to Azure).
We’ve written before about how N2W customers stayed online through a us-east-1 outage. The lesson this time is the same, just harder to ignore: the copy that counts is the one outside the blast radius.
Get the AWS Cloud Outage Survival Guide →
Frequently asked questions
Does multi-AZ protect against a region failure?
No. Multi-AZ spreads a workload across data centers inside one Region, and they’re all within about 100 km of each other. When AWS lost two Availability Zones in Bahrain, the whole Region went down. You need a copy in a different Region, and ideally a different account, to survive that.
What happened to the AWS Bahrain region?
Drone strikes in March 2026 damaged an AWS facility in Bahrain, and a second Availability Zone was disrupted in April, taking me-south-1 offline. In September 2026 AWS said it can’t restore access to resources and data hosted exclusively in that Region. It told customers to recover from backups stored in other Regions.
Are AWS backups stored in the same region as my data?
By default, yes. EBS snapshots, AMIs and AWS Backup recovery points live in the Region where they were created. Copying them to another Region is a setting you configure: a copy rule in an AWS Backup plan, or a cross-Region snapshot copy.
Can AWS lose my data?
Yes, in a large enough physical disaster. AWS confirmed in 2026 that data held only in me-south-1, or only in one UAE Availability Zone, can’t be recovered. Under the shared responsibility model, AWS runs the infrastructure and you decide where your copies live.
What’s the difference between multi-AZ and multi-region?
Multi-AZ keeps a workload running across data centers in one Region, usually with synchronous replication and automatic failover. Multi-region keeps a copy in a separate geographic Region, usually with asynchronous replication or backup copies, so you can recover when a whole Region is lost. Multi-AZ is about availability. Multi-region is what gets you back after a disaster.
How far apart are AWS availability zones?
AWS says the Availability Zones in a Region are separated by a meaningful distance, many kilometers, but all are within 100 km (60 miles) of each other. That’s far enough apart for a building-level failure and close enough for low-latency replication, which is also why an event affecting a whole metro area can reach more than one zone.