In the previous subchapter, we defined the RTO (how long I can be down) and the RPO (how much data I can lose). Now we’ll look at the four classic disaster recovery strategies, ranging from the cheapest and slowest to the most expensive and instantaneous. Your RTO and RPO determine which to choose. It’s a range of options where, in general, lower cost = slower recovery, and higher cost = faster recovery.

The four strategies form a spectrum. As you move along, recovery is faster (lower RTO and RPO), but it costs more to maintain:

Let’s go through them one by one.

The simplest and cheapest. You make backups of your data (and configuration) and, if a disaster occurs, rebuild everything from those backups. You don’t have anything duplicated and running: you just keep copies.

• RTO: high (hours or more: you have to rebuild everything).
• RPO: depends on how often you make backups.
• Cost: very low (you only pay for backup storage).

Analogy: it’s like having copies of your photos on a hard drive stored in a drawer. If your computer breaks, you don’t lose the photos, but you’ll have to buy a new computer and restore them, which takes time. Cheap to maintain, but recovery is not immediate.

Ideal for: systems that can tolerate being down for hours (high RTO), such as internal tools or files.

A step further. You keep a minimal version of the system always running elsewhere: the essentials (mainly the data, continuously copied), but without full capacity running. In a disaster, you “ignite” the rest from that base.

• RTO: medium (faster than backup, because the essentials are ready).
• RPO: low (data is continuously replicated).
• Cost: low-medium (you only keep the minimum running).

Analogy: it’s like the pilot light of a gas boiler: there’s always a small flame burning (the minimum), ready so that, when you need heat, the system can turn on quickly from it, without starting from scratch. You keep just enough to start up fast.

Ideal for: important systems that need to recover fairly quickly, but where paying for a full copy always running would be excessive.

You keep a complete but reduced copy of the system running elsewhere: everything is running, but at a smaller scale (less capacity). In a disaster, you just need to scale it up to full size and redirect traffic.

• RTO: low (the copy is already running, you just need to scale it up).
• RPO: very low.
• Cost: medium-high (you keep a full copy running, though small).

Analogy: it’s like having a more modest spare car always ready in the garage, engine tuned up. If your main car fails, you get in the spare instantly and keep going (maybe with fewer luxuries, but it works). You don’t have to start anything from scratch or wait.

Ideal for: critical systems that need to recover very quickly (low RTO), but where you can tolerate a few minutes of adjustment.

The most robust and expensive. You have the system running fully and at full capacity in several locations at once (for example, two regions), serving traffic simultaneously. If one fails, the other absorbs everything almost transparently, with hardly any interruption.

• RTO: almost zero (the other site is already serving).
• RPO: almost zero.
• Cost: high (you keep the full system duplicated and active).

Analogy: it’s like having two identical cars, both running, taking you along parallel routes. If one breaks down, you’re already (also) in the other: you keep going without stopping for a second. Maximum security, but you pay for two full cars running.

Ideal for: systems that cannot go down under any circumstances (payments, critical services), where the cost of downtime far exceeds the cost of duplication.

The strategy is chosen according to the RTO and RPO the business needs (subchapter 26.1) and the budget:

💡 Not everything needs the same: a company uses different strategies for different systems. Its payment platform may be multi-site, while its internal reporting system uses simple backup & restore. You apply to each system the strategy its criticality justifies.

Real-world example: an e-commerce company decides its DR by system. The sales website (critical) uses Warm Standby: a reduced copy ready in another region that they scale up in minutes if the main one fails, balancing cost and speed. The billing system uses Pilot Light: data is always replicated, but the rest is started only if needed. And the historical reports warehouse uses Backup & Restore: daily backups and nothing more. This way, they spend a lot where it’s critical and little where it’s not, optimizing cost and resilience at the same time.

• There are four classic disaster recovery strategies, on a spectrum from lower cost/slower to higher cost/faster:
• Backup & Restore: you only keep backups and rebuild in a disaster. Very cheap, high RTO (hours). Like photos on a hard drive in a drawer.
• Pilot Light: you keep the essential minimum running (data replicating) and start up the rest if it fails. Low-medium cost, medium RTO. Like the pilot light of a boiler.
• Warm Standby: you keep a complete but reduced copy running, and scale it up if it fails. Medium-high cost, low RTO. Like a spare car with the engine ready.
• Multi-site (active-active): complete and duplicated system serving in several places at once. Expensive, RTO/RPO almost zero. Like two identical cars running.
• You choose according to your RTO/RPO (26.1) and budget, and you can use different strategies for different systems depending on their criticality.

In the next subchapter, we’ll look at a key piece to make the switch to the backup system automatic: health checks and failover with Route 53.