RPO, RTO and the Four DR Strategies

By the end of this lesson you will be able to

• Say what a disaster is (an AZ or Region outage, human error, ransomware, a bad deploy) and tell the three kinds of disaster recovery apart: on-premises to on-premises, on-premises to AWS, and one AWS Region to another.
• Define RPO (how much data may be lost, looking back from the disaster) and RTO (how long the system may be down, looking forward), work out both from a timeline, and explain why an RPO is only true if the backup is good.
• Describe the four AWS strategies (backup and restore, pilot light, warm standby, multi-site active/active) with their typical RPO and RTO, what runs in the DR Region, and what each costs.
• Tell pilot light from warm standby, and hot standby from active/active, and correct the common myth of a “zero” RPO and RTO.
• Build a DR design from AWS parts: cross-Region backups and replication, Route 53 failover, Application Recovery Controller, infrastructure as code, AMIs and quotas kept ready, and regular drills.
• Read an exam scenario’s words (data loss, downtime, cost, mission-critical) and pick the cheapest strategy that meets them.

#Why disaster recovery

Chapter 23 is about two jobs that look different but share one question: what happens to the business when its systems have to move? In a disaster they move because they must; in a migration because you chose to. This lesson is the planning half of disaster recovery: the two numbers that define it and the four standard ways to meet them. Lesson 23.2 adds the services that do the copying (Elastic Disaster Recovery and AWS Backup), and lessons 23.3 to 23.5 cover migrations.

#What counts as a disaster

A disaster is any event that harms a company’s ability to keep working or its finances. In the cloud the usual ones are:

• An Availability Zone fails: power, cooling or network trouble in one data center group. A well-built Multi-AZ system rides through this without a DR plan.
• A whole Region is impaired: rare, but it happens, and every service in that Region may be affected at once.
• Human error: an engineer deletes a table, runs a script against production, or deletes a bucket.
• A bad deploy: a new release corrupts data or crashes under load.
• An attack: ransomware encrypts or deletes data; stolen credentials are used to destroy resources.
• Physical events on premises: a flood in a server room, a fire, a long power cut.

Disaster recovery (DR) is preparing for such events and recovering from them: deciding in advance how much loss is acceptable, keeping the right copies in the right place, and practising the way back.

#Three kinds of disaster recovery

#High availability is not disaster recovery

High availability and DR are related but answer different questions:

• High availability (HA) keeps a system running through small, common failures: an instance dies, an AZ goes down. Multi-AZ RDS, an Auto Scaling group across AZs and a load balancer give HA inside one Region (lesson 7.1 is careful about this difference).
• DR handles the big, rare events: a Region impaired, data destroyed or corrupted. Multi-AZ does nothing against a dropped table: the standby copies the drop within milliseconds.

The AWS DR whitepaper says it plainly: for a well-built, highly available workload, losing one data center may need only backup and restore; if your definition of disaster includes losing a Region, or regulators require it, look at pilot light, warm standby or multi-site.

#RPO and RTO

Every DR plan starts with two numbers per system. The exam asks about them constantly, and mixing them up is the commonest mistake.

#RPO: how much data you can lose

Recovery Point Objective (RPO) is the maximum amount of data, measured in time, that the business accepts to lose. It looks backward from the disaster: “we can lose at most the last hour of orders.” It is set by how often you take backups or how closely you replicate.

#RTO: how long you can be down

Recovery Time Objective (RTO) is the maximum time the business accepts between the disaster and the service working again. It looks forward from the disaster: “customers must be able to order again within 4 hours.” It is set by how much of the system is already running, and how automated the recovery is.

  last good backup            disaster              service back
        |<------- RPO -------->|<-------- RTO -------->|
           data written here     the system is down
           is lost               (detect, decide, recover)

#A worked example

A shop takes a database backup every hour, on the hour, so its RPO is 1 hour. The disaster strikes at 10:50.

Two lessons hide in this table. First, the RPO is a worst case, not what usually happens. Second, the RPO is only true if the backup you fall back to is good and restorable. A backup that has never been restored is a hope, not a recovery point.

#Where the numbers come from

RPO and RTO are business decisions, not technical ones. The business says what an hour of downtime or an hour of lost data costs (lost sales, fines, reputation), and IT says what each level of protection costs. Lower numbers always cost more: a 24-hour RPO needs a nightly backup; a seconds RPO needs continuous replication to a live database elsewhere; a near-zero RTO needs a second copy already running at full size.

