Some companies run their disaster recovery across availability zones. Each AZ is a separate datacenter, so three AZs are three sites. Others maintain a second region, because to them a recovery site belongs somewhere else entirely.
Both camps call it disaster recovery. Both have a point. And DORA, the regulation both camps worry about, does not pick a side.
DORA never mentions availability zones or multi-region. It asks a different question: for each application, how long can you afford to be down, how much data can you afford to lose, and can you prove it? That has a different answer per application. This article shows what each setup actually protects against and what the regulation actually requires, so you can answer it for yours.
Ask two engineering teams about disaster recovery and you get two confident, opposite answers.
The first team says: "we're multi-AZ". The reasoning is sound. AWS availability zones are physically separate datacenters, kilometers apart, with independent power, cooling, and physical security. Three AZs are three sites. Why would that not count as disaster recovery?
The second team says: "we have a standby in a second region". Also sound. A disaster that takes out the whole region takes every AZ with it. A recovery site should not share fate with the primary.
Then an auditor, a compliance framework, or a customer due-diligence questionnaire enters the room, usually citing DORA. It asks: what are your recovery objectives? Where is your secondary site? What happens if your provider's region fails? Both teams go looking for the sentence in the regulation that blesses their architecture. Neither finds it. It does not exist.
So we went to the primary sources: the regulation text, AWS's own documentation, and the post-mortem of the largest cloud outage in recent memory.
DORA, the EU's Digital Operational Resilience Act for financial entities, is the strictest widely-applicable regime here. That makes it the useful worst case. We searched the full text of the regulation and its ICT risk management RTS. The words "availability zone" and "multi-region" never appear. "Region" appears exactly once, in a clause about disclosing where a vendor processes data.
What DORA requires of a financial entity (Art. 12) is technology-neutral. Maintain "redundant ICT capacities equipped with resources, capabilities and functions that are adequate to ensure business needs". Restore backups on systems "physically and logically segregated from the source ICT system". Set recovery time and recovery point objectives per function, yourself, based on how critical the function is.
DORA does contain a "secondary processing site" requirement, in Article 12(5). It applies to central securities depositories, and the accompanying technical standards extend it to central counterparties. Those are the market infrastructures the rest of the financial system runs on. The requirement does not bind a typical bank, and it does not bind a SaaS vendor.
Even there, the language is about risk, not technology. The secondary site must sit "at a geographical distance from the primary processing site to ensure that it bears a distinct risk profile and to prevent it from being affected by the event which has affected the primary site". During the public consultation on the technical standards, respondents asked the three European Supervisory Authorities (EBA, ESMA and EIOPA, who drafted them) whether "secondary processing site" refers to secondary data centres. The authorities kept the risk-based wording and declined to name any technology (Final Report JC 2023 86, p. 173).
If you are a SaaS company, you are most likely not in DORA's direct scope at all. You meet it indirectly, through contract clauses and due-diligence questionnaires from financial customers. So the question you have to answer is the regulator's question: does your recovery setup bear a distinct risk profile from your primary, per application, and can you prove your recovery objectives? Neither "we're multi-AZ" nor "we have a second region" answers that by itself. The multi-AZ camp is right about the physical world, and AWS backs them.
AZs are physically separate facilities, many kilometers apart, with independent power, cooling, and physical security. AWS's own disaster recovery whitepaper, Disaster Recovery of Workloads on AWS: Recovery in the Cloud, says plainly: "a multi-AZ architecture within an AWS Region may already meet much of your risk mitigation needs". A fire or a flood that takes out one datacenter is a disaster your multi-AZ architecture recovers from by design. For that risk profile, three AZs really are three sites.
But the same whitepaper has a section titled, in full, "High availability is not disaster recovery". The distinction: "Availability focuses on components of the workload, whereas disaster recovery focuses on discrete copies of the entire workload." And its "Disaster recovery options in the cloud" section draws the boundary precisely: "If your definition of a disaster goes beyond the disruption or loss of a physical data center to that of a Region or if you are subject to regulatory requirements that require it, then you should consider Pilot Light, Warm Standby, or Multi-Site Active/Active."
So AWS's position, in our words: multi-AZ is disaster recovery for datacenter-scale disasters. It is not disaster recovery for region-scale disasters. Which leaves one question: how often are disasters region-scale?
On October 19-20, 2025, us-east-1 suffered roughly 14 hours of cascading impact. The root cause, from AWS's own post-event summary: "a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record for the service's regional endpoint". One automation bug deleted the DNS records for DynamoDB's regional endpoint. The failure cascaded into EC2 launches, network load balancers, Lambda, and STS. Downdetector logged over 6.5 million reports across more than 1,000 services.
Here is what it means for the multi-AZ camp: every availability zone in the region was affected equally. The event was not a flood that your second AZ sits outside of. It was a software defect in a regional control plane, and all your AZs share that control plane. Against the failure mode that actually happened, multi-AZ provided zero isolation. And this keeps happening: December 2021, network congestion in us-east-1 disrupted sign-in globally. November 2020, a Kinesis failure took down Cognito authentication. The big cloud outages are software, not floods.
But the same outage carries a warning for the second-region camp. Some global AWS services are homed in us-east-1: the IAM control plane, console sign-in and identity federation, parts of Route 53. During the outage, customers in other regions could not sign in with federated identities and could not modify IAM roles or policies. Redshift customers "in all AWS Regions were unable to use IAM user credentials for executing queries". AWS's own Support Center "successfully failed over to another region as designed", and then broke anyway, because a subsystem it depended on had not. A second region is not automatically a distinct risk profile either. It only is if the failover path has no hidden dependency on the failed region.
So the honest scorecard. An availability zone gives you a distinct physical risk profile and an identical software risk profile. A second region gives you a distinct software risk profile only if you engineered the dependencies out. And the regulator's phrase "the event which has affected the primary site" covers both kinds of event.
Stop asking which camp is right. Decide per application, from recovery objectives. The technology follows.
Set RTO and RPO per application, as a business decision. Recovery Time Objective: the maximum acceptable delay between interruption and restoration. Recovery Point Objective: the maximum acceptable data loss, measured in time. This is exactly what DORA asks the entity to define per function. Most companies have never written them down. That absence is the real audit finding, not the architecture.
Map each application to one of the four AWS strategies. AWS's Well-Architected guidance (Reliability Pillar, REL13-BP02) gives the honest numbers. Backup and restore: RPO in hours, RTO in 24 hours or less. Pilot light: RPO in minutes, RTO in tens of minutes. Warm standby: RPO in seconds, RTO in minutes. Multi-site active-active: RPO near zero, RTO potentially zero. Cost and operational complexity climb steeply along that ladder.
The multi-AZ camp, done right: add cross-region backups. Run highly available in one region. Continuously back up to a second region: segregated copies, restorable on segregated systems, which is the exact backup-segregation language regulators use. Accept an honest RTO measured in hours for the rare region-scale event. For every application whose true business tolerance is a day, this is a legitimate, defensible DR strategy, and dramatically cheaper than a standby region.
The second-region camp, done right: engineer out the hidden dependencies. For the few applications that genuinely cannot be down for hours, build the standby region so it actually bears a distinct risk profile. Fail over using data plane operations only: control planes have lower availability design goals, and a control plane is exactly what broke in October. Use regional STS and sign-in endpoints, not the global ones homed in us-east-1. Pre-provision quotas and capacity. Make the failover decision independent of the failing region.
Test it and write it down. A recovery objective you have never tested is a guess. This is also the letter of the regulation: DORA Art. 11(6) requires testing continuity and recovery plans at least yearly, with scenarios that include "switchovers between the primary ICT infrastructure and the redundant capacity, backups and redundant facilities". The artifact that satisfies an auditor, and a prospect's due-diligence questionnaire, is documented objectives per application plus evidence of a tested recovery. Not an architecture diagram with two of everything.
Which camp is right? Both, for different applications.
Multi-AZ plus segregated cross-region backups is a compliant, defensible answer for every application that can tolerate hours of recovery, and that is most of them. A properly engineered second region is the answer for the few that cannot. What DORA asks for is neither architecture. It asks for written recovery objectives per application, segregated restorable backups, and proof.
Teams that adopt this framing stop overbuilding and underproving. DR spend becomes proportional to each application's actual tolerance, instead of one anxious architecture decision applied to everything. And the due-diligence answer changes. "We're multi-AZ" and "we have a second region" both invite follow-up questions. "Here are our recovery objectives per application and the test evidence" ends them.
Want us to look for issues like this in your account? We offer a free AWS audit: upstood.com