Rpo Rto Confusion — AWS SysOps Administrator (SOA-C03)
You confused recovery point objective (data loss tolerance) with recovery time objective (downtime tolerance). Different requirements, different architectures.
RTO and RPO Are Not the Same Number
Exam questions state both a recovery time objective and a recovery point objective. Candidates who read quickly often match their answer to just one. A warm standby satisfies a tight RTO — instances are pre-warmed and can accept traffic quickly. But if the RPO is measured in seconds, replication lag determines whether the answer passes or fails, independent of startup time. Read both constraints explicitly before evaluating any DR strategy.
The Scenario
A financial application requires RPO of 1 hour and RTO of 15 minutes. You design a Pilot Light strategy with Aurora read replicas in the DR region using asynchronous replication. Pilot Light infrastructure can spin up in 15 minutes (meets RTO). But asynchronous replication to a read replica can lag by several hours during peak loads — if the primary fails during a replication lag spike, you lose more than 1 hour of transactions (violates RPO). The correct answer is Warm Standby with Aurora Global Database, which replicates with typical lag under 1 second and provides a pre-scaled environment for fast failover. You satisfied RTO but forgot to verify RPO independently.
How to Spot It
- •RPO drives your replication strategy: RPO of 0 requires synchronous replication (Multi-AZ RDS, Aurora Multi-AZ). RPO of 1 hour can use asynchronous replication if the lag is bounded under 1 hour (Aurora Global Database typical lag < 1 second). RPO of 24 hours can use daily snapshots.
- •RTO drives your failover infrastructure: RTO of minutes requires Warm Standby or Multi-Site Active-Active with pre-provisioned compute. RTO of hours allows Pilot Light (minimal infrastructure, scaled up on failover). RTO of days allows Backup and Restore from S3/snapshots.
- •When a question gives both RPO and RTO, evaluate each independently against every answer option. An answer that meets RTO but fails RPO is wrong. The exam specifically designs options that satisfy one but not the other.
Decision Rules
Whether Multi-AZ high availability satisfies a 15-minute RPO for logical data corruption versus enabling automated backups to unlock continuous transaction-log-based PITR, which is the only mechanism that constrains data-loss window for application-layer errors.
Whether to enable RDS Multi-AZ (synchronous standby, automatic promotion, near-zero RPO) or promote an RDS Read Replica (asynchronous replication, manual promotion step required) as the database HA mechanism when the constraint demands both automatic failover and near-zero data loss.
Whether to convert the RDS instance to Multi-AZ (synchronous replication, automatic promotion, RTO within minutes) versus adding an RDS Read Replica (asynchronous, manual promotion required), given that the automatic-failover and sub-five-minute RTO constraints together disqualify the Read Replica path.
Whether to convert the RDS instance to Multi-AZ deployment (synchronous standby, automatic promotion, near-zero RPO) versus adding an RDS Read Replica (asynchronous, manual promotion required), given an explicit RPO-of-zero and sub-2-minute RTO constraint.
Whether transitioning EBS snapshots to cold storage satisfies a 30-minute RTO, or whether multi-hour archive retrieval latency forces standard-tier retention with cost controlled through deletion lifecycle policies rather than storage-tier degradation.
Domain Coverage
Difficulty Breakdown
Related Patterns