Keep the two numbers apart in your head:

• RPO is about data. It depends on how data is protected: periodic backups (hours), frequent or continuous backups (minutes), continuous replication (seconds), synchronous replication (zero).
• RTO is about everything else. It depends on how much of the system already exists in the recovery site, how long it takes to start and scale, how fast traffic moves (DNS TTL), and whether the steps are automated.

A design can have a tiny RPO and a long RTO (data replicated every second, but no servers in the DR Region), or the other way round.

#The four strategies at a glance

AWS groups DR into four strategies, ordered by cost and by how fast they recover. The ranges are the ones in the AWS whitepaper Disaster Recovery of Workloads on AWS.

The first three are active/passive: users go to the primary site until a failover. The fourth is active/active. The slides draw the same order as an arrow towards faster RTO; read it the other way and it is an arrow towards higher cost.

#Backup and restore

The simplest and cheapest strategy. You back up data regularly and keep the copies somewhere the disaster cannot reach. When disaster strikes, you build the environment again and restore the data into it.

What to back up and where it goes:

• AWS data: EBS snapshots (lesson 5.1), RDS automated backups and snapshots (lesson 7.2), Aurora, DynamoDB, EFS, FSx and Redshift snapshots, and S3 data with versioning and replication. AWS Backup schedules and copies most of these from one place (lesson 23.2).
• On-premises data into AWS: through Storage Gateway (lesson 12.3) or, for big initial copies, Snowball (lesson 12.1), into S3, with a lifecycle rule that moves older copies to S3 Glacier storage classes to cut cost (lesson 10.5).
• The servers themselves: AMIs of your instances (lesson 4.3), copied to the DR Region.
• The infrastructure: templates for networks, security groups, load balancers and Auto Scaling groups, so the whole environment can be recreated.

Three rules the notes leave out, and the whitepaper insists on:

1. Copy backups to another Region (and ideally another account). A snapshot in the failed Region is unreachable exactly when you need it. Use copy-snapshot, copy-image, RDS cross-Region automated backups, S3 Cross-Region Replication, or AWS Backup copy rules.
2. Rebuild with infrastructure as code (IaC): AWS CloudFormation or Terraform. Rebuilding by hand under pressure is slow and full of mistakes; a template deploys the same thing every time (lesson 25.1).
3. Test restores. A backup you have never restored may be corrupt, incomplete or too slow to restore within the RTO.

#Pilot light

Think of a gas water heater or an old gas stove: a tiny pilot flame burns all the time, and when you turn on the gas, the full burner lights from it at once. In the pilot light strategy the most critical core of the system, usually the database and other data stores, is always running and kept in sync in the DR Region. The application servers are switched off. On a disaster, automation (CloudFormation, an Auto Scaling group) starts the servers around the live data.

• Always on in the DR Region: a cross-Region read replica (RDS), a secondary cluster (Aurora global database), a DynamoDB global table replica, S3 buckets with replication.
• Switched off: web and application servers. AWS’s best practice is that “switched off” means not even deployed: the template and AMI are ready, and deploying is part of the failover.
• On failover: promote the database replica to a writer, deploy and scale the servers, then move traffic with Route 53.
• Result: RPO in seconds to minutes (replication), RTO in tens of minutes (servers must be created, booted and warmed up).

The slides add two points: pilot light is very similar to backup and restore (most of the environment still has to be created), but faster, because the critical systems are already up. The slides draw it as hybrid DR: the corporate data center replicates its database to an RDS instance in AWS (running), while EC2 instances are “not running”, and Route 53 points users to AWS on failover.

Three things that make pilot light fail on the day:

• Quotas: the DR Region’s account has default service quotas (On-Demand vCPUs, load balancers, IP addresses). Raise them to production size before the disaster; for capacity you cannot afford to miss, use On-Demand Capacity Reservations.
• Stale images and templates: every release must reach the DR Region too (AMIs, container images, templates, configuration, secrets). An EC2 Image Builder pipeline can copy each golden AMI to both Regions.
• Data is not enough: the replica protects against losing a Region, not against a bad script. Keep point-in-time backups in the DR Region too.

