RTO, RPO, and DR Tiers

Recovery Time Objective (RTO) is the maximum acceptable time from when a disaster occurs until your system is restored to operation. If your RTO is 4 hours, your business can tolerate 4 hours of downtime. Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time — if your RPO is 1 hour, you must be able to recover to a point no more than 1 hour before the disaster. Both metrics are defined by business requirements, not technical preferences.

AWS defines four primary Disaster Recovery strategies, ordered from lowest cost / highest RTO to highest cost / lowest RTO: 1) Backup and Restore — cheapest, hours of RTO. 2) Pilot Light — minimal core always running, minutes to hours RTO. 3) Warm Standby — scaled-down but functional, minutes RTO. 4) Multi-Site Active-Active — most expensive, near-zero RTO. Your choice depends on the business cost of downtime versus the cost of the DR infrastructure.

In Backup and Restore, you regularly snapshot your data and store it in another location (e.g., S3 with cross-region replication). In a disaster, you restore from the most recent backup. This is the cheapest strategy because you do not run standby infrastructure. The trade-off is the longest RTO (hours to restore large databases from snapshots) and highest RPO (data since the last backup is lost). AWS Backup automates snapshot schedules across EC2, RDS, EFS, DynamoDB, and more.

The Pilot Light strategy keeps the core components of your system running in a DR region at minimal capacity — like a pilot light that can quickly ignite the full flame. Typically, this means continuously replicating your database to the DR region and maintaining basic network infrastructure (VPC, subnets, security groups). Application servers are NOT running but can be launched from pre-built AMIs or launch templates quickly. RTO is typically 30 minutes to several hours depending on how much manual work is needed.

The Warm Standby strategy runs a fully functional scaled-down copy of your production environment in the DR region. Unlike Pilot Light, the application tier is running (perhaps with 1-2 instances instead of 20), and the database is an Aurora Global Database secondary or RDS Read Replica. During failover, you scale up the DR environment to match production capacity. RTO is typically under 15 minutes. This is the most common DR strategy for medium to high criticality workloads.

Multi-Site Active-Active runs full production capacity in two or more regions simultaneously. All regions serve live traffic, and data is replicated in near real-time (or multi-master). There is no failover delay — when one region fails, Route 53 or Global Accelerator immediately routes all traffic to the remaining healthy regions. This provides the lowest RTO and RPO but also the highest cost, as you are paying for full production capacity in all regions at all times.

Your RPO directly dictates what replication technology you need. RPO = 0 requires synchronous replication — nothing is lost. RPO in seconds needs near-real-time async replication like Aurora Global Database (<1s lag). RPO in minutes allows asynchronous replication with small lag (DynamoDB Streams, RDS Read Replicas). RPO in hours is achievable with periodic snapshots (AWS Backup hourly schedule). Clearly establish your business RPO requirement before choosing a technology.

Serverless architectures (Lambda, DynamoDB, API Gateway) are naturally more resilient but still need DR planning. DynamoDB Global Tables provides active-active multi-region for the database tier. Lambda can be deployed to a second region from the same CI/CD pipeline. API Gateway should be provisioned in the DR region. The main risk is configuration drift between regions — use AWS CDK or Terraform to deploy identical infrastructure to both regions from the same code base.

Consider a company with annual revenue of $10M. If downtime costs $1,000/minute, an 8-hour outage (RTO=8h) costs $480,000. An active-passive warm standby with RTO=15 minutes reduces potential loss to $15,000 per incident. If the standby costs $5,000/month ($60,000/year), it only makes economic sense if you have more than one significant outage per year. This cost-justification analysis is exactly what the SAA-C03 exam asks you to perform when selecting DR strategies.

A DR plan that has never been tested is just a document. AWS strongly recommends regular DR drills: practice failover procedures, measure actual RTO and RPO, and identify gaps. Use AWS Fault Injection Simulator (FIS) to simulate regional degradation in a controlled way. Document runbooks for failover steps so that under the stress of a real incident, the on-call team follows a clear, tested procedure rather than improvising.

Many industries have regulatory requirements for DR. PCI DSS requires documented DR plans and testing. HIPAA requires data backup and disaster recovery procedures. SOC 2 evaluates availability controls including DR. Use AWS Config and AWS Audit Manager to continuously evaluate and document that your DR resources (backups, replicas, health checks) are configured correctly. This provides evidence for compliance audits without manual collection.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: RTO is the maximum acceptable downtime and RPO is the maximum acceptable data loss, the four DR tiers balance cost against recovery speed, and your RPO requirement determines which replication technology to use. Always test your DR plan to validate actual RTO and RPO. Next up we explore the Backup and Restore strategy in detail.