Definition
- RPO (Recovery Point Objective) – how much data you can afford to lose, measured as a time window; tighter RPO requires more frequent or continuous replication.
- RTO (Recovery Time Objective) – how long you can afford to be down; tighter RTO requires more standby infrastructure ready to take over.
- Backup and Restore – keep backups, rebuild on disaster; RPO = backup frequency, RTO = hours.
- Pilot Light – keep the critical core (replicated DB) always running; scale up the app on disaster; RPO = seconds to minutes, RTO = tens of minutes.
- Warm Standby – run a scaled-down fully functional copy; scale up on disaster; RPO = small, RTO = minutes.
- Multi-Site Active-Active – full capacity in multiple Regions serving live traffic; RPO and RTO near zero.
Imagine National Bank of India must survive its main building being destroyed. Backup and Restore is keeping copies of all records in a warehouse and rebuilding from scratch -- cheap but takes hours. Pilot Light is keeping just the vault mirrored in a second building, lights off, ready to furnish quickly. Warm Standby is a smaller working branch that you scale up rapidly. Multi-Site Active-Active is two full branches both serving customers, so if one is destroyed the other keeps going.
Understanding the Concepts
What are RPO and RTO?
RPO answers how much data you can lose. If your RPO is five minutes, you must recover to a state no more than five minutes before the disaster, which demands frequent or continuous replication. RTO answers how long you can be down. If your RTO is ten minutes, the whole failover must complete within ten minutes. Tighter objectives cost more.
// DR targets drive the strategy choice
package com.bank.infrastructure;
public class DrTargets {
private final String workload;
private final int rpoMinutes;
private final int rtoMinutes;
public DrTargets(String workload, int rpoMinutes, int rtoMinutes) {
this.workload = workload;
this.rpoMinutes = rpoMinutes;
this.rtoMinutes = rtoMinutes;
}
public static void main(String[] args) {
DrTargets ledger = new DrTargets("Core Ledger", 1, 5);
DrTargets api = new DrTargets("Customer API", 15, 30);
DrTargets reports = new DrTargets("Internal Reports", 1440, 240);
System.out.println(ledger.workload + ": RPO=" + ledger.rpoMinutes + "m, RTO=" + ledger.rtoMinutes + "m");
System.out.println(api.workload + ": RPO=" + api.rpoMinutes + "m, RTO=" + api.rtoMinutes + "m");
System.out.println(reports.workload + ": RPO=" + reports.rpoMinutes + "m, RTO=" + reports.rtoMinutes + "m");
}
}
What is Backup and Restore?
Backup and Restore is the cheapest strategy. You take regular backups -- EBS snapshots, RDS snapshots, S3 cross-region copies -- and on disaster you provision infrastructure from infrastructure-as-code and restore from backup. RPO equals your backup frequency and RTO is hours because you rebuild from nothing.
// Backup and Restore strategy
package com.bank.infrastructure;
public class BackupRestoreStrategy {
public static void explain() {
System.out.println("Backup and Restore:");
System.out.println(" Daily backups to another Region (S3, RDS snapshots)");
System.out.println(" On disaster: deploy IaC -> restore backups -> start app");
System.out.println(" RPO: hours (= backup frequency)");
System.out.println(" RTO: hours (rebuild from scratch)");
System.out.println(" Cost: lowest (only backup storage)");
System.out.println(" Suitable for: internal reporting, non-critical workloads");
}
}
What is Pilot Light?
Pilot Light keeps the critical core always running in the recovery Region, typically a continuously replicated database. The application tier exists only as configuration or stopped resources. On disaster you start the application tier, scale it up, and point traffic over. Because the data is already there, RPO is small.
// Pilot Light strategy
package com.bank.infrastructure;
public class PilotLightStrategy {
public static void explain() {
System.out.println("Pilot Light:");
System.out.println(" Replicated database running in DR Region (continuous)");
System.out.println(" App tier: AMIs/containers ready but NOT running");
System.out.println(" On disaster: start app tier -> scale up -> Route 53 failover");
System.out.println(" RPO: seconds to minutes (continuous replication)");
System.out.println(" RTO: tens of minutes (start and scale app)");
System.out.println(" Cost: moderate (replicated DB + dormant app config)");
}
}
What is Warm Standby?
Warm Standby runs a scaled-down but fully functional copy of the entire stack in the recovery Region all the time. On disaster you scale it up to full capacity and shift traffic. The system is already running and just needs to grow.
// Warm Standby strategy
package com.bank.infrastructure;
public class WarmStandbyStrategy {
public static void explain() {
System.out.println("Warm Standby:");
System.out.println(" Scaled-down copy running in DR Region (fully functional)");
System.out.println(" Replicated database + running app at reduced capacity");
System.out.println(" On disaster: scale up to full -> Route 53 failover");
System.out.println(" RPO: small (continuous replication)");
System.out.println(" RTO: minutes (already running, just scale)");
System.out.println(" Cost: higher (always-on standby)");
}
}
What is Multi-Site Active-Active?
Multi-Site Active-Active runs full capacity in two or more Regions, all serving live traffic, with data replicated both ways or a globally distributed database. If a Region fails, the others absorb its traffic almost instantly. RPO and RTO are near zero. It is the most expensive and complex.
// Multi-Site Active-Active strategy
package com.bank.infrastructure;
public class ActiveActiveStrategy {
public static void explain() {
System.out.println("Multi-Site Active-Active:");
System.out.println(" Full capacity in 2+ Regions, all serving live traffic");
System.out.println(" Data: bidirectional replication or global database");
System.out.println(" On Region failure: others absorb traffic instantly");
System.out.println(" RPO: near zero");
System.out.println(" RTO: near zero (seconds)");
System.out.println(" Cost: highest (full infra in each Region)");
System.out.println(" Complexity: data consistency across Regions");
}
}
How do you choose a strategy per workload?
You do not pick one strategy for the whole company. You pick per workload based on business criticality. The core payment ledger might justify Active-Active, while an internal analytics dashboard is fine on Backup and Restore.
| Strategy | RPO | RTO | Cost | Best For |
|---|---|---|---|---|
| Backup and Restore | Hours | Hours | Lowest | Internal, non-critical |
| Pilot Light | Minutes | Tens of min | Moderate | Important services |
| Warm Standby | Small | Minutes | Higher | Customer-facing |
| Active-Active | Near zero | Near zero | Highest | Core banking, payments |
// Strategy selector based on RPO/RTO targets
package com.bank.infrastructure;
public class DrStrategySelector {
public static String select(int rpoMinutes, int rtoMinutes) {
if (rpoMinutes <= 1 && rtoMinutes <= 5) return "Multi-Site Active-Active";
if (rpoMinutes <= 15 && rtoMinutes <= 30) return "Warm Standby";
if (rpoMinutes <= 60 && rtoMinutes <= 60) return "Pilot Light";
return "Backup and Restore";
}
}
Why must you test DR regularly?
A DR plan is worthless unless you test the failover regularly, because untested recovery procedures fail exactly when you need them. Game-day exercises validate that the RTO and RPO are actually achievable, that runbooks work, and that the team knows what to do under pressure.
// DR testing schedule
package com.bank.infrastructure;
public class DrTestingSchedule {
public static void main(String[] args) {
System.out.println("DR Testing Schedule for NBI:");
System.out.println(" Quarterly: game-day failover drill for core ledger");
System.out.println(" Monthly: backup restoration test for reporting DB");
System.out.println(" Annually: full Region failover exercise");
System.out.println();
System.out.println("After each test:");
System.out.println(" 1. Record actual RPO and RTO achieved");
System.out.println(" 2. Document gaps and failures");
System.out.println(" 3. Update runbooks and automation");
}
}
What should a senior engineer know?
Senior engineers know that the four strategies are not mutually exclusive within an organization. They pick per workload, they automate failover with Route 53 health checks and infrastructure-as-code, and they track RPO and RTO as measurable SLIs. They also know that cross-Region data replication introduces consistency challenges that must be designed for, not discovered during an incident.
Visual Overview
DR Strategies: Cost vs Recovery Speed
Cost (low) Cost (high)
│ │
│ ┌──────────────┐ │
│ │ Backup & │ RPO: hours │
│ │ Restore │ RTO: hours │
│ └──────┬───────┘ │
│ │ │
│ ┌──────┴───────┐ │
│ │ Pilot │ RPO: minutes │
│ │ Light │ RTO: tens of min │
│ └──────┬───────┘ │
│ │ │
│ ┌──────┴───────┐ │
│ │ Warm │ RPO: small │
│ │ Standby │ RTO: minutes │
│ └──────┬───────┘ │
│ │ │
│ ┌──────┴───────┐ │
│ │ Active- │ RPO: near zero │
│ │ Active │ RTO: near zero │
▼ └──────────────┘ ▼
Recovery (slow) Recovery (instant)
RPO vs RTO:
┌──────────────────────────────────────┐
│ Timeline: ──────X──────────Y────── │
│ │ │ │
│ │ │ │
│ Last good Disaster Recovery
│ backup happens complete
│ │ │ │
│ ←─── RPO ───→ │ │
│ (data lost) ←── RTO ──→
│ (downtime) │
└──────────────────────────────────────┘
Key Takeaway
Disaster recovery on AWS is how I restore a workload after a failure large enough to take out the primary environment, and there are four strategies that trade cost against recovery speed. I choose between them using RPO (how much data I can lose) and RTO (how long I can be down). Tighter objectives always cost more.
From cheapest to fastest: Backup and Restore keeps backups and rebuilds from scratch on disaster with hours of RTO. Pilot Light keeps the critical core running (a replicated database) and starts the app on disaster. Warm Standby runs a scaled-down fully functional copy that scales up in minutes. Multi-Site Active-Active runs full capacity in multiple Regions with near-zero RPO and RTO at the highest cost.
The senior point is that you pick per workload, not one strategy for the whole organization, and a DR plan is worthless unless you test the failover regularly. Untested recovery fails exactly when needed.
At National Bank of India the core payment ledger needed near-zero RPO and RTO, so it ran Active-Active across two Regions. The customer API used Warm Standby with a thirty-minute RTO. Internal reporting stayed on Backup and Restore. We ran quarterly game-day failover drills to prove the targets were real.
Remember one sentence: choose a DR strategy per workload based on RPO and RTO, from Backup and Restore (cheap, hours) to Active-Active (expensive, near-instant), and test the failover regularly because untested plans fail when needed.
---