2.2.2.2. Disaster Recovery (DR) Strategies: RPO, RTO

2.2.2.2. Disaster Recovery (DR) Strategies: RPO, RTO

💡 First Principle: Disaster Recovery (DR) strategies rapidly restore critical systems and data after disruptive events, minimizing downtime and data loss for continuous business operations.

Disaster Recovery (DR) strategies rapidly restore critical systems and data after disruptive events, minimizing downtime and data loss for continuous business operations.

Disaster Recovery (DR) is a comprehensive plan to prepare for and recover from major outages or disasters that could affect an entire data center or AWS Region. Two fundamental metrics guide DR strategy:

• Recovery Time Objective (RTO): The maximum tolerable duration of time that a system or application can be down after a disaster. It defines how quickly you need to recover (e.g., 15 minutes, 4 hours). A low RTO demands rapid recovery mechanisms.
• Recovery Point Objective (RPO): The maximum tolerable amount of data loss, measured in time. It defines how much data you can afford to lose (e.g., 0 seconds, 5 minutes, 1 hour). A low RPO requires frequent backups or continuous replication.

Key DR Strategies (from highest RTO/RPO/lowest cost to lowest RTO/RPO/highest cost):

1. Backup and Restore: Longest RTO/RPO, lowest cost.
2. Pilot Light: Key components always running, minimal infrastructure.
3. Warm Standby: Scaled-down, fully functional replica, continuously updated.
4. Multi-Site Active/Active: Fully deployed in multiple Regions, serving traffic simultaneously, near-zero RTO/RPO.

Typical recovery objectives (AWS DR whitepaper): Backup & Restore — RPO/RTO of hours; Pilot Light — tens of minutes; Warm Standby — minutes; Multi-Site Active/Active — near zero. The Pilot Light vs. Warm Standby line: pilot light keeps the data tier live and replicating, but application servers are switched off, so it cannot serve requests until they are launched and scaled; warm standby is already running and can take traffic immediately at reduced capacity, then scales up.

Service quotas in the DR Region: Most quotas (for example, EC2 On-Demand vCPU limits) apply per account per Region, and a recovery Region does not inherit increases made in the primary. Request increases in the recovery Region ahead of time through Service Quotas, or a failover or scale-out fails with a quota error such as InstanceLimitExceeded. That is different from InsufficientInstanceCapacity, which means AWS lacks spare capacity for that instance type at that moment; On-Demand Capacity Reservations guarantee the capacity itself.

Scenario: An organization implements a backup and restore DR strategy for its e-commerce platform on AWS, targeting an RPO of 15 minutes (S3 backup) and an RTO of 4 hours (rebuilding infrastructure and launching EC2 from AMIs). Note: this is Backup and Restore, not Pilot Light — a true Pilot Light strategy requires core data services (e.g., a database) to already be running and replicating in the DR Region, not rebuilt from a backup.

Visual: Disaster Recovery (DR) Strategies (RPO/RTO vs. Cost)

⚠️ Common Pitfall: Choosing a DR strategy that is too expensive or complex for the actual RPO/RTO requirements of the workload. Not all applications need active-active multi-region DR.

Key Trade-Offs:

• RPO/RTO vs. Cost: There's a direct correlation: lower RPO/RTO (less data loss, faster recovery) typically means higher cost due to increased infrastructure and replication.

Reflection Question: How do RPO and RTO influence the choice and cost of a DR strategy for different business functions, balancing acceptable downtime/data loss with financial investment?