AWS Elastic Disaster Recovery is pilot light as a service for servers: it keeps continuously replicated disks and small, cheap replication servers in a staging area and launches full-size servers only at recovery. It is the subject of lesson 23.2.

#Warm standby

In warm standby a scaled-down but fully functional copy of the whole production environment always runs in the DR Region: load balancer, a few small application servers and a database replica. It can serve real traffic immediately, just not all of it. On a disaster you scale it up to production size (Auto Scaling raises the desired capacity) and move all traffic there.

• Difference from pilot light: pilot light cannot process a request until servers are deployed and started; warm standby can, at reduced capacity, right now. Pilot light must turn on and scale; warm standby only scales.
• Result: RPO in seconds (replication), RTO in minutes.
• Bonus: because the copy is always running, you can send it a small share of real or test traffic every day and know it works.

The slides draw warm standby with an ELB, an EC2 Auto Scaling group at minimum size and a running RDS secondary in AWS, replicating from a corporate data center; on failover Route 53 moves users and the Auto Scaling group grows to production size.

Two catches. First, Auto Scaling is a control plane action (an API that changes configuration), and control planes are less available than data planes during a big event. AWS’s whitepaper calls a copy that is already at full size, needing no scaling, hot standby; many teams pick a middle ground: enough capacity for the first wave of traffic, then scale for the rest. Second, never send full traffic before the capacity exists: scale first, then switch.

#Pilot light or warm standby?

#Multi-site active/active and hot standby

In multi-site active/active the full workload runs at production size in two or more Regions at the same time, and all of them serve users. Route 53 (latency, weighted or geolocation records) or Global Accelerator spreads users across Regions; if one Region fails, its health checks fail and the others take all traffic at once. There is no failover of the application tier at all, only of the data writer if there is a single one.

• Result: RPO and RTO near zero (the whitepaper writes “real time”), with the corrections above.
• Cost: the highest. You pay for full capacity everywhere, all the time, plus cross-Region data transfer.
• Data design is the hard part. Reads are served locally. Writes follow one of three patterns:
  • Write global: all writes go to one Region’s writer. Aurora global database fits: secondaries serve local reads, write forwarding sends occasional writes to the primary, and a secondary is promoted in under a minute if the primary Region fails (lesson 7.3).
  • Write local: each Region accepts writes. DynamoDB global tables fit, with last writer wins for conflicts (lesson 15.5).
  • Write partitioned: each user or account has a home Region for writes, avoiding conflicts.
• Hot standby is the active/passive cousin: a full-size copy that takes no users until failover (Route 53 failover routing). AWS notes that most teams who pay for a full second environment prefer to use it, so active/active is more common.

The slides show it twice: on-premises and AWS both active at production scale behind Route 53, and an all-AWS multi-Region design with an Aurora global database (primary and secondary) and a production-size Auto Scaling group behind an ELB in each Region.

#Choosing a strategy

The method is the same in every scenario:

1. Find the RTO: how long may it be down? Hours → backup and restore. Tens of minutes → pilot light. Minutes → warm standby. Seconds → multi-site.
2. Find the RPO: how much data may be lost? Hours → periodic backups are enough. Minutes or seconds → you need continuous replication, which means at least a live database replica: pilot light or above. Zero → synchronous replication.
3. Take the stricter of the two.
4. Among strategies that meet both, choose the cheapest. The exam nearly always adds “most cost-effective”.

Try the edge cases in the picker: a lenient RTO with a strict RPO (the RPO forces a running replica), and a strict RTO with a small budget (the plan cannot be paid for; the business must choose).

#DR building blocks on AWS

The notes give three tips (Route 53 failover, global databases, IaC); the slides add backup, high availability, replication, automation and chaos. Here they are as one toolbox, with the lesson where each is taught.

#Data: backups and replication across Regions

The notes say Aurora global database and DynamoDB global tables replicate “within a fraction of a second”. That is typical, not guaranteed: lag grows under heavy write load or network trouble, which is why Aurora PostgreSQL offers a managed RPO setting that pauses commits when no secondary is close enough.

Within one Region, the slides’ “high availability” list (RDS Multi-AZ, ElastiCache Multi-AZ, EFS and S3, which already span AZs) handles AZ failures, so the DR plan can focus on Region and data disasters. For hybrid links, a Site-to-Site VPN is the classic backup path when a Direct Connect connection fails (lessons 22.4 and 22.5).

