Every IT lead evaluating cloud disaster recovery eventually hits the same uncomfortable moment: someone in the room assumes the cloud already handles recovery. It does not. Moving disaster recovery (DR) to the cloud can make recovery faster, cheaper, and far easier to test than running a second data centre, but only when you design it around explicit recovery objectives, because the cloud does not recover itself.
The rest of this article unpacks what cloud DR actually is, where your provider's responsibility ends and yours begins, the four strategies that map cost to recovery speed, and how to build and test a plan that survives contact with a real outage.
What is cloud disaster recovery?
Cloud disaster recovery is the practice of replicating systems, applications, and data to cloud infrastructure so an organisation can restore critical IT operations after an incident. It uses on-demand compute and storage instead of a standing secondary site, letting teams recover to defined recovery time and recovery point objectives at lower fixed cost and with more frequent testing.
That definition matters because cloud DR is often confused with backup, with high availability, or with the provider's own uptime guarantees. None of those is a recovery plan. A recovery plan is a deliberate design that says which workloads come back, in what order, how fast, and who executes it.
How cloud DR fits into business continuity
Cloud disaster recovery is the IT recovery mechanism, not the whole continuity picture. Business continuity is a holistic process: it starts with a business impact analysis (BIA), informs the development of business continuity plans and recovery strategies, and helps an organisation keep critical operations running during and after an incident. Cloud DR executes the technical half of those recovery strategies for digital workloads.
The ordering is non-negotiable. Recovery objectives come from the BIA and drive the cloud DR design, never the reverse. ISO 22301:2019 Clause 8.4 requires documented business continuity plans and procedures, and ISO/IEC 27031 frames ICT readiness as a distinct component of continuity rather than an afterthought. If you are standing up cloud DR as part of a broader programme, anchor it to your IT DR plan so the technical recovery steps trace back to business priorities.
Cloud DR vs traditional secondary-site DR
Traditional disaster recovery relies on a physical secondary site: standing hardware, floor space, cooling, and a capital budget that sits mostly idle waiting for a disaster that may never come. Cloud DR flips the economics. You provision infrastructure on demand and pay for meaningful capacity mainly at failover, which is why a mid-market team can afford geographic redundancy that used to be a large-enterprise luxury.
The bigger practical difference is testing. An idle secondary site is expensive and disruptive to exercise, so many organisations test it once a year, badly. Cloud DR can be tested more often and more cheaply because you can spin up a recovery environment, validate it, and tear it down. Both models depend on the same underlying concepts. NIST SP 800-34 Rev. 1 defines the recovery time objective and recovery point objective that every DR design, cloud or not, has to hit.
| Attribute | Traditional secondary-site DR | Cloud disaster recovery |
|---|---|---|
| Cost model | Capital-heavy, mostly idle | Pay for capacity mainly at failover |
| Time to provision recovery | Weeks to months for hardware | Minutes to hours via automation |
| Testing frequency | Often annual, disruptive | Frequent, spin-up and tear-down |
| Geographic redundancy | Costly second facility | Multiple regions by default |
The shared responsibility model: what your provider covers vs what you own
The single most dangerous assumption in cloud DR is that the provider handles recovery. Hyperscalers publish availability targets and run enormous redundancy, but their uptime commitment and your recovery plan are not the same thing. When a region fails, customers who designed around "it's the cloud, it's resilient" discover the difference in real time.
Where the provider's responsibility ends
Under the shared responsibility model, the provider owns the physical infrastructure, the hardware, and regional availability. You own your data, your configuration, your architecture, and your recovery design. A single-region deployment inherits that region's fate, and no service level agreement changes that.
| Layer | Cloud provider owns | You own |
|---|---|---|
| Physical infrastructure | Data centres, power, hardware | Nothing at this layer |
| Regional availability | Availability zones, region uptime SLAs | Choice of regions and cross-region design |
| Platform services | Service-level operation and patching | Configuration, IAM, encryption keys |
| Data and applications | None | Data, backups, replication, DR runbook |
| Recovery plan | None | Objectives, testing, documentation, execution |
On 20 October 2025, a DNS resolution failure in Amazon Web Services' US-EAST-1 region, triggered by an empty DNS record and incorrect automation updates, cascaded through DynamoDB dependencies to knock out 141 AWS services. The outage ran roughly 15 hours and affected more than 4 million users and over 1,000 companies. Firms with genuine cross-region failover kept running. Firms that had quietly concentrated everything in one region did not. The provider met its obligations; the recovery gap was the customers'.
Why "the cloud is resilient" is a failed recovery waiting to happen
Cloud outages are getting more frequent and lasting longer. Critical service interruptions across AWS, Azure, and Google Cloud rose 18% and lasted 18.7% longer in 2024 versus 2023, and the three providers together logged more than 100 service outages between August 2024 and August 2025. Resilience is not a default setting.
Cascading dependency failures are what widen the blast radius. Authentication systems, DNS, and control planes are shared dependencies, so when one degrades, the damage rarely stays contained.
The CrowdStrike outage is the cleanest example of why an assumption is not a plan. A faulty Channel File 291 content update to the Falcon sensor, pushed early on 19 July 2024, forced roughly 8.5 million Windows endpoints into boot loops with the Blue Screen of Death. CrowdStrike reverted the update within about 78 minutes, but that did not matter: recovery required manual, machine-by-machine intervention. Delta cancelled around 7,000 flights over five days. The Harvard Business Review analysis of the incident makes the point sharply. A cloud-hosted control plane does not save you if the failure mode requires touching every device. Design for the recovery you'll actually have to perform, not the one you hope for.
The four main cloud DR strategies and how they map to RTO/RPO and cost
There are four canonical cloud DR patterns, and they exist on a single spectrum: the more you pay in steady state, the faster you recover. The mistake is picking one pattern for the whole organisation. Recovery targets vary by workload, so your strategy should too.
Backup and restore, pilot light, warm standby, and multi-site active-active
Each pattern trades cost against recovery speed differently:
- Backup and restore. Lowest cost, longest recovery time. Data and images are stored in the cloud and rebuilt on demand. Suits non-critical workloads where hours of downtime are tolerable.
- Pilot light. Core services, typically the database and critical configuration, run minimally in the recovery region and scale up only at failover. Faster than a cold restore, modest steady-state cost.
- Warm standby. A scaled-down but always-running copy of the environment. Failover is fast because the system is already live; you pay more to keep it warm.
- Multi-site active-active. Full production capacity running in two or more regions simultaneously, serving traffic. Near-zero recovery time and data loss, at the highest cost and operational complexity.
Matching a strategy to a target: a mid-market example
Take a mid-market team with an order-management platform its BIA rates as critical, with a two-hour RTO and a fifteen-minute RPO. Backup and restore cannot hit that. The real choice is pilot light versus warm standby.
Pilot light keeps the database replicating into a second region while the application tier sits dormant. At failover, the team scales the application tier up, which takes time, plausibly 45 to 90 minutes on top of DNS cutover. Warm standby keeps a scaled-down application tier running continuously, so failover is a matter of shifting traffic and scaling out, comfortably inside the two-hour target with margin to spare. Warm standby costs more every month. That premium is justified for a workload where two hours of downtime hurts, and unjustified for the same company's internal reporting tool.
The discipline NIST SP 800-34 pushes is to tier workloads and select recovery strategies per service against defined objectives. Higher cost buys lower RTO and RPO. Make that trade explicitly, workload by workload, and justify each against business impact.
Where DRaaS fits
Disaster Recovery as a Service (DRaaS) bundles replication, orchestration, and failover into a managed offering. For teams without in-house DR engineering capacity, that is a legitimate way to reach a recovery capability faster than building it from parts.
The trade is dependency. DRaaS introduces a third party into your recovery path and adds concentration risk you now have to manage. And it does not transfer ownership: the recovery objectives, the testing regime, and the runbook documentation stay yours. Outsourcing the mechanism is fine. Outsourcing accountability is not a thing.
How to build a cloud DR plan
Building cloud DR is an ordered process, and every step ties back to the objectives that make recovery provable rather than assumed. Do these in sequence:
- Run a BIA to set an RTO and RPO for each critical service.
- Select a strategy per workload from the four patterns and design the target recovery architecture.
- Automate replication and failover using infrastructure as code and orchestration so recovery is repeatable, not heroic.
- Document a runbook covering roles, trigger criteria, failover steps, and failback steps.
- Protect the recovery copies with immutable, ideally air-gapped, backups.
- Test the plan, then update it from what the test exposes.
Step-by-step: from BIA to runbook
The seven-step contingency planning process in NIST SP 800-34, and its Appendix B BIA template, is the most usable public scaffold for this. It forces the sequence: policy, BIA, preventive controls, recovery strategy, plan development, testing, and maintenance. ISO 22301 Clause 8.4 adds the requirement that the resulting plans and procedures are actually documented and maintained.
The runbook is where most plans quietly fail. A recovery procedure that only its author can follow, or that has drifted from the live architecture, is a document pretending to be a capability. Write it so an on-call engineer who did not design the system can execute a failover under pressure.
Protecting backups against ransomware
Cloud DR that can be encrypted by the same attacker who hit production is not recovery, it's a second victim. Immutable and air-gapped cloud backups exist so that attackers who reach your environment cannot alter or delete the copies you'll recover from.
The entry vectors are well documented. Exploited vulnerabilities were the root cause in 32% of ransomware attacks and compromised credentials in 23%, according to Sophos. Clean, recoverable backups shorten recovery and strip away the attacker's bargaining position, and the trend is moving in the right direction: 53% of ransomware victims recovered within a week in 2025, up from 35% in 2024. In practice, the backup-versus-disaster-recovery question comes down to one thing: can your backups survive the attack and actually restore the business?
Testing and validating cloud disaster recovery
Untested cloud DR is an assumption wearing the costume of a capability. The only way to know your recovery time meets your target is to recover and measure it. This is also where regulated firms feel the most scrutiny.
Test methods and frequency
Three test types validate different things, and mature programmes run all three. A tabletop walks the team through the runbook to find gaps in roles and decision-making. A simulation exercises parts of the technical failover without full cutover. A full failover proves the whole path end to end, ideally against live-like conditions.
Test after any significant architecture change and at least annually. Measure actual recovery time against the RTO and RPO you set, and feed every finding back into the runbook. The ICT readiness guidance in ISO/IEC 27031 treats testing as an ongoing obligation, not a one-off certification exercise. For a fuller treatment of cadence and method, work through structured disaster recovery testing.
Regulatory testing expectations (financial services)
Financial services carries the heaviest testing burden, and cloud makes it more, not less, pointed. DORA Article 11 requires response and recovery plans, Article 12 sets backup and restoration requirements, and the regime mandates regular testing including cyber-attack scenarios. In the UK, FCA PS21/3 requires scenario testing against impact tolerances for important business services, and APRA CPS 230 requires Australian regulated entities to maintain critical operations within tolerance and to keep a register of material service providers.
The cloud angle sharpens this. Under FCA outsourcing and operational resilience guidance, cloud services are treated as material outsourcing, so your provider's regional failure becomes your regulatory problem. Concentration on a single provider or region is not just an availability risk; for financial services it's a governance finding waiting to happen.
Common cloud DR pitfalls and how to avoid them
Most failed cloud recoveries trace back to a small set of avoidable assumptions. Each has a concrete correction anchored to recovery objectives.
The assumptions that cause failed recoveries
The recurring mistakes:
- Single-region deployment with no cross-region failover. The fix is designing failover across regions for workloads whose RTO cannot survive a regional outage.
- Never testing failover, or only testing the happy path. Test the messy paths: partial failures, stale replicas, DNS propagation delays.
- Ignoring egress costs and data sovereignty in DR site selection. Recovering to a region you can't legally use, or that costs a fortune to pull data from, is a plan that dies at execution.
- Vendor concentration. One provider is a single point of failure, and durations vary wildly between them.
That last point has numbers behind it. Between August 2024 and August 2025, the average AWS incident lasted 1.5 hours, Google Cloud averaged 5.8 hours, and Azure averaged 14.6 hours. Azure's East US2 networking outage in early 2025, caused by a networking configuration change that lost indexing data in the Azure PubSub service, ran for roughly 50 hours and hit zonally redundant services across multiple zones. "Zonally redundant" did not mean "recovered" for the customers depending on it.
Cyber risk keeps this at board level. Cyber security was rated the highest risk concern for the next five to ten years, at 63.6% in the BCI Horizon Scan 2025. Treat cloud DR as a tested capability tied to a defined cloud DR strategy, and it becomes an answer to that concern rather than another exposure inside it.
