RPO is tolerated data loss measured in time. RTO is tolerated recovery time. They are business requirements, not service features.
| Strategy | Running footprint | Relative RTO/RPO | Cost |
|---|---|---|---|
| Backup and restore | Backups only | Highest | Lowest |
| Pilot light | Critical core running | Lower | Low-medium |
| Warm standby | Scaled-down full stack | Lower still | Medium-high |
| Multi-site active/active | Full production in multiple sites | Lowest | Highest |
High availability typically survives component or AZ failure inside a Region. Disaster recovery addresses larger failures and operational recovery. A Multi-AZ database is not automatically a cross-Region DR plan.
Match migration tool to what moves
- DMS migrates databases and can keep replicating changes; SCT converts heterogeneous schemas.
- Application Migration Service moves servers into AWS.
- Elastic Disaster Recovery maintains recovery capability for servers.
- DataSync transfers online files/object data.
- Snow Family handles large offline transfer or constrained networks.
- Application Discovery Service inventories dependencies; Migration Hub tracks migration progress.
Backups need tested restores, retention, encryption, and isolation. AWS Backup centralizes policy; Vault Lock helps enforce retention. Replication can also replicate corruption, so immutable recovery points still matter.
Exam lens: if two options meet RTO/RPO, choose the less expensive and operationally simpler one. Do not buy active/active when warm standby satisfies the business target.
Review card
- RPO is data loss; RTO is downtime.
- Multi-AZ HA and Multi-Region DR are different scopes.
- Replication is not a substitute for immutable backup.
- DMS moves databases; MGN moves servers; DRS prepares server recovery.
- A DR design is incomplete until failover and restore are tested.