AWS Just Confirmed Permanent Data Loss From War-Damaged Gulf Data Centers — A DORA Article 11 Case Study

On September 15, 2026, AWS added an update to its Health Dashboard that most cloud providers spend their entire existence trying to avoid ever having to write: some customer data is gone, permanently, and there is no recovery path. Six months after Iranian drone and missile strikes damaged its Middle East facilities, AWS confirmed it cannot restore access to resources and data hosted exclusively in its Bahrain region, and reached the same conclusion for mec1-az2, one of three Availability Zones in its UAE region. AWS's own framing is the most useful sentence in the whole story: the damage "exceeded what our regional and multi-AZ services are designed to withstand" (CircleID, citing the AWS Health Dashboard update).

The story hit Hacker News the same day and stayed near the top of the front page — the WSJ writeup "AWS says it can't restore some data from mideast facilities struck by Iran" pulled 370 points and 308 comments on the associated HN thread. CNBC, the Insurance Journal, Data Center Dynamics and several other outlets independently confirmed the same AWS statement (CNBC). It's an unusually clean, publicly documented case of a hyperscaler admitting a permanent loss rather than an extended outage — and it happens to be a close-to-perfect real-world test of the exact resilience posture that DORA Article 11 has required in-scope EU financial entities to plan, document and test since January 2025.

What actually happened, and when

The important architectural detail, easy to miss in the headlines: this is not "AWS lost a data center." The UAE Middle East region is built the standard way — three physically separate Availability Zones, precisely so that a single-facility failure (fire, power loss, a bad deploy) doesn't take out the region. That design worked exactly as intended for two of the three UAE zones, which are still in active recovery. It did not work for mec1-az2, and it did not work for the entire Bahrain region, because the failure mode wasn't a single-facility incident — it was correlated, deliberate, kinetic damage across multiple facilities in the same conflict, which is a fundamentally different threat model than the one multi-AZ redundancy was designed around. AWS said as much itself: the damage exceeded the assumptions the redundancy was designed to withstand.

Why this is a DORA Article 11 story, not just an AWS story

DORA (Regulation (EU) 2022/2554) has applied in full since 17 January 2025, and Article 11 ("Response and recovery") is the provision that speaks most directly to this scenario. It requires in-scope financial entities to maintain "a comprehensive ICT business continuity policy" (Art. 11(1)) covering arrangements to "quickly, appropriately and effectively respond to, and resolve, all ICT-related incidents" (Art. 11(2)(b)), with ICT assets "designed and used in full alignment with the [business impact analysis], in particular with regard to adequately ensuring the redundancy of all critical components" (Art. 11(5)) (digital-operational-resilience-act.com, Art. 11).

The clause that maps almost exactly onto what just happened in the Gulf is the testing requirement in Art. 11(6): financial entities (other than microenterprises) must test their ICT business continuity and recovery plans at least yearly, and those tests must include "scenarios of cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities" necessary to meet the backup obligations in Article 12. Read that clause next to the AWS timeline above and ask the honest question: does your organization's annual DORA test scenario list include "our cloud provider's entire regional footprint is physically destroyed by an armed conflict, with no restoration path for six-plus months"? Most BCP test plans we've seen model cyberattacks, ransomware, and single-facility outages. Very few model correlated, multi-facility, geopolitically-driven destruction — which is precisely the gap this incident exposes.

Article 12 adds the backup-specific half of the obligation: entities must "develop and document" backup policies and periodically test restoration procedures, with restored systems kept "physically and logically segregated from the source ICT system" (digital-operational-resilience-act.com, Art. 12). Article 12 also contains an instructive, narrower requirement for central securities depositories specifically: their secondary processing site must sit "at a geographical distance from the primary processing site to ensure that it bears a distinct risk profile." That specific wording is scoped to CSDs in the regulation's text — it is not a blanket "X kilometers" rule for every financial entity — but the underlying logic (a backup that shares the same risk profile as the primary isn't really a backup) is exactly what the Bahrain/UAE case illustrates: two data centers in facilities close enough to be damaged by the same regional conflict do not give you a "distinct risk profile," even if they're formally in different Availability Zones.

The concentration-risk and contract angle (Art. 29, Art. 30)

