DR strategies — backup, pilot light, warm standby, active-active

Disaster recovery architecture defines how a system recovers its operational state after a catastrophic failure that cannot be handled by normal redundancy mechanisms such as multi-AZ deployments or auto-scaling. The four standard DR strategies — backup and restore, pilot light, warm standby, and active-active — represent a spectrum from lowest cost and highest RTO to highest cost and lowest RTO. Selecting the correct strategy for each workload requires mapping the business’s RTO and RPO requirements to the architectural and financial cost of achieving them.

Disaster recovery architecture defines how a system recovers after a catastrophic failure that normal redundancy cannot handle. The four DR strategies — backup and restore, pilot light, warm standby, and active-active — represent a spectrum from lowest cost and highest RTO to highest cost and lowest RTO. Selecting the correct strategy requires mapping the business’s RTO and RPO requirements to the architectural and financial cost of achieving them.

The four DR strategies are not mutually exclusive across a system’s components. A realistic multi-tier application might use active-active for the API layer (zero RTO acceptable), warm standby for the database (RTO under 5 minutes, RPO under 1 minute), and backup and restore for the audit log archive (RTO 4 hours acceptable). Matching each component’s DR strategy to its specific RTO/RPO requirement rather than applying a single strategy uniformly across all components is the cost-optimal approach to DR architecture.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.