Disaster Recovery (DR)
Last reviewed: August 2026
What Is DR
Section titled “What Is DR”Disaster Recovery (DR) is the plan and process for restoring service within a predefined target time when service is interrupted by a natural disaster, hardware failure, human error, or similar event.
Defining a Disaster
Section titled “Defining a Disaster”To build a DR plan, you first need to define “what counts as a disaster.” A disaster is a different order of event from a single resource failure.
Types of Disasters
Section titled “Types of Disasters”| Category | Examples | Scope of Impact |
|---|---|---|
| Natural disaster | Earthquake, flood, typhoon, fire, power outage | A single or multiple data centers, a region |
| Hardware/infrastructure failure | Power supply failure, network backbone disconnection, storage cluster damage | A single AZ to a region |
| Software/platform failure | Cloud vendor’s region-wide service outage, deployment failure | A single service to a region |
| Human error | Accidental deletion, incorrect change, misconfiguration | A single resource to an entire account |
| Security incident | Ransomware, data breach, credential theft | Data, account, region |
| External supply chain issue | External API/service outage, SaaS vendor failure | Scope of that dependency |
Classifying Disaster Levels
Section titled “Classifying Disaster Levels”Response strategies are applied differently depending on the scope of failure.
| Level | Definition | Response |
|---|---|---|
| Local failure | A single server or single resource fails | Auto-scaling, health-check-based automatic recovery |
| AZ failure | An entire single Availability Zone goes down | Multi-AZ deployment, automatic failover between AZs |
| Regional failure | An entire region goes down (rare, but does happen) | Cross-region replication, region-to-region DR |
| Vendor failure | An entire cloud vendor outage | Multi-cloud DR (high cost/complexity) |
The Difference Between Disaster and High Availability
Section titled “The Difference Between Disaster and High Availability”High Availability (HA) is a design that keeps service running even when individual failures occur. DR is a recovery strategy for failures at a scale (regional disaster) that HA cannot prevent.
| Aspect | High Availability (HA) | Disaster Recovery (DR) |
|---|---|---|
| Goal | Maintain uninterrupted service | Recover service after a disaster |
| Target failure | Failures within an AZ | Failures at regional scale or above |
| Implementation | Multi-AZ, load balancers, automatic failover | Cross-region replication, DR site |
| Cost | Relatively low | High (duplicate infrastructure) |
Key Metrics: RPO and RTO
Section titled “Key Metrics: RPO and RTO”| Metric | Definition | Business Meaning |
|---|---|---|
| RPO (Recovery Point Objective) | Maximum acceptable data loss time upon recovery | “How many minutes/hours of data can we afford to lose at most?” |
| RTO (Recovery Time Objective) | Maximum acceptable time to restore service after a failure | “Within how many minutes/hours must service be back at most?” |
RPO and RTO are derived from business requirements. They are not set arbitrarily by the technical team, but determined through a Business Impact Analysis (BIA).
Alignment with Business Goals
Section titled “Alignment with Business Goals”Business Impact Analysis (BIA)
Section titled “Business Impact Analysis (BIA)”Before setting DR targets, you first need to define the following:
- Identify core business processes — which systems, if interrupted, directly impact revenue/customers?
- Estimate the cost of downtime — what is the cost per hour/minute of downtime? (revenue loss, penalties, reputational damage)
- Derive RPO/RTO — set targets at the balance point between downtime cost and DR build cost
- Classify tiers — applying the same DR level to all systems is excessively costly. Classify by importance tier
| Tier | RPO | RTO | DR Strategy | Examples |
|---|---|---|---|---|
| Tier 1 (mission-critical) | 0 (no data loss allowed) | Minutes | Active-Active / Hot Standby | Payment systems, trading platforms |
| Tier 2 (business-critical) | Minutes to 1 hour | 1-4 hours | Warm Standby | Order management, CRM |
| Tier 3 (general business) | Hours to 24 hours | 24 hours | Pilot Light / Backup & Restore | Internal tools, development environments |
DR Strategy Types
Section titled “DR Strategy Types”graph LR
A["🗄️ Backup & Restore<br/>RPO: hours<br/>RTO: hours<br/>Cost: low"]
B["💡 Pilot Light<br/>RPO: minutes<br/>RTO: tens of minutes<br/>Cost: medium"]
C["🔆 Warm Standby<br/>RPO: seconds-minutes<br/>RTO: minutes<br/>Cost: high"]
D["⚡ Active-Active<br/>RPO: 0<br/>RTO: near 0<br/>Cost: very high"]
A -->|raise recovery target| B -->|raise recovery target| C -->|raise recovery target| D
| Strategy | RPO | RTO | Cost | Description |
|---|---|---|---|---|
| Backup & Restore | Hours | Hours | Low | Restore from regular backups upon failure. Cheapest but slowest |
| Pilot Light | Minutes | Tens of minutes | Medium | Only core infrastructure runs at minimal scale at all times. Scale up on failure |
| Warm Standby | Seconds to minutes | Minutes | High | A scaled-down full environment runs at all times. Scale up on failure |
| Active-Active | 0 | Near 0 | Very high | Traffic handled simultaneously in two regions. Automatic failover on failure |
Implementation by Strategy — Vendor Service Mapping
Section titled “Implementation by Strategy — Vendor Service Mapping”The vendor services used to actually implement each strategy above.
Backup & Restore Implementation
Section titled “Backup & Restore Implementation”Data is replicated to another region in advance, and infrastructure is newly created and restored in that region upon failure.
| Role | AWS | Azure | Google Cloud | OCI |
|---|---|---|---|---|
| Storage replication | S3 Cross-Region Replication | Geo-Redundant Storage (GRS) | Multi-region Storage | Cross-Region Copy |
| DB backup replication | RDS automated cross-region backup copy | Azure SQL Geo-Backup | Cloud SQL cross-region backup | Data Guard (Standby) |
| Infrastructure recreation | CloudFormation / Terraform | ARM / Bicep / Terraform | Terraform | Resource Manager / Terraform |
Pilot Light to Warm Standby Implementation
Section titled “Pilot Light to Warm Standby Implementation”Core infrastructure runs at minimal/reduced scale in the DR region at all times, and scales up upon failure.
| Role | AWS | Azure | Google Cloud | OCI |
|---|---|---|---|---|
| DR orchestration | Elastic Disaster Recovery (DRS) | Azure Site Recovery (managed via Resiliency) | — (configured as an architecture pattern) | Full Stack DR |
| DB real-time replication | RDS Cross-Region Read Replica, Aurora Global DB | Azure SQL Geo-Replication | Cloud SQL Cross-Region Replica | Data Guard (Active) |
| Traffic switching | Route 53 Failover | Traffic Manager / Front Door | Cloud DNS + Global LB | DNS Traffic Management |
Active-Active Implementation
Section titled “Active-Active Implementation”Traffic is handled simultaneously in two regions, and if one fails, the other absorbs the full load.
| Role | AWS | Azure | Google Cloud | OCI |
|---|---|---|---|---|
| Global routing | Route 53 + Global Accelerator | Front Door | Global HTTP(S) LB | DNS Traffic Management |
| Global database | Aurora Global Database, DynamoDB Global Tables | Cosmos DB (Multi-region Write) | Spanner | Autonomous DB (Cross-Region) |
| State synchronization | ElastiCache Global Datastore | Azure Cache Geo-Replication | Memorystore Cross-Region | — |
DR Testing
Section titled “DR Testing”A DR plan is meaningless if it isn’t tested. You must regularly verify that it works as planned when an actual failure occurs.
Test Types
Section titled “Test Types”| Type | Description | Frequency |
|---|---|---|
| Tabletop Exercise | Scenario-based discussion. No actual system changes | Quarterly |
| Walkthrough Test | Execute the recovery procedure step by step, without affecting production | Semi-annually |
| Simulation Test | Perform an actual failover, but within a limited scope | Annually |
| Full Interruption Test | Actually shut down the production region and switch to the DR region | Annually (optional) |
What to Check During Testing
Section titled “What to Check During Testing”- Is the actual RTO within the target RTO?
- Is the actual RPO within the target RPO? (verify the amount of data lost)
- Does the failback (returning to the original region) procedure work?
- Are the runbooks/automation scripts up to date?
- Are the responsible personnel familiar with the procedure?
Relationship to Chaos Engineering
Section titled “Relationship to Chaos Engineering”Beyond DR testing, Chaos Engineering is the practice of routinely injecting failures to verify system resilience.
| Vendor | Native tool |
|---|---|
| AWS | AWS Fault Injection Service |
| Azure | Azure Chaos Studio |
Google Cloud and OCI do not offer a native chaos engineering service. They rely on vendor-neutral third-party tools such as Gremlin and LitmusChaos, which also work across all clouds including AWS and Azure.
DR Regions by Country and Regulation
Section titled “DR Regions by Country and Regulation”When choosing a secondary region, look not only at latency but also at whether data leaves the jurisdiction. A region pair in the same country enables in-country DR; using a neighboring country’s region creates cross-border transfer requirements. See each country guide for primary and secondary candidates:
- Korea — Seoul, Busan, Chuncheon; vendors with in-country DR; cross-border personal data transfer
- United States — FedRAMP, data residency
- EU — GDPR, sovereign cloud
- Japan — ISMAP, Government Cloud
- Singapore — MTCS, PDPA
Common Mistakes
Section titled “Common Mistakes”- Building a DR plan and never testing it — during an actual failure, outdated runbooks fail to work, and the target RTO cannot be achieved
- Applying the same DR strategy to every system — designing everything as Active-Active without considering cost, or leaving everything at Backup & Restore
- Not reviewing data sovereignty when using an out-of-jurisdiction DR region — regulatory violations from failing to confirm cross-border personal data transfer and residency requirements
Checklist
Section titled “Checklist”- Have you defined RPO/RTO per workload based on a Business Impact Analysis (BIA)?
- Do you perform DR testing (at minimum a Walkthrough) at least once a year and keep runbooks up to date?
- If using an out-of-jurisdiction DR region, have you met the legal requirements for cross-border data transfer?
Related Documents
Section titled “Related Documents”References
Section titled “References”- AWS Disaster Recovery whitepaper
- AWS Elastic Disaster Recovery — 2026 updates: Fast Recovery mode (skips conversion for reduced recovery time), IPv6 support, European Sovereign Cloud availability
- AWS Fault Injection Service
- Azure Site Recovery documentation
- Azure Resiliency (formerly Business Continuity Center) — rebranded as a unified management platform integrating Zone Resiliency, HA, Backup & DR, and Ransomware Protection
- Azure Chaos Studio
Google Cloud
Section titled “Google Cloud”- OCI Full Stack DR — 2025–2026 expansions: AI-powered log summaries (Generative AI service integration), multicloud database support (Oracle DB@Azure/AWS/Google Cloud), OKE cross-region DR, Policy Advisor (automated IAM policy analysis), Oracle Integration Cloud native integration
- OCI business continuity guide