Multi-Cloud
Disaster Recovery

This handbook exists to turn disaster recovery from a slide in a compliance deck into a rehearsed, auditable capability. It applies to any organization running production workloads across two or more of AWS, Azure, and GCP — whether that multi-cloud footprint is a deliberate resilience strategy or the accumulated result of acquisitions, team preferences, and vendor negotiations.

• Reduce ambiguity during major service disruption — every role, decision, and threshold is defined before the incident, not during it.
• Standardize recovery language across engineering, leadership, and regulators so "we're recovering" means the same thing to everyone in the room.
• Turn recovery from theory into rehearsal with runbooks that are tested on a cadence, not written once and forgotten.
• Separate recovery, validation, and failback into explicit, independently-verifiable stages.
• Prove backup posture continuously rather than assuming coverage because a policy exists somewhere.

For years, multi-region and multi-cloud DR was treated as an expensive insurance policy that mature organizations bought "eventually." Two incidents ten days apart changed the conversation from theoretical to operational, and Forrester's 2026 cloud predictions turned it into a planning assumption.

RTO (Recovery Time Objective) defines the maximum acceptable duration between an outage and restored service. RPO (Recovery Point Objective) defines the maximum acceptable data-loss window, measured back from the moment of failure. Both must be defined per application tier and backed by demonstrated recovery capability — not optimistic assumptions written into a spreadsheet once and never re-tested.

Four patterns cover nearly every production system. The right choice is the cheapest pattern that still meets the tier's RTO/RPO from §04 — over-provisioning resilience wastes budget that could harden a genuinely critical system instead.

Every well-run recovery — whether it's an automated failover or a human-led incident response — passes through the same six stages. Skipping validation to "recover faster" is the single most common cause of a second, self-inflicted outage during failback.

RTO/RPO Standards in Practice

The declared RTO/RPO for each tier drives every decision downstream: which recovery pattern is affordable (§05), what the runbook must document (§07), what backup posture must prove (§08), and how often a drill must exercise the path (§14). Treat these values as engineering requirements with the same rigor as a latency SLO — because functionally, that's what they are.

• Every production system has a declared RTO and RPO mapped to one of the four tiers in §04.
• Recovery owner and incident commander are named — by role, with a current on-call rotation, not a person's name that goes stale when they change teams.
• Backup location and restore steps are documented at the level of detail an engineer unfamiliar with the system could execute under pressure.
• Validation steps cover application, data, and external integrations — a restored database that can't reach its payment processor is not a recovered system.
• Communication templates exist before the incident starts — drafting a customer-facing status update during an active outage costs minutes you don't have.
• Runbook test date and evidence are recorded, with a defined maximum staleness (see §14) before the runbook is considered unverified.

The most common cause of a failed multi-cloud recovery isn't a bad runbook — it's a resource that was never covered by a backup policy in the first place, or a policy that drifted out of sync as the environment changed. Most teams cannot currently prove, on demand, that every critical resource across every cloud account has a current, recoverable backup. Cloud Backup Posture Management (CBPM) is the operational discipline that closes that gap continuously rather than at quarterly-audit time.

Replication lag must be measured continuously, not assumed from a dashboard that says "healthy." Backups are only considered valid after a successful restore test — an unverified backup is a liability that looks like an asset. Failback must be treated as its own controlled event with explicit validation and rollback criteria, not the automatic reverse of a failover.

Manual, ad-hoc recovery across multiple cloud providers introduces exactly the kind of cognitive load that produces mistakes at the worst possible time. The 2026 standard is to express the full restoration sequence as reusable, versioned, auditable workflows — pipelines and orchestrators, not custom shell scripts that live on one engineer's laptop and are difficult to audit or fork safely.

Major incidents require parallel technical recovery and stakeholder communication — not one after the other. Define, before the incident, who communicates to leadership, who communicates to customers, and who owns engineering coordination, so the recovery team is never interrupted to answer the same "what's the status" question twice.

For EU financial entities, the Digital Operational Resilience Act (DORA) — in force since January 17, 2025 — turns much of this handbook from best practice into a legal obligation. DORA requires ICT business continuity policies, disaster recovery plans, and backup policies that are tested regularly and updated based on lessons learned from disruptions, resilience testing, and audit findings. Non-compliance penalties reach into the millions of euros or a percentage of global annual turnover.

Outside financial services, the EU's NIS2 Directive extends comparable ICT risk-management and incident-reporting obligations to a broader set of "essential" and "important" entities across energy, healthcare, transport, and digital infrastructure sectors. Even organizations outside direct DORA/NIS2 scope increasingly see these frameworks referenced in customer security questionnaires and vendor due-diligence — treat the runbook evidence this handbook requires as reusable compliance artifact, not overhead.

Regular testing is what separates a disaster recovery plan from a disaster recovery capability. Non-disruptive testing techniques let teams validate failover procedures and confirm RTO/RPO targets without impacting production workloads — there is no longer a good excuse for "we can't test because it's too risky."

• Recovery roles are current — verify the on-call rotation and named owners in every runbook header still resolve to real people.
• Failover triggers and decision rules are understood by everyone on the rotation, not just the person who wrote the runbook.
• Restore procedures have been tested recently, against the specific staleness threshold declared per tier (Tier 0: monthly, Tier 1: quarterly, Tier 2: semi-annually, Tier 3: annually).
• Runbooks match the live architecture — a drill that surfaces a stale runbook is a successful drill; a drill skipped because "the runbook is probably fine" is not.
• Failback is rehearsed, not improvised — treat failback as its own drill, not an assumed inverse of failover.
• Chaos scenarios include hidden dependencies — deliberately fail the monitoring or auth system a recovery workflow depends on, per §03's lesson.

Most organizations are at Stage 1 or early Stage 2 for the majority of their services, with only their most critical systems reaching Stage 3 or 4. Advance tier by tier — a Stage 2 capability with honest, tested RTO/RPO numbers is worth more than a Stage 4 architecture diagram that has never been drilled.

Do not attempt to bring every service to Stage 3 simultaneously. Start with the systems where a failure would be most damaging, prove the pattern works, then extend it service by service.