Your DR Plan Assumes the Region Comes Back

Two availability zones, six hours apart

At 1251 UTC on 2 March 2026, the availability zone AWS designates mec1-az2, in its Middle East UAE region, stopped serving normally. By 1846 UTC the same day mec1-az3 had been impacted as well. AWS confirmed that both had been directly struck by drones during the wider conflict in the region. A third facility, mes1-az2 in the separate Bahrain region, had been disrupted at around 0656 UTC that Monday, which AWS attributed to a drone strike in close proximity causing physical impacts to its infrastructure.

The strikes caused fires. The fires triggered the data centre sprinkler systems, and the water damaged equipment. AWS reported that customers were seeing high failure rates for data ingest and egress on services such as S3, which needs at least one healthy zone in a region to function. The company estimated that restoring the facilities and their cooling systems would take at least a day.

Hold that estimate in mind for the rest of this piece. It was made in good faith, by an operator with better information than any customer had, and it described the repair accurately.

The sentence in the advisory that actually mattered

Alongside the status updates, AWS told customers something more consequential. It advised them to back up their data and potentially migrate their workloads to alternate AWS regions, on the grounds that the ongoing conflict in the region made the operating environment unpredictable. Cloud providers do not lightly tell paying customers to leave a region they sell.

That advisory is the useful artefact from the whole episode, because it is the only instruction that addresses the actual failure mode. Sprinkler damage is a repair. An unpredictable operating environment is not a repair, it is a property of the location, and no amount of engineering inside the building changes it. AWS was in effect telling customers that the correct response to this class of event is exit rather than patience.

The uncomfortable part: most disaster recovery runbooks have a page for waiting and no page for leaving.

At least a day, measured against the calendar

On 30 April, AWS's own service status said the Middle East UAE region had suffered damage as a result of the conflict in the Middle East and was currently unable to reliably support customer applications. Note what changed in that sentence. In March the region had an outage and an estimate. By the end of April it had a condition and no estimate at all.

On 28 July, Cloudflare published its quarterly review of internet disruption events, drawn from its Radar network data. It records that HTTP traffic to me-central-1 has remained low, and describes the sustained reduction as the downstream signature of physical damage to the underlying data centre infrastructure. That is an independent measurement rather than a vendor statement, and it points the same way roughly five months after the strikes.

The arithmetic to carry into your next continuity review: the published estimate was at least a day, and the observable answer is still being measured in months.

Regional resilience was designed for the wrong failure

Multi-availability-zone architecture is a genuinely good answer to the failure it was designed for. Zones are separated so that a fire, a flood, a power event or a network fault in one does not take the others. That design assumption holds beautifully when the hazard is local to a building and independent between buildings. It stops holding when the hazard is regional and correlated, because then the separation between zones is measured in kilometres and the thing causing the damage is not.

Two of the three UAE zones were hit on the same day. A facility in a different region, in a different country, was affected the same week. Zone independence is a physical claim about a specific list of hazards, and armed conflict is not on that list. This is worth stating plainly because it is the part that reads as obvious afterwards and almost never appears in a design review beforehand.

For European firms the obligation already exists: financial entities under DORA owe their regulator a documented exit and continuity plan for critical ICT providers, and that plan is meant to survive a provider region becoming unavailable rather than merely slow.

Four changes to make in your runbook this week

First, write down your actual recovery time objective for the loss of an entire region rather than a zone, and be honest about whether you have ever tested it. If the honest answer is that region loss is out of scope, that is a decision, and it should be recorded with a named owner rather than left as an omission. Second, separate your repair scenarios from your withdrawal scenarios. A repair scenario waits. A withdrawal scenario moves, and it needs its data, its identity configuration and its network routes already staged somewhere else.

Third, decide in advance what evidence would trigger a move. The useful trigger here was not the outage on 2 March, it was the advisory telling customers to consider migrating. Vendors rarely say that, and when they do it should be treated as the signal rather than as background. Fourth, check where your backups physically are. A backup inside the region you are trying to leave is not a backup, and the moment you need it is the moment the region is the problem.

Read next: OpenAI Paid You Back in the Thing That Broke  |  A Fourth Cloud Giant Just Got More Plausible