At 12:51 UTC on 2 March 2026, AWS told customers that two of its facilities in the United Arab Emirates had been struck by a drone — “objects that struck the data center, creating sparks and fire.” Local authorities cut power to fight the blaze, a second availability zone degraded on shared dependencies, and the Bahrain region lost a zone the same morning. AWS's guidance, reported at the time, was unusually direct: consider backing up your data now and potentially migrating your workloads to alternate AWS Regions.
That is the scenario every multi-region business case is written against. It is also, out of everything that broke in the five months since, the only one that fits. Multi-region buys you protection from exactly one failure class — the loss of an entire region — and of the six notable cloud failures between March and July 2026, only the strikes on AWS's UAE facilities were that. The rest were single-zone, single-network-path, or control-plane failures, and a second region helps with roughly one of those three.
Key takeaways
- “Region outage” is not one thing. A zone losing cooling, a network path losing routes, and a global control plane losing DNS are three different problems with three different answers. Only one of them is solved by a second region.
- The same incident is a non-event or a breach depending on the number you signed. July's 20-minute AWS us-west-2 disruption fits comfortably inside a 99.9% monthly budget and blows a 99.99% budget by 4.6×.
- Infrastructure is the cheap half of multi-region. The expensive half is making the application tolerate asynchronous replication, and rehearsing the failover often enough that it still works.
- DORA does not mandate multi-cloud or multi-region. It mandates documented, segregated, periodically tested recovery. Plenty of teams bought topology when the regulation asked for evidence.
This post unpacks what actually failed between March and July 2026 and why the failure classes are not interchangeable, how to price the four disaster-recovery tiers against real RTO and RPO targets, what the EU rules genuinely require, and how to decide which of your workloads earns which tier.
1. Six failures, six different problems
Grouping these under “the cloud went down again” is how teams end up buying the wrong control. Here is what actually happened, in order:
- 1–2 March, AWS me-central-1 and me-south-1. Drone strikes and fire physically damaged facilities in the UAE, with a Bahrain zone losing power the same morning. AWS warned recovery “could take at least a day,” requiring repairs to cooling and power and coordination with local authorities. Cloudflare's Q2 2026 disruption summary records the same event independently. Failure class: destruction of regional capacity.
- 7–8 May, AWS us-east-1. Chiller units failed in a single data hall serving zone use1-az4. Racks shut down on thermal safety, taking EC2 and EBS with them; data-heavy services took the best part of a day to restore. Failure class: single-zone infrastructure loss.
- 22 June, Cloudflare and AWS. A broad Cloudflare network disruption coincided with an AWS fiber cut in eastern North America. Failure class: transit loss, outside any one region's blast radius.
- 20–21 July, Cloudflare R2 in ENAM. R2 returned 500s for some customers for roughly 17 hours. Failure class: degradation at a dependency you do not run.
- 23 July, Azure West US. Traffic in or out of the region failed for 4 hours 57 minutes, 14:44 to 19:41 UTC. Microsoft attributed it to maintenance automation removing IP routes from more devices than intended, after a blast-radius calculation wrongly expanded scope. Workloads staying entirely inside West US were unaffected. Failure class: regional network isolation.
- 24 July, AWS us-west-2. Connectivity to the Seattle Metro failed from 10:55 to 11:15 UTC, with route reconvergence causing intermittent issues until 11:59. Customers reaching the region over a single Direct Connect path through the Westin Building Exchange were impaired until 12:12 — 1 hour 17 minutes. AWS pointed at the networking hardware carrying routing to Seattle, and noted that anyone holding a redundant path through a different Direct Connect location was unaffected. Press coverage generally reported this one as roughly 80 minutes, measuring from the first user reports to AWS's all-clear; the figures here are AWS's own impact windows, which is the fairer comparison against an availability target. Failure class: single network path, with a self-inflicted amplifier.
For contrast, take the October 2025 us-east-1 event, where a latent race condition in DynamoDB's DNS automation emptied the regional endpoint record and took roughly fifteen hours to clear. Its blast radius was global, because us-east-1 hosts control-plane services other regions depend on. A second region would not have saved you, because the thing that broke was not regional.
The base rate is worth stating plainly, because the doom framing is wrong. Cisco ThousandEyes counted 610 global outage events in the week of 20–26 July, 514 the next week, and 502 in the week of 3–9 August — a downward trend, per Network World's running tally. The internet is not falling apart; 2026 has simply produced a run of newsworthy incidents in a short window. Forrester expects at least two multi-day hyperscaler outages in 2026, arguing AI build-out is diverting investment from ageing infrastructure. That is a forecast, not a measurement, but a reasonable one to plan against.
2. The only number that matters is the one you signed
Before you price any architecture, work out whether these events would actually have breached your commitments. Most teams have never done this arithmetic, which is why the debate stays emotional. Using the same figures as our uptime and SLA calculator, a 99.9% target allows 43m 49s of downtime per month and 8h 45m 57s per year; 99.99% allows 4m 22s per month.
| Event | Duration | Against 99.9% | Against 99.99% |
|---|---|---|---|
| AWS us-west-2, 24 Jul core impact |
20 min | Fits, with half the month's budget to spare | Blows the monthly budget 4.6× over |
| AWS us-west-2, 24 Jul single Direct Connect path |
1h 17m | Blows the monthly budget 1.8× over | Consumes 1.5 years of budget |
| Azure West US, 23 Jul | 4h 57m | More than half the annual budget, in one afternoon | Roughly 5.6 years of budget |
| AWS us-east-1, 7–8 May worst-affected services |
~28 h | Over 3× the annual budget, in one event | Not meaningfully measurable |
One incident, four verdicts. The 24 July disruption was a non-event for a three-nines service and a contractual problem for a four-nines one, and nothing about the incident changed between those readings — only the number someone signed. Set the target before shopping for architecture, not after.
Notice what the second row is really telling you. The customers who lost 1h 17m rather than 20 minutes were not hit by a bigger outage; they were hit by the same outage plus a single-path Direct Connect design. That is a few hundred dollars a month of redundancy, not a second region. The cheapest resilience wins are almost always inside the failure domain you are already in.
Be honest, too, about what you would have detected. If your on-call rotation is drowning, a 20-minute network event is over before anyone triages it — a failure mode we covered in the alert fatigue trap. A failover you cannot decide to trigger in twenty minutes is not a twenty-minute failover.
3. What each topology actually protects against
Multi-AZ, multi-region and multi-cloud are not three points on one scale. They are three different controls covering three overlapping-but-distinct sets of failures, at wildly different prices.
The bottom row is not a joke. Providers' own automation caused two of the incidents above — Azure's maintenance tooling miscalculating a blast radius, and AWS's DNS enactor racing itself. Your change pipeline is not better than theirs. Multi-region replicates a bad deploy to both regions at the speed of your CI system, which is why teams with genuine active-active spend heavily on staged rollouts and per-region deploy gates. That cost belongs in the business case.
The May event is the clearest illustration of the multi-AZ boundary, and usefully, the affected company published its own analysis. Coinbase's postmortem of the 7 May outage explains that its matching engine ran as a Raft cluster inside a single AWS cluster placement group — a deliberate choice to get the lowest possible inter-node latency for an exchange. When AWS terminated instances in that placement group, three of five nodes went down, quorum was lost, and in the company's own framing there was no automated ability to fail over to another availability zone. Recovery needed manual cluster reconstruction.
That is not carelessness; it is a legitimate latency-versus-availability trade that many low-latency systems make on purpose, and it is worth studying precisely because the reasoning is defensible and the outcome was still bad. If you run a consensus system: do you know, today, whether losing your placement group costs you quorum, and has anyone tested the answer?
4. Pricing the four tiers honestly
AWS's disaster recovery whitepaper defines four tiers, and they remain the right vocabulary. What the whitepaper does not do is tell you what each one costs you specifically, so here is how we model it.
Those multipliers are modelled from architecture, not taken from a survey: they follow from how much duplicated compute each tier runs, how much data replicates continuously, and cross-region transfer charged per gigabyte on every replicated byte for as long as the replica exists. Treat them as a starting shape and substitute your own numbers — a stateless API and a 40 TB analytics estate land in very different places. Modelling the spend side alongside the reliability side is what we do in cloud billing engagements and AWS cost optimization.
| Tier | Realistic RTO / RPO | Earns its cost when | The trap |
|---|---|---|---|
| Backup & restore | Hours to a day / your backup interval | A next-day restore is genuinely acceptable to the business | Nobody has restored from these backups. Untested backups are a filing system, not a recovery plan |
| Pilot light | Tens of minutes to hours / minutes | Data must survive, but capacity can be rebuilt on demand | The RTO assumes instance capacity is available in the target region during a regional event, when everyone else is asking for it too |
| Warm standby | Minutes / seconds | Downtime cost per hour clearly exceeds running a scaled-down second copy | Standby drifts. It is a version behind, missing a secret, or scaled for last year's traffic, and you find out during the incident |
| Active-active | Near zero / near zero to seconds | A regional loss is existential, or a regulator requires demonstrable continuity of a critical function | The hard part is the application, not the infrastructure. Concurrent writes from two regions need a conflict-resolution story you probably do not have |
The ladder is cheap at the bottom, and at the top the price is not really money. Going from warm standby to active-active roughly doubles infrastructure but can multiply engineering effort by considerably more, because it changes what your application may assume about consistency. Teams that skip that reckoning end up with a second region that serves read traffic and quietly cannot take writes — a warm standby with a larger bill and a more confident architecture diagram.
5. What the regulators actually require
If you work in financial services, someone has told you DORA requires multi-cloud. It does not, and this is the most expensive misreading we encounter.
Article 12 of Regulation (EU) 2022/2554 requires financial entities to document backup policies with scope and frequency set by criticality, to define restoration and recovery procedures, to restore using systems physically and logically segregated from the source, and to test those procedures periodically. Read it looking for a mandated topology and you will not find one. There is no second provider named, and no second region either. The obligation is demonstrable, tested recovery — not a particular architecture.
This cuts both ways, and the second direction is the uncomfortable one. A single-region deployment with a genuinely rehearsed, evidenced restore satisfies the requirement. An active-active pair across two providers that nobody has ever failed over under load does not, however impressive it looks in an architecture review. Cockroach Labs' State of Resilience survey of 1,000 senior technology executives — fielded in late 2024, so treat it as a baseline rather than fresh data — found 79% saying they were not equipped to comply with DORA and NIS2. Our read is that most of that gap is evidence and rehearsal, not topology.
So for a regulated team the money is often better spent making one region's recovery provable than on a second region nobody exercises. That is the shape most of our fintech engagements take, and it usually costs less than the multi-region programme it replaces.
6. Four mistakes we keep seeing
From resilience reviews across fintech, SaaS and enterprise platforms, the same four patterns come up almost every time:
- 1. One RTO for the entire estate. A single aggressive target set at board level and applied uniformly, so the internal wiki gets the same protection as the payments path and the budget runs out before tier one is covered. Tier by business impact first — the exercise usually finds three tiers, and the middle is larger than anyone expects. We walk through that reasoning in SRE for SaaS.
- 2. The DR region has never taken production traffic. The most common finding, and the most consequential. If the last failover test was a tabletop exercise, you do not have an RTO, you have an estimate. Untested failover reliably surfaces the same things: a security group never replicated, a certificate scoped to one region, a parameter group that silently differs, quotas never raised in the standby.
- 3. The dependency map stops at the cloud provider. Teams model losing their own region and forget the payment gateway, the identity provider and the object store the failed-over stack still has to reach. The July R2 incident is the reminder: a second region is useless if both regions call the same impaired dependency. Map the third parties before the regions.
- 4. Nobody is authorised to press the button. The technical failover takes four minutes and the decision takes ninety, because the runbook says escalate and the approver is asleep. Write the criteria down in advance, name who owns the call at 3 AM, and pre-authorise against a measurable trigger. It is a governance fix, not an engineering one, and usually the largest single component of real-world RTO.
The takeaway
The five months from March to July 2026 were a good natural experiment, and the result was not “go multi-region.” It was that failure classes are not interchangeable: a zone lost cooling, two regions lost network paths, a dependency returned 500s, a control plane emptied a DNS record, and one region took physical damage. Multi-AZ covers the first. Redundant paths cover part of the second. Vendor diversity covers the third. Only leaving the provider entirely covers the fourth. Only a second region covers the fifth — and nothing at all covers your own bad deploy.
The useful question is therefore not whether multi-region is worth it in general, but which of your services would still be worth running if a region were gone for a week, and what you owe the rest. For most organisations that means a small tier-one set on warm standby or better, a large middle on pilot light, and a long tail on tested backups — paired with the unglamorous work of removing single paths, rehearsing the restore, and writing down who makes the call.
Pick the availability target first, tier your workloads by what a week-long regional loss would actually cost each one, and then buy the cheapest architecture that survives a rehearsal — because an untested second region is not resilience, it is a more expensive way to have the same outage.
Been asked for a multi-region plan and not sure the business case holds? InfraZen runs resilience reviews as part of our SRE practice: we tier your workloads by business impact, price each DR option against your actual data volumes and cloud architecture, and run the failover you have been meaning to test. Book a free 30-minute resilience review and we will tell you honestly which tier your workloads earn — including the ones where the answer is “you already have enough.”
Frequently asked questions
Is multi-region architecture worth the cost?
For most workloads, no. Multi-region protects against one failure class, the loss of an entire region, and that is the rarest class. Of the notable cloud failures between March and July 2026, only the drone strikes on AWS's UAE facilities destroyed regional capacity outright. Single-AZ, single-network-path and control-plane failures were far more common, and a second region does nothing for two of those three. Buy multi-region for the handful of workloads where a multi-day regional loss is existential, and buy a tested lower tier everywhere else.
What is the difference between multi-AZ and multi-region?
Multi-AZ spreads a workload across physically separate data centres inside one region, linked by sub-millisecond networking, so you can run synchronous replication and automatic failover with no application changes. Multi-region spreads it across geographies 10 to 100 milliseconds apart, which forces you to choose between asynchronous replication and accepting write latency. Multi-AZ is a high-availability control and handles the common case: a building losing power or cooling. It does nothing for a region-wide event, and nothing at all for a global control-plane failure.
How much does a multi-region setup cost on AWS?
The infrastructure multiplier ranges from roughly 1.05x for cross-region backups to 2x or more for active-active, driven by duplicated compute, duplicated stateful storage, and cross-region data transfer billed per gigabyte on every replicated byte, continuously. But infrastructure is the smaller half of the bill. The larger half is engineering: making the application tolerate asynchronous replication, resolving conflicting writes, and running the failover exercise often enough that it still works. Model the second half before you commit to the first.
Does DORA require multi-cloud or multi-region?
No. Regulation (EU) 2022/2554 requires documented backup, restoration and recovery procedures, restoration onto systems physically and logically segregated from the source, and periodic testing of those procedures. It never names a second cloud provider or a second region as a control. A single-region architecture with a genuinely rehearsed restore can satisfy DORA, while an untested active-active deployment across two providers can fail it. The obligation is demonstrable recovery, not topology.
What RTO and RPO should we set?
Set them per workload, from business impact, before you look at any architecture. Ask what an hour of unavailability costs this specific service, and how much data loss the business can reconcile by hand. Most organisations discover three tiers: a small set of revenue-path or regulated services that justify minutes, a larger middle that is fine with hours, and a long tail where a next-day restore is genuinely acceptable. Applying one aggressive target to everything is how DR budgets get spent protecting internal wikis.
Related: Uptime & SLA calculator · What is SRE? (definition guide) · The four golden signals · DevOps for fintech · SRE consulting