RTO and RPO name the two costs of an outage

Recovery time objective is the longest acceptable gap between service stopping and service returning. Recovery point objective is how much recently accepted data may be lost, usually stated as a span of time or a number of transactions. Every failover plan implies a pair of these, whether or not anyone wrote them down.

The two are set separately but usually pull against each other. A system allowed to lose everything can often come back almost at once, while one that must keep every byte may take far longer. Promoting an asynchronously replicated copy sits near one end; waiting for the old primary to return sits near the other.

An RPO is only as firm as whatever bounds it. With continuous replication the bound is replication lag, which is why AWS suggests watching lag on each secondary against the target. With periodic backups, the backup interval sets the achievable recovery point.

An RTO has to count every step that is not a computer. A four-nines quarterly target leaves about 13 minutes of downtime, so on-call reaction alone must be measured in minutes. The human part and DNS caching are both easy to leave out of the number.