Disaster Recovery Strategies

Recovery Point Objective (RPO) defines the maximum acceptable data loss measured in time. An RPO of 1 hour means you can afford to lose up to 1 hour of data. This determines your backup frequency. An RPO of 1 hour requires hourly backups. An RPO of 5 minutes requires continuous replication.

Recovery Time Objective (RTO) defines the maximum acceptable downtime. An RPO of 4 hours means the system must be back online within 4 hours of a disaster. This determines your recovery strategy. An RPO of 4 hours allows manual recovery from backups. An RPO of 5 minutes requires automated failover with pre-warmed infrastructure.

RPO and RTO tradeoffs: Lower RPO and RTO require more investment. An RPO of 0 (zero data loss) and RTO of 0 (zero downtime) requires active-active multi-region with synchronous replication. An RPO of 24 hours and RTO of 24 hours allows daily backups with manual restore. Most workloads fall somewhere in between.

Mapping to strategies: RPO 24h + RTO 24h = Backup and Restore. RPO 1h + RTO 30min = Pilot Light. RPO minutes + RTO minutes = Warm Standby. RPO 0 + RTO 0 = Multi-site Active-Active.

Business alignment: Work with business stakeholders to define RPO and RTO for each workload. A customer-facing payment API might need RPO 0 + RTO 15 minutes. An internal analytics dashboard might tolerate RPO 24h + RTO 4h. The cost difference between these strategies is significant.

Example: A healthcare application handling patient records requires RPO 0 (no data loss for compliance) and RTO 15 minutes (patient care cannot wait). This mandates multi-region with synchronous replication and automated failover. A marketing campaign website might tolerate RPO 1 hour + RTO 2 hours, which can be achieved with a warm standby approach.

Backup and Restore is the simplest DR strategy. Regular backups are stored in a DR region. When disaster strikes, restore from backup to new infrastructure in the DR region. RPO depends on backup frequency (hourly backups = 1 hour RPO). RTO depends on restore time (restoring a large database can take hours).

When to use: Non-critical workloads, dev/test environments, cost-sensitive applications. The cost is minimal (storage for backups) but recovery is slow.

Pilot Light keeps the core infrastructure running in the DR region at minimal scale. A small database instance, a single application server, and pre-configured networking are always running. When disaster strikes, scale up the existing infrastructure and redirect traffic. RPO is minutes (replication lag). RTO is 10-30 minutes (scale-up time).

When to use: Critical applications that need fast recovery but can tolerate some data loss. The core components are always warm, but you scale them up during failover.

Warm Standby maintains a scaled-down but functional copy of production in the DR region. The DR region runs at 20-50% capacity. When disaster strikes, scale up to full capacity and redirect traffic. RPO is seconds to minutes (replication lag). RTO is 5-15 minutes (scale-up time).

When to use: Business-critical applications requiring fast recovery with minimal data loss. The DR cost is 20-50% of production, making it a balance between cost and recovery speed.

Multi-site Active-Active runs full production capacity in multiple regions simultaneously. Both regions serve traffic and handle writes. RPO is 0 (synchronous replication). RTO is 0 (traffic shifts instantly). This is the most expensive option but provides the best recovery characteristics.

When to use: Global applications with strict uptime requirements (financial trading, healthcare, e-commerce during peak sales). The cost is 2x production, but the availability is unmatched.

DR runbooks are step-by-step procedures for executing a failover. A runbook includes: pre-failover checks, data validation steps, failover commands, post-failover verification, and rollback procedures. Write runbooks for each DR scenario: AZ failure, region failure, database corruption, and security incident.

Runbook example for region failover: 1) Verify DR region is healthy (check ASG capacity, RDS replication status). 2) Stop writes to primary database (prevent split-brain). 3) Promote DR database replica to primary. 4) Update DNS to point to DR region endpoints. 5) Verify application health in DR region. 6) Notify stakeholders of failover completion.

DR drills validate that your DR strategy actually works. Schedule regular drills (quarterly for critical workloads, annually for others). A drill simulates a disaster by failing over to the DR region and measuring actual RPO and RTO. Compare results against targets. If the drill fails, fix the issues before a real disaster occurs.

GameDays are structured DR drills. AWS GameDay provides a framework for running disaster simulations. Teams practice failover procedures in a controlled environment, identify gaps in runbooks, and improve response times. Post-drill retrospectives document lessons learned and update runbooks.

AWS Elastic Disaster Recovery (DRS) provides automated failover for EC2 instances. DRS replicates block-level data from source instances to staging areas in the DR region using asynchronous replication. When failover is needed, DRS converts replicated volumes to bootable EBS volumes and launches replacement instances.

DRS configuration: Install the DRS agent on source EC2 instances. Configure replication settings (replication interval, throttling). DRS continuously replicates to the DR region. During failover, use the DRS console to launch recovery instances with the latest data. RPO is typically under 10 minutes. RTO is minutes (instance launch time).

DRS benefits: No need to maintain warm infrastructure. Pay only for staging storage and replication. Automated block-level replication is more reliable than application-level replication. Supports heterogeneous recovery (launch different instance types in DR region).