An application uses an Amazon CloudFront distribution with a public Application Load Balancer (ALB) in a Region as the default origin. The app is deployed to a secondary Region in a warm-standby setup and the business requires zero-second RTO for HTTP GET requests. How can failover to the secondary Region be automated so HTTP GETs meet that RTO?

The correct solution leverages CloudFront's origin groups, which are designed for high availability and failover. By adding the secondary ALB as a new origin and creating an origin group with the primary ALB and a failover condition for HTTP 5xx errors, CloudFront automatically directs traffic to the secondary ALB when the primary fails. This provides a zero-second RTO for GET requests because CloudFront handles the failover internally without DNS propagation delays. Creating a second CloudFront distribution and using Route 53 failover would introduce DNS propagation delays, violating the zero-second RTO. Route 53 failover directly to ALBs, even with a 0 TTL, still incurs DNS lookup and propagation time. A CloudFront function for redirection would add latency and complexity, and might not be truly "zero-second" as it relies on the client to follow the redirect.