What's the actual difference between RPO and RTO, and how does each change depending on whether you're designing for multi-AZ or multi-region failover?

RPO (Recovery Point Objective) answers "how much data can we afford to lose" — measured as a time window, e.g. an RPO of 5 minutes means you can tolerate losing up to 5 minutes of writes. RTO (Recovery Time Objective) answers "how long can we be down" — measured as a duration, e.g. an RTO of 30 minutes means the system must be back up within 30 minutes of a failure. Multi-AZ failover, with its low-latency synchronous replication, can typically achieve near-zero RPO and an RTO of seconds to a couple minutes; multi-region failover, constrained by higher cross-region latency, usually means a non-zero RPO (some async replication lag) and a longer RTO (minutes, sometimes tens of minutes) unless significant additional investment goes into active-active architecture.

The two metrics measure different axes of a disaster-recovery plan and are set independently based on business tolerance, not derived from each other. RPO is about data loss tolerance: if a database fails at 10:00 and the last consistent backup or replica snapshot was taken at 09:55, the RPO realized was 5 minutes — everything written in that window is gone. RTO is about downtime tolerance: if that same failure happens at 10:00 and service is restored at 10:20, the RTO realized was 20 minutes, regardless of how much data was or wasn't lost. A system can have a great RTO and a bad RPO (fails over instantly but to a stale replica) or the reverse (recovers all data perfectly but takes hours to bring back up) — they're genuinely independent trade-offs, each with its own cost to improve.

Multi-AZ architectures achieve strong numbers on both axes cheaply because AZs are connected by low-latency private links (sub-millisecond to a few milliseconds), which makes synchronous replication practical without meaningfully hurting write latency — many managed database services offer synchronous multi-AZ replication essentially "for free" as a configuration option, giving near-zero RPO, and automated failover mechanisms can typically restore service within seconds to low minutes for RTO.

Multi-region architectures face a harder physics problem: cross-region latency (tens to hundreds of milliseconds) makes synchronous replication impractical for most write-heavy workloads, so most multi-region setups use asynchronous replication — meaning there's an inherent replication lag, and any data written but not yet replicated at the moment of failure is lost, giving a non-zero RPO proportional to that lag (often seconds to low minutes, depending on the specific technology and load). RTO for multi-region failover also tends to be longer unless the architecture is genuinely active-active, because promoting a region from passive-standby to active typically involves DNS/traffic-routing changes, connection draining, and validation steps that take real time — active-passive multi-region setups commonly see RTOs in the range of many minutes to low tens of minutes, while active-active setups can approach multi-AZ-like RTOs at the cost of significantly more architectural complexity (bidirectional replication, conflict resolution, or careful data partitioning to avoid conflicts in the first place).

• RPO measures acceptable data loss (a time window of writes that could be lost); RTO measures acceptable downtime (how long recovery can take) — they're independent axes, not two names for the same thing.
• Multi-AZ's low-latency links make near-zero RPO and low RTO achievable cheaply via synchronous replication.
• Multi-region's higher latency usually forces asynchronous replication, giving a non-zero RPO proportional to replication lag.
• Multi-region RTO depends heavily on active-passive versus active-active design — active-active can approach multi-AZ-like recovery speed at significantly higher architectural cost.

• AWS Well-Architected Framework: Reliability Pillar — Disaster Recovery
• AWS: Disaster Recovery of Workloads on AWS — RPO and RTO