AWS Middle East data loss: disaster recovery for UAE workloads

AWS has told customers it is unable to restore access to the resources and data hosted exclusively in one availability zone of its UAE region, and in the whole of its Bahrain region. The AWS Middle East data loss is not a story about one unlucky zone. It is AWS saying, in writing, that multi-AZ inside one region was not enough. By the end of this post you will know which of your workloads share that exposure, which disaster recovery pattern fits each one, and where UAE data residency limits what you can copy abroad.

The key facts, as of 22 September 2026, from the AWS Health Dashboard:

Region	What AWS said on 15 September 2026	Status of everything else
Middle East (UAE), me-central-1	Resources and data hosted exclusively in the mec1-az2 availability zone cannot be restored	AWS is still working to recover regional resources and zonal resources in mec1-az1 and mec1-az3
Middle East (Bahrain), me-south-1	Resources and data hosted exclusively in the region cannot be restored	AWS will share a further update in early 2027

What happened to the AWS Middle East regions

The UAE region's trouble began on 1 March 2026 with what the dashboard first called a localized power issue in mec1-az2. Later that day AWS said the zone had been impacted by objects that struck the data center, creating sparks and fire, and that the fire department had shut off power to the facility and its generators. In the same update AWS wrote that customers running their applications redundantly across the AZs were not impacted.

That held for less than a day. On 2 March a second zone, mec1-az3, went down, and new instance launches were impossible across the region. AWS then explained that Amazon S3 is a regional service designed to withstand the total loss of a single Availability Zone; it kept working when the first zone went dark, and its error rates climbed when the second one was impaired. On 3 March AWS confirmed that two of its UAE facilities had been directly struck by drones, and that a strike close to a Bahrain facility had caused physical damage there.

By 30 April AWS was describing the UAE region as unable to reliably support customer applications and the Bahrain region as unavailable, with recovery expected to take several months. The 15 September updates are the first time the public dashboard says some of that data cannot be restored. Reuters reported the statements the following day, and InfoQ's write-up collects the engineering community's reaction. We stick to what AWS itself published; the conflict behind the damage is outside the scope of this post.

The AWS Middle East data loss turns on one word: exclusively

AWS did not say it lost everything in mec1-az2. It said it cannot restore what was hosted exclusively there. Anything with a copy in another zone or another region is, by that phrasing, outside the loss. That makes the practical question for every team narrow and checkable: what do you run that exists in exactly one place?

The dashboard names the usual suspects. In the first hours, AWS listed EC2 instances, DB instances and EBS volumes in the affected zone as unavailable, and told customers who needed immediate recovery to restore from EBS snapshots or launch replacements in another zone or region. Those are zonal resources. A single-AZ database, a self-managed database on one EC2 instance, or a file share on one volume is exactly the shape of data AWS could not bring back.

The second word to read carefully is "regional". Six months after the strikes, AWS says it is still working to recover regional resources in me-central-1. Regional services such as S3 store data across zones, and AWS states S3 Standard stores objects across a minimum of three availability zones. That protects you against losing a zone. It does not give you a copy outside the region, and while the region is impaired your data is neither lost nor reachable.

Is multi-AZ enough for disaster recovery?

Multi-AZ is enough for losing one data centre, and AWS never claimed more. Its own disaster recovery whitepaper says that for the disruption or loss of one physical data center, a well-architected, highly available workload may only need backup and restore. If your definition of a disaster extends to a whole region, or regulation requires it, the same page says to consider pilot light, warm standby or multi-site active/active.

Bahrain shows where that line sits. AWS wrote that the damage there spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. InfoQ puts the facilities behind a region's availability zones within roughly 100 kilometres of each other, which covers the failure modes AWS lists, such as power outages, lightning strikes and earthquakes, but not an event that reaches several facilities at once.

The strongest counter-argument deserves a fair hearing. Multi-region architecture is expensive, widens the surface you have to secure, and for most teams in most years the failure it protects against never happens. Plenty of engineers read this incident as proof that you should design for regional loss everywhere. We think that overcorrects. The honest reading is narrower: multi-region is a business decision about which workloads you cannot afford to lose, and most teams never made that decision explicitly. They inherited single-region by default.

The four AWS disaster recovery patterns, compared

AWS groups disaster recovery into four strategies that trade cost against recovery time. The whitepaper describes each in terms of what already runs in the recovery region before anything fails:

Strategy	Running in the recovery region	What failover involves
Backup and restore	Backups only	Restore data, then redeploy infrastructure, configuration and code, ideally from infrastructure as code
Pilot light	Replicated data stores always on; application servers deployed but switched off	Switch on and scale out the application tier
Warm standby	A scaled-down but fully working copy that can take traffic immediately	Scale up to production capacity
Multi-site active/active	Full production in more than one region, all serving traffic	No failover as such; route traffic away from the failed region

Two details in the whitepaper matter more after this incident than they did before. First, restoring from backup is a control plane operation, and AWS recommends scheduling periodic restores so you still have working data stores if that operation is unavailable during a disaster. Second, the difference between pilot light and warm standby is whether the recovery site can serve requests without first being switched on. If your recovery time objective (RTO) is measured in minutes, backup and restore will not meet it however good your backups are.

For databases, the whitepaper notes that Aurora global database replicates to a secondary region with typical latency under a second and can promote a secondary to read/write in less than one minute, even in a complete regional outage. That is the benchmark to hold any cross-region database design against when you set a recovery point objective (RPO).

How do I back up AWS workloads to another region?

You back up AWS workloads to another region by copying backups there and making the rest of the workload redeployable. The AWS guidance reduces to these steps:

1. Copy backups across regions. AWS Backup supports copying backups to a disaster recovery region, and also across accounts, which protects against account compromise and insider threats.
2. Replicate object storage with versioning on. S3 Cross-Region Replication copies objects continuously. AWS warns that continuous replication may not protect against corruption or malicious deletion as well as point-in-time backups, so keep versioning and backups alongside it.
3. Put infrastructure in code. AWS says that without infrastructure as code, restoring in the recovery region may be complex enough to exceed your RTO. Copy the AMIs you launch from, too.
4. Check quotas in the recovery region. A warm standby that cannot scale because of a service quota is a pilot light you did not plan for.
5. Restore on a schedule, not only in a drill. A backup you have never restored in the recovery region is a hypothesis, which is the argument of our post on backup restore testing.

In the environments we set up for clients, step three is usually where the real work is. Data copies are a configuration change; a workload that was built by hand in the console over three years is a project.

UAE data residency and cross-region backup

The hardest part of this for UAE companies is not technical. When AWS told Middle East customers to move, it recommended regions in the United States, Europe or Asia Pacific, "as appropriate for your latency and data residency requirements". For some data that qualifier is the whole problem.

Under the UAE's federal personal data law, Federal Decree-Law No. 45 of 2021, cross-border transfers are allowed to countries with adequate protection, and to others under conditions such as contractual safeguards or the data subject's consent, according to a US International Trade Administration summary. The same summary notes that the law excludes government data, health data and personal financial data, which are governed by their own rules. If your workload holds any of those, the question of whether a backup may leave the country belongs with your legal adviser, not your cloud team. Nothing here is legal advice.

Encryption does not make the question go away. As one thread in InfoQ's coverage points out, an encrypted backup abroad is only useful after a regional loss if the keys are reachable too, which means they also sit outside the jurisdiction. Gregor Hohpe's point, quoted in the same piece, cuts the other way: the risk is regional, not tied to a provider, so moving to another cloud in the same geography does not remove it.

Where data genuinely cannot leave, the remaining options are a second facility or provider inside the country, or accepting the exposure. InfoQ's conclusion is the right frame: in that case the residual risk is a constraint on the architecture, and it belongs in a risk register that your board has seen, rather than in a runbook nobody expects to use. We made a similar point about AI workloads in OpenAI data residency in India and the UAE: residency decides the architecture before engineering does.

Five questions to answer this week

1. What exists in exactly one place? List every database, volume and bucket in me-central-1 or me-south-1 with no copy in another region.
2. Which of it is residency-bound? Tag each data set as free to copy abroad, copy with conditions, or must stay in the UAE, and get that classification signed off.
3. What RPO and RTO does each workload actually need? Pick the DR pattern from the table from that answer, not from habit.
4. Can you rebuild without the console? If the answer involves someone's memory, fix that before buying a second region.
5. When did you last restore in another region? If never, schedule it.

This is a short exercise for a small estate and a real programme for a large one. If you want a second pair of hands on it, it is the first thing we do in any DevOps and cloud engineering engagement, and our team for software development in Dubai works through it with UAE clients. Whatever you decide, write down which workloads you have chosen to keep in one region and why. After 15 September, "we assumed AWS had it covered" is no longer a position anyone can defend.