Is the AWS UAE region (me-central-1) back online?

Not fully. On 30 April 2026 the AWS status page said ME-CENTRAL-1 was unable to reliably support customer applications. In mid-September AWS said it could not restart one UAE facility, was still restoring two, and could not restore resources and data held only in its Bahrain region (me-south-1). Check the AWS Health Dashboard for the current state before planning around it.

Was multi-AZ enough to survive the AWS UAE outage?

No. Two of the three availability zones in me-central-1 lost power on 1 March 2026, and in-region backups such as EBS snapshots, which live in S3 in the same region, were impaired too. Availability zones protect against a failed building, not against a regional event.

Can a UAE company fail over to an AWS region in Europe?

For unregulated workloads, yes. For data under residency rules, such as banking data under the Central Bank of the UAE or patient records, generally not without regulator engagement. The common answer is a second provider with UAE infrastructure for regulated data and a European region for everything else.

What is the minimum a Gulf company should do this quarter?

Know which systems hold regulated data, keep an immutable backup outside the primary region and provider, write down the recovery time you can tolerate for each system, and run one real restore. Most of the damage in March fell on companies that had never tested a restore.

AWS UAE Outage: Multi-Region Disaster Recovery

A Gulf data centre with one region dark and workloads rerouted to a second site

TL;DR: On 1 March 2026, drones struck two AWS data centres in the UAE. A day later a strike nearby knocked out power in AWS Bahrain. Seven months on, AWS says data that lived only in Bahrain cannot be restored. Customers in both regions ran multi-AZ setups and it did not help, because two zones failed at once. The fix is a second region, and usually a second provider, and the hard part in the Gulf is doing that without breaking data residency rules. This post covers what happened, why the usual advice does not fit, and the checklist we would work through with a UAE client.

What actually happened

The timeline below comes from AWS status updates as reported in the press. We link each source so you can check it.

28 February 2026. US and Israeli strikes on Iran begin.
1 March, 12:51 UTC. AWS reports that availability zone mec1-az2 in me-central-1 (UAE) was "impacted by objects that struck the data center, creating sparks and fire". Authorities cut the power. By 18:46 UTC a second zone, mec1-az3, had lost power as well, and S3 was failing at high rates (The Register).
2 March. Zone mes1-az2 in me-south-1 (Bahrain) loses power after what AWS later described as "a drone strike in close proximity". On 3 March AWS confirmed that two UAE facilities had been "directly struck" and that sprinkler water had caused further damage. It told customers to back up and move workloads to other regions.
March and April. Banks, fintechs and platforms report disruption: TeleGeography names ADCB, Emirates NBD, FAB, Careem, Hubpay, Alaan and Snowflake, across EC2, S3, DynamoDB, Lambda and RDS (TeleGeography). On 24 March AWS said its Bahrain region "has been disrupted as a result of the ongoing conflict" (Arab News / AFP).
30 April. The AWS status page says ME-CENTRAL-1 is "currently unable to reliably support customer applications" (W.Media).
16 September. AWS says it cannot restore Bahrain "resources and data hosted exclusively in this Region", cannot restart one UAE facility, and is still restoring two (report).

That last line is the one that matters. Anything that lived only in me-south-1 and was not copied out in time is gone.

Two things we could not confirm. The IRGC claimed a strike on an Oracle site in Dubai in April, and Dubai officials denied that any data centre was hit. We found no reported damage to Microsoft Azure, Google Cloud or Oracle facilities in the region. The threat has not gone away, though: on 31 March Iran named 18 technology companies as "legitimate targets", including Microsoft, Google, Oracle, Nvidia and G42 (intellinews).

The network is exposed too. Several subsea cables near Jeddah were cut on 6 September 2025, which added latency to Azure traffic crossing the Middle East and disrupted du and Etisalat users (TechRadar). The Strait of Hormuz carries the FALCON, AAE-1, TGN-Gulf and SEA-ME-WE cables, and analysts rate dragging anchors from congested shipping as a bigger risk to them than sabotage (AGBI).

