DR Strategies

The DR Spectrum

Disaster recovery strategies differ by two numbers: RTO (time to restore service) and RPO (data you can lose). Moving right along the spectrum trades money for speed:

• Backup/restore — data lives in backups copied cross-region; cheapest, RTO measured in hours, RPO equals your backup interval.
• Pilot light — core data plane replicates continuously while minimal services stay idle in the secondary region; scale up on failover.
• Warm standby — a scaled-down but running copy serves limited traffic; promote by scaling and flipping DNS; RTO in minutes.
• Multi-site active/active — everything runs in both regions behind latency-based or failover routing; lowest RTO/RPO, highest cost.

Pick per workload: a static marketing site needs backup/restore; a payments API may justify active/active.

Implementing Failover

Data replication drives the choice: Aurora Global Database replicates to a secondary region typically with sub-second lag — promote the secondary in pilot light/warm setups; S3 cross-region replication and RDS read replicas cover storage and relational tiers.

Traffic switching lives in Route 53: health checks with failover routing, or latency-based routing for active/active. Write the runbook as explicit steps: detect → verify replication lag → promote secondary → update DNS/parameters → scale capacity → validate with synthetic transactions. Backups via AWS Backup cross-region copy remain the last line even when replication is running.

Stateless tiers need no promotion — redeploy from artifacts — so invest automation there first.

Pitfalls and Interview Focus

Failover is not automatic: Route 53 health checks flip DNS only if you configure them, and IAM, KMS keys, AMIs, and container images are regional — replicate or re-provision them or the secondary region cannot boot. Sync replication protects RPO but adds write latency; async keeps latency low and opens a data-loss window — state which you chose and why.

The most common failure is never testing: DR plans decay quietly. Measure real RTO in game days — includes detection and decision, not just the deploy script.

Interview: define RTO/RPO, place the four strategies on the cost/latency line, then pick one for a stated workload and justify with its objectives.