A regional grocery chain runs online ordering on EC2 and RDS MySQL in eu-west-1. The board requires RTO under 20 minutes, RPO under 1 minute, and rejects the cost of full active-active. Pilot-light restore tested at 55 minutes. Which disaster recovery strategy meets the stated RTO, RPO, and cost requirements?

The warm standby design fits all three constraints because continuous cross-region RDS replication keeps lag in seconds to satisfy sub-minute RPO, while a live replica, scaled-down Auto Scaling group and preconfigured Route 53 health-check failover allow rapid scale-out and traffic shift to satisfy sub-20-minute RTO without paying for full duplicate capacity. The pilot-light approach also uses replication for low data loss and remains inexpensive, but it fails on recovery time conceptually because EC2 hosts, application stacks and scaling must be provisioned from AMIs and automation after declaration, which typically pushes restoration beyond a tight RTO even when data is current. The backup-and-restore approach is cheapest and operationally sound with snapshots, versioned storage and infrastructure as code, but it fails on recovery point conceptually because recovery depends on periodic snapshot points and rebuild steps, so the inevitable data-loss window and restore duration cannot guarantee seconds-level currency. The fully provisioned mirrored fleet with global database and distributed routing is technically excellent for RTO and RPO and is common for zero-downtime retail, but it fails on the business constraint because running duplicate compute at scale doubles cost and was explicitly rejected. Exam caveat is to separate replication from readiness: replication solves RPO while running and pre-warmed capacity solves RTO, so pilot light versus warm standby hinges on what is already running. Practical check is to run a game-day failover, monitor replica lag under peak write load, verify Auto Scaling launch times and Route 53 TTLs, and document measured RTO and RPO evidence against board targets.