#Traffic: moving users to the DR Region

• Route 53 failover routing with health checks is the notes’ first tip and the classic answer: the primary record is used while its health check passes; when it fails, Route 53 answers with the secondary. How checks, intervals (30 or 10 seconds), thresholds and TTL add up to the failover time is in lessons 8.3 and 8.4. Keep failover records at a short TTL (60 seconds): resolvers that cached the old answer keep sending users to the dead Region until it expires.
• Global Accelerator moves traffic between Regions behind the same static anycast IP addresses, with no DNS caching to wait for (lesson 11.4).
• Application Recovery Controller (ARC) routing controls are reliable on/off switches for a manual but scripted failover, running on a cluster in five Regions (lesson 8.4).

AWS recommends using only data plane actions during a failover (DNS answers driven by health checks, ARC routing controls), not control plane changes such as editing records or creating resources, because control planes are designed for lower availability. It also warns that automatic Region failover on a health check alarm can do harm on a false alarm, so many teams let a person start the failover, with every step after that automated.

#Infrastructure and capacity ready in the DR Region

• Infrastructure as code is the notes’ third tip: CloudFormation (its stack sets deploy one template to many accounts and Regions) or Terraform, so recovery is a deployment, not a memory test. The slides also mention Elastic Beanstalk, which can recreate a whole environment from a saved configuration.
• AMIs, container images, configuration and secrets copied to the DR Region with every release.
• Service quotas raised in the DR Region to production size; capacity reservations for instance types you cannot do without.
• Keys and permissions: KMS keys (multi-Region keys help), IAM roles and certificates the recovery needs must exist in the DR Region (lesson 21.2).

#Automation for smaller failures

The slides’ automation list also covers single-instance problems: a CloudWatch alarm on a failed system status check can recover an EC2 instance onto new hardware (most current instance types now also recover automatically by default), or reboot it; Lambda functions run custom recovery steps when EventBridge or CloudWatch report a problem.

#Testing: drills, game days and chaos

A DR plan that has never been run will fail in surprising ways: expired credentials, a missing route, a quota, a step only one person knew. Run DR drills (fail over to the DR Region and back on purpose) and game days (a planned exercise with the whole team). The slides’ example is Netflix’s “Simian Army”, whose Chaos Monkey randomly terminated production instances so that engineers had to build systems that survive it. On AWS, AWS Fault Injection Service runs controlled experiments such as stopping instances, failing over databases or disrupting an AZ.

#Newer tools (side notes)

#What goes wrong

#DR in system design

Different systems of one company can use different strategies: the wallet’s payment core is active/active while its marketing site is backup and restore. Classify each system, do not give everything the most expensive tier.

#Try it yourself

These commands use the AWS CLI v2 with Singapore (ap-southeast-1) as the primary and Mumbai (ap-south-1) as the DR Region. Copies and replicas cost money; delete them afterwards.

# 1. Backup and restore: copy an EBS snapshot and an AMI to the DR Region (run in the DR Region)
aws ec2 copy-snapshot --region ap-south-1 \
  --source-region ap-southeast-1 --source-snapshot-id snap-0abcd1234example \
  --description "DR copy of erp-data" --encrypted --kms-key-id alias/dr-ebs
# { "SnapshotId": "snap-0fedc9876example" }

aws ec2 copy-image --region ap-south-1 \
  --source-region ap-southeast-1 --source-image-id ami-0abcd1234example --name erp-web-2026-11-01
# { "ImageId": "ami-0fedc9876example" }

# 2. RDS: replicate automated backups to the DR Region (point-in-time restore there)
aws rds start-db-instance-automated-backups-replication --region ap-south-1 \
  --source-db-instance-arn arn:aws:rds:ap-southeast-1:111122223333:db:erp-db \
  --backup-retention-period 7 --kms-key-id alias/dr-rds
# { "DBInstanceAutomatedBackup": { "Status": "pending", "BackupRetentionPeriod": 7, ... } }

# 3. Pilot light: a cross-Region read replica that is always running
aws rds create-db-instance-read-replica --region ap-south-1 \
  --db-instance-identifier pharmacy-db-dr \
  --source-db-instance-identifier arn:aws:rds:ap-southeast-1:111122223333:db:pharmacy-db \
  --db-instance-class db.r6g.large --kms-key-id alias/dr-rds
