Learn Cloud Computing - Disaster Recovery (DR) & Business Continuity

#Introduction

In episode 18 we built connectivity bridges between the on-premise data center and the cloud, from IPsec Site-to-Site VPN to dedicated private connections. But connectivity is only part of the story. There's a question every organization running production systems must answer: what happens when something much bigger breaks?

Not just a single server dying — but an earthquake, a data center fire, a human error deleting the production database, or a ransomware attack encrypting the entire system. Incidents this big happen more often than you think, and this is where Disaster Recovery (DR) and Business Continuity (BC) determine whether a company survives or collapses.

Business Continuity is an organization's ability to keep operating during a major disruption. Disaster Recovery is the technical part of that: how to recover systems, data, and infrastructure from a disaster. In the cloud, DR is far more affordable than on-premise, because providers offer regions, object storage, and management services you can use as recovery targets. In this episode we'll discuss the two metrics underlying every DR decision — RPO and RTO — then four recovery strategies from the cheapest to the most resilient.

#RPO and RTO: Two Numbers That Decide Everything

All DR decisions are rooted in two numbers that must be set first. Both are determined by the business, not by engineers.

#RPO (Recovery Point Objective)

RPO is the maximum acceptable data loss when a disaster occurs, measured in time. If your RPO is 1 hour, that means you're willing to lose at most 1 hour of the most recent data. The smaller the RPO, the more often backups or replication must run.

The clearest analogy: you're writing a long document and press Ctrl+S every 30 minutes. If the laptop dies suddenly, you only lose at most 30 minutes of work — your RPO is 30 minutes. The recovery point is the state of the data at the last save; the more often you save, the less data loss you must accept.

RPO = the time gap between the last saved data and the moment of disaster
Small RPO = frequent backups/replication
Large RPO = infrequent backups/replication, higher risk of data loss

#RTO (Recovery Time Objective)

RTO is the maximum acceptable downtime duration, measured from the disaster until the system is back to normal operation. If your RTO is 4 hours, the system must be serving users again within 4 hours.

An analogy for RTO: a store loses power during business hours. While the lights are off, there are no transactions and no income. The store owner must decide how long they can afford to lose revenue before the loss becomes unbearable — that's the RTO. The length of the RTO is determined by how fast the recovery process runs: starting servers, restoring data, and verifying everything.

The two numbers are related, and there's an unavoidable pattern: the smaller the RPO and RTO, the higher the cost. Whatever DR strategy you choose is simply a way to hit the RPO/RTO targets at a cost the organization can accept.

#Four Disaster Recovery Strategies in the Cloud

#1. Backup & Restore

The simplest and cheapest strategy. All data is backed up periodically to object storage or snapshots, and when a disaster occurs everything is restored from scratch. No DR resources run on the recovery side — costs only appear when backups run and when a disaster actually happens.

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier app-prod-restored \
  --db-snapshot-identifier rds:app-prod-2026-08-03-01-00

Its RPO equals the backup interval — could be 24 hours or more if only daily backups. Notice --db-snapshot-identifier in the command above: it determines the recovery point, and the further that snapshot is from the moment of disaster, the more data is lost. Its RTO is the longest of all strategies: restoring the snapshot, reprovisioning infrastructure, reconfiguring applications, and verifying data. Suitable for non-critical data, or workloads with RPO/RTO targets in the hours-to-days range.

#2. Pilot Light

The concept is like the pilot light on a gas stove, or the aircraft engine that stays on while parked on the apron: only the core components stay alive; the rest is fully started when needed. In the cloud, that core is usually the database continuously replicating data to the recovery region, while the application servers and load balancer don't run at all.

aws rds promote-read-replica \
  --db-instance-identifier app-prod-replica

When a disaster occurs, you just start the application servers, point them at the promoted database via aws rds promote-read-replica, and redirect DNS to the new infrastructure. Because the database is always in sync, RPO approaches zero, and RTO is shorter than backup-and-restore because there's no data restore process — only compute provisioning. Costs are low because the only thing running continuously is a small-capacity database.

#3. Warm Standby

The "half-on" version of the production environment: a minimal environment running continuously — application servers active at small capacity, the database replicating data, and automation ready to scale up when needed.

Resources:
  StandbyASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: 2
      MaxSize: 20
      DesiredCapacity: 2
      LaunchConfigurationName: app-standby-launch-config

In the configuration above, MinSize: 2 ensures at least two instances are always alive even in normal conditions. Because the system is already running, failover just means redirecting traffic and raising capacity. RPO is usually in seconds to minutes, RTO in minutes. The cost is higher than pilot light because there are always-on resources, but still far below the cost of running a full double production.

#4. Multi-Region Active-Active

The most expensive and most resilient strategy: two or more regions equally active serving traffic from the start. DNS with latency-based routing and health checks (for example Route 53 on AWS or global load balancing) distributes requests across all regions; when one region dies, traffic automatically moves to the remaining ones.

Region A ──┐                     ┌── Region B
  ALB ─────┼── Global DNS ───────┼── ALB
  App ─────┘   (health check)    └── App
  DB (multi-region replication)

Because both regions are always active and data is continuously replicated, RPO and RTO approach zero — users barely notice any disruption. But the consequences are the heaviest: each region runs full production, data must be replicated across regions while handling consistency and write-conflict issues, and cross-region data transfer costs also balloon.

#Comparing the Four Strategies

Notice the consistent pattern: the smaller the RPO and RTO, the higher the cost and the more complex the operations. There's no "most correct" strategy — the most correct one is the one able to meet the business targets at an acceptable cost.

#Choosing a Strategy: How It Works

1. Set targets from the business, not from technology. Ask: how much data can be lost (RPO) and how long can the system be down (RTO) for the business to survive? These numbers must be approved by business owners, not decided by engineers alone.
2. Choose the cheapest strategy that can meet the targets. Start from the cheapest, then level up only if that strategy fails to hit the target.
3. Automate recovery. DR that depends on manual runbooks executed by panicking humans is DR that's prone to failure. Codify recovery procedures with Infrastructure as Code (back to episode 16).
4. Test periodically. Schedule a game day at least once a year, measure the actual RPO/RTO, and fix anything that overshoots the target.

#Conclusion

In this episode 19 you understood the two metrics that determine every disaster recovery decision: RPO — the data loss limit — and RTO — the downtime duration limit — plus the four strategies that meet them: backup and restore, cheap but slow; pilot light, which only keeps the core database alive; warm standby, which keeps a minimal environment running; and multi-region active-active, with near-zero RPO/RTO at the highest cost.

The key points to take with you:

• RPO and RTO are business decisions set before choosing technology.
• RPO determines backup frequency; RTO determines recovery speed.
• The four DR strategies form a cost-vs-speed spectrum: Backup & Restore, Pilot Light, Warm Standby, Active-Active.
• Always test the cheapest strategy first; level up only if targets aren't met.
• A DR that's never tested is just a document; failure drills are part of the strategy itself.

You now have the entire cloud architecture puzzle: foundations, networking, compute, storage, databases, security, observability, connectivity, and disaster recovery. In episode 20, the final episode of this series, we'll assemble everything into a complete production-grade architecture case study, review a production readiness checklist, and close the journey with cloud certification path guidance. See you in the final episode!