Why multi-AZ was not enough

The standard cloud advice is to spread a workload across availability zones. Zones are separate buildings with separate power, a few kilometres apart, so if one floods the others carry on. That advice is designed for a failed building. It is not designed for a regional event, and in March two of me-central-1's three zones went down within six hours.

Backups failed too. AWS Backup and EBS snapshots are stored in S3 in the same region, so when S3 in me-central-1 started failing, the backups were stuck behind the same outage as the systems they were meant to restore. A backup in the same region as production does not count as disaster recovery.

The residency trap: why "just fail over to Frankfurt" does not work

In March, AWS advised customers to move to other regions "depending on latency and data residency requirements". For many Gulf companies, data residency rules out the obvious move.

Regulated financial data. Firms licensed by the Central Bank of the UAE are expected to keep customer data onshore. As one backup vendor put it after the outage, they "cannot simply failover to AWS in Europe" (N2W).
Health data. A UAE healthcare provider generally cannot move patient records abroad, outage or not.
Government and semi-government work. Contracts often name the hosting location.

These summaries come from vendors, not from regulators. We found no regulator guidance issued in response to the strikes. Your compliance team and, if you are licensed, your regulator are the ones who decide.

The practical consequence is that the plan has to split by data class. Regulated data needs a second location inside the country. Everything else can and should go further away.

What a resilient Gulf setup looks like now

Most companies don't need everything below. Pick the parts that match how long each system can be down and what data it holds.

1. Classify before you architect. List every system and note two things for each: whether it holds data that legally has to stay in the UAE or KSA, and how long the business can survive without it (the recovery time objective, or RTO) and how much data it can afford to lose (the recovery point objective, or RPO). A marketing site and a payments ledger should never share a disaster plan.

2. Get an immutable copy out of the blast radius. At minimum, keep a backup that the primary region cannot take down with it, and that ransomware cannot delete: object-locked storage in another region or with another provider. For regulated data, that means a second provider with UAE infrastructure. Azure has UAE North, and Oracle has regions in Dubai and Abu Dhabi. For everything else, a European region is fine and further from the conflict.

3. Choose your failover level honestly. There are three levels, each costing more than the last:

Backup and restore. The cheapest. Recovery takes hours to days, and only works if you have rehearsed the restore.
Pilot light. The database is replicated to the second site and the compute is defined in infrastructure-as-code (Terraform, for example) but switched off. Recovery takes tens of minutes to a few hours.
Active-active. Both sites serve traffic all the time. Recovery takes minutes, but the bill and the complexity roughly double. Worth it for payments and very little else.

4. Make the infrastructure reproducible. If your production environment was built by hand in a console, you can't rebuild it somewhere else under pressure. Infrastructure-as-code is what makes a second region a deployment instead of a project. It is also how we run our own platform, with staging and production defined in Terraform.

5. Remove the hidden single-region dependencies. DNS, secrets, container registries, identity providers and CI runners all tend to sit in the primary region. Each one can quietly block a failover.

6. Run the restore. Put it in the calendar, restore production data into the second site, and time it. That number is your real recovery time, whatever the architecture diagram says.

The questions to answer this month

Which of our systems hold data that has to stay in the UAE or KSA, and where is the second copy of that data today?
If me-central-1 went down for good tomorrow, what would we lose, and how long would it take us to come back?
Do our backups live in the same region, or with the same provider, as production?
Has anyone restored from those backups this year?
What do our contracts and our regulator actually say about failover outside the country?

If you can't answer them, you're in the same position as many of the companies hurt in March. You can fix it in a few weeks, before the next event.

Related: how we work with companies in Dubai and the UAE, and, if a security questionnaire is holding up a deal, how to answer an enterprise security review.

The AWS UAE Outage: Disaster Recovery for Gulf Companies After the Drone Strikes

Multi-AZ did not save anyone in me-central-1. Here is what does, and how to do it when your data is not allowed to leave the UAE.