# { "DBInstance": { "DBInstanceIdentifier": "pharmacy-db-dr", "DBInstanceStatus": "creating",
#   "ReadReplicaSourceDBInstanceIdentifier": "arn:aws:rds:ap-southeast-1:111122223333:db:pharmacy-db" } }

# 4. Before any disaster: check the DR Region's On-Demand vCPU quota
aws service-quotas get-service-quota --region ap-south-1 \
  --service-code ec2 --quota-code L-1216C47A --query 'Quota.Value'
# 32.0      <- production needs 192: request an increase now, not on the day

# 5. Failover day (pilot light): promote the replica, deploy the web tier, scale it
aws rds promote-read-replica --region ap-south-1 --db-instance-identifier pharmacy-db-dr
aws cloudformation deploy --region ap-south-1 --stack-name pharmacy-web-dr \
  --template-file web-tier.yaml --parameter-overrides AmiId=ami-0fedc9876example DesiredCapacity=12
# Waiting for changeset to be created..
# Successfully created/updated stack - pharmacy-web-dr

# 6. Warm standby: grow the running copy from 2 to 20
aws autoscaling update-auto-scaling-group --region ap-south-1 \
  --auto-scaling-group-name results-web-dr --min-size 20 --desired-capacity 20 --max-size 40

# 7. Watch the Route 53 health check that drives failover
aws route53 get-health-check-status --health-check-id 1a2b3c4d-1111-2222-3333-example \
  --query 'HealthCheckObservations[0:3].[Region,StatusReport.Status]' --output text
# ap-southeast-1   Failure: HTTP Status Code 503, Service Unavailable
# eu-west-1        Failure: HTTP Status Code 503, Service Unavailable
# us-east-1        Failure: HTTP Status Code 503, Service Unavailable

# 8. Or run the whole recovery as an ARC Region switch plan
aws arc-region-switch start-plan-execution \
  --plan-arn arn:aws:arc-region-switch::111122223333:plan/results-dr:abc123 \
  --target-region ap-south-1 --action activate --mode ungraceful \
  --comment "Singapore impaired, game day 2026-11-01"
# { "executionId": "ap-south-1/0123456789abcdef", "activateRegion": "ap-south-1",
#   "deactivateRegion": "ap-southeast-1", ... }

In the console, open Route 53 → Health checks and look at the status from each checker Region, and Service Quotas in the DR Region to compare every quota your production uses. Then plan a game day: fail one test application over to the DR Region and back, and write down how long each step really took. That measured number is your real RTO.

#Summary

Key takeaways

• A disaster is anything that harms business continuity or finances: AZ or Region outage, human error, bad deploy, ransomware, a flooded server room. DR can be on-prem → on-prem (costly), on-prem → AWS (hybrid), or Region → Region.
• RPO = data you may lose, measured back from the disaster (backup frequency, replication). RTO = downtime you may accept, measured forward (how much is already running, automation, TTL). Hourly backups, disaster at 10:50 → 50 minutes lost, worst case 60. An RPO is only true if the backup is good.
• Four strategies, cheapest and slowest first: backup and restore (hours; nothing running), pilot light (tens of minutes; data tier live, servers off), warm standby (minutes; everything running small), multi-site active/active (near zero; full size, all Regions serving). Hot standby = full size but passive.
• Multi-site is near-zero, never literally zero, with asynchronous replication; corruption replicates too, so even multi-site needs point-in-time backups.
• Backup and restore must copy backups to another Region and rebuild with IaC. Pilot light needs current AMIs and quotas in the DR Region. Warm standby must scale before taking full traffic.
• Toolbox: Route 53 failover + health checks (short TTL), Global Accelerator, ARC routing controls and Region switch; Aurora global database, DynamoDB global tables, RDS cross-Region replicas and backup replication, S3 CRR with RTC, EBS snapshot and AMI copies, AWS Backup; CloudFormation or Terraform; regular drills and game days; Resilience Hub to assess RTO/RPO.
• Exam method: read the RTO and RPO words, take the stricter, choose the cheapest strategy that meets it.

Self-check: RPO, RTO and DR strategies30 questions