There's a second, less obvious DORA angle here. Article 29 requires financial entities to assess ICT concentration risk before contracting for a service supporting a critical or important function — specifically whether the provider is "not easily substitutable," and to "weigh the benefits and costs of alternative solutions, such as the use of different ICT third-party service providers" (digital-operational-resilience-act.com, Art. 29). Any EU financial entity that ran a critical function exclusively out of AWS's Bahrain region or mec1-az2, with no alternate region or provider, was carrying exactly the concentration risk Article 29 asks you to identify and price before signing — not after your provider's status page tells you the data is gone.

Article 30 then governs what the contract with that provider is supposed to say: mandatory "exit strategies, in particular the establishment of a mandatory adequate transition period," and provisions guaranteeing "access, recovery and return... of personal and non-personal data" on termination or provider insolvency (digital-operational-resilience-act.com, Art. 30). Here's the uncomfortable gap this incident surfaces: those exit and data-return clauses are drafted around contractual termination events — the provider going insolvent, the relationship ending, a service-level breach. They are not obviously drafted around a provider announcing that the underlying infrastructure was physically destroyed by a third party and the data is unrecoverable, full stop. A perfectly compliant Art. 30 exit clause is worthless if there's no data left to return. That reframes the exit-strategy obligation: the contractual right to get your data back only matters if your own backup design (Art. 11/12) never depended on that single provider-region holding the only copy in the first place.

Runbook: a multi-region resilience checklist this incident actually tests

This isn't a generic "here's what DORA Article 11 says" walkthrough — we've written that guide already, with the full 25-item BCP checklist, RTO/RPO calibration and a reference DORABusinessContinuityChecker implementation, here. This is the narrower, sharper checklist the Bahrain/UAE incident specifically demands: does your multi-region setup survive the loss of an entire region, not just a single zone?

1. Map single-region dependencies (Art. 6, Art. 8). List every critical or important function and the cloud region(s) it runs in. Flag any function where "region" and "provider" are both singular — that's your highest-risk row.
2. Run the concentration-risk test that Art. 29 requires, retroactively if you skipped it (Art. 29). For each flagged function: is the provider/region "easily substitutable"? If not, document why you accepted that risk, and re-run the cost/benefit of an alternate provider or region now, not at the next renewal.
3. Check your backup's actual blast radius, not just its AZ label (Art. 11(5), Art. 12). A backup in a different Availability Zone of the same region shares the same regional conflict, weather system, and power grid as the primary. Ask whether your restore target is in a different provider, a different geography, or ideally both.
4. Add "total regional loss" to your annual BCP test scenarios (Art. 11(6)). Cyberattack switchover tests are necessary but not sufficient. Explicitly script a test where the primary region is unreachable indefinitely — no ETA, no partial recovery — and verify your documented RTO/RPO still hold when the answer to "when will it come back" is "never."
5. Re-read your exit-strategy clause for the force-majeure gap (Art. 30). Confirm the contract's data-return and transition-period language isn't silently conditioned on the provider still having the data to return. If it is, the real mitigation lives in your backup architecture, not your legal team's redline.
6. Rehearse the Art. 19 reporting clock against this exact scenario (Art. 17–19). If your primary provider told you tomorrow that a region was unrecoverable, could you classify it as a major ICT-related incident and hit the 4-hour/24-hour initial notification window, the 72-hour intermediate report, and the one-month final report — all while you're simultaneously trying to restore service?
7. Put it in front of the risk committee (Art. 5). This incident is now a citable, dated, primary-sourced example — use it as the concrete scenario in your next governance review of ICT concentration risk, instead of a hypothetical.

What this doesn't mean

It would be easy to read this as "move to an EU cloud provider and the problem disappears." That's overselling it. Regional infrastructure can fail for plenty of reasons that have nothing to do with geopolitics — power grid failures, fiber cuts, and conventional fires have taken down single-region setups before, EU-based ones included. What an EU-based, genuinely multi-region architecture changes isn't the possibility of physical destruction — it's the correlation risk (a single geopolitical conflict is far less likely to simultaneously threaten facilities spread across, say, Germany, Finland and France than three Availability Zones in the same 50km stretch of Gulf coastline) and the jurisdictional simplicity of not routing a DORA compliance program through a single foreign region that happens to sit inside an active war zone. The actual, non-negotiable takeaway from the AWS Health Dashboard update is architectural, not geographic: whatever provider you use, if your disaster-recovery plan has never been tested against "the primary region does not come back," you don't yet know if it works — and on September 15, 2026, AWS just gave every DORA-scoped compliance team a real, dated, unambiguous reason to go find out before a regulator, or a war, does it for them.