Rpo Rto Confusion — AWS Advanced Networking (ANS-C01)
You confused recovery point objective (data loss tolerance) with recovery time objective (downtime tolerance). Different requirements, different architectures.
Active/passive failover is not zero data loss
Exam scenarios will state an RPO of zero minutes or near-zero alongside a multi-region requirement. Candidates select Route 53 active/passive failover with regional endpoints — a valid HA pattern — but miss that passive standby implies replication lag and potential data loss during the switchover window. RPO governs data loss tolerance; RTO governs recovery time. An architecture that meets RTO through fast DNS failover can still violate RPO if underlying replication is asynchronous.
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
Determine whether the edge failover mechanism introduces a caching layer whose TTL creates a post-failover stale-data window, causing the architecture to satisfy RTO while violating RPO=0, and select the mechanism that eliminates the cache layer entirely.
Whether CloudFront origin-group failover (HTTP-error-code triggered at the edge, sub-10-second recovery) or Route 53 failover routing (TTL plus health-check-interval dependent, 30-300 second recovery) satisfies the stated RTO for cacheable HTTP content served globally.
Domain Coverage
Difficulty Breakdown
Related Patterns