~13 min
Two numbers frame every disaster recovery decision. Recovery Time Objective (RTO) is how long the business can tolerate being down before service is restored. Recovery Point Objective (RPO) is how much data, measured in time, the business can tolerate losing — the gap since the last point you can recover to. A finance system might need an RTO of hours but an RPO of minutes; a marketing blog might tolerate both being measured in hours.
AWS describes four DR strategies that trade cost and complexity for recovery speed, roughly in this order: backup and restore (cheapest, slowest to recover), pilot light (a small, always-on core with the rest of the stack built up on failover), warm standby (a full-featured but scaled-down duplicate, scaled up on failover), and multi-site active/active (two or more Regions actively serving traffic all the time, most expensive, fastest to recover). None of these is universally "right" — each workload's RTO and RPO, weighed against what that speed costs to maintain, determines which strategy fits.
bash
aws backup start-copy-job \
--recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:abc-123 \
--source-backup-vault-name production-vault \
--destination-backup-vault-arn arn:aws:backup:us-west-2:123456789012:backup-vault:dr-vault \
--iam-role-arn arn:aws:iam::123456789012:role/AWSBackupCrossRegionRoleBackup and restore is the simplest strategy: take regular backups (AWS Backup can automate and centralize this) and copy them to a second Region, restoring from them only when disaster strikes. It's the cheapest option specifically because almost nothing runs in the second Region until you need it — which is also why it's the slowest to recover.
Pilot light keeps the smallest core of the workload always on in the second Region: typically the database, kept continuously up to date through replication, while application and web tiers stay switched off until failover, when you deploy or scale them up around that already-live data. Because the data layer is already warm, pilot light recovers faster than backup and restore without the cost of running the full application stack continuously.
Warm standby goes further: a scaled-down but fully functional copy of the entire stack runs continuously in the second Region, ready to be scaled up to full production capacity the moment it's needed. It costs more than pilot light because more of the stack is always running, but it recovers faster because there's less to stand up from scratch during a disaster.
Multi-site active/active goes all the way: two or more Regions run full production capacity and actively serve real traffic all the time, not just standing by. Recovery from a Regional failure can be close to instant, because the other Region or Regions were already handling requests. The cost is real complexity: you have to keep data consistent across Regions and decide how to handle writes that land in two Regions for the same record at nearly the same time.
Whichever strategy you pick, the failover mechanism itself matters. AWS divides its services into a data plane (day-to-day operations like serving a request or reading an object) and a control plane (operations that configure the environment, like creating a resource). Data plane operations are built for higher availability. Building your failover on data plane operations, rather than on a control plane call that might itself be degraded during the very disruption you're recovering from, keeps the failover mechanism from becoming one more thing that can fail.
A data plane operation instead of a control plane one — data plane operations are built for higher availability and are less likely to be degraded during the disruption you're failing over from.