Build Instant Failover with CloudFront Origin Groups

This is Part 2 of the 3-part Disaster Recovery series. Part 1 (Multi-Region Deployment) teaches you to deploy your app across multiple AWS regions. This project (Part 2) builds on that foundation with edge-based failover using CloudFront origin groups for instant traffic switching. Part 3 completes your DR toolkit with infrastructure-as-code using Pulumi for automated disaster recovery deployment. Together, these three projects give you a complete disaster recovery strategy for production systems.

DNS-based failover using Route 53 health checks requires DNS records to change and propagate globally, which can take minutes. CloudFront origin failover happens at the edge location level. When an edge server gets an error from the primary origin, it immediately retries with the secondary on the same request. Users experience a slightly slower response for that single request, but there is no propagation delay. This is why Twitch and DAZN use this pattern for live streaming where minutes of downtime costs millions.

Yes, this project requires two App Runner services running in different AWS regions (us-east-1 and us-west-2). The Deploy Multi-Region project teaches you how to deploy the same application to multiple regions. Complete that project first, then return here to add automatic failover between those regions.

An origin group bundles two origins together, a primary and a secondary. CloudFront always tries the primary first. If it receives one of the error codes you specified (404, 5xx), it immediately retries the same request against the secondary origin. This happens at each edge location independently, so failover is nearly instantaneous. No DNS changes or manual intervention required.

When you pause an App Runner service, it returns 404 (not a 5xx error). If you only selected 5xx errors for failover criteria, CloudFront would keep trying the paused primary and never fail over. Including 404 ensures CloudFront switches to the secondary when the primary service is unavailable for any reason. This is a subtle but critical configuration detail.

CloudFront pricing is based on data transfer and requests. For this project with minimal test traffic, costs are typically under $1. CloudFront charges approximately $0.085 per GB for data transfer to North America and $0.0075 per 10,000 HTTPS requests. During testing, you will generate minimal traffic. Remember to delete the distribution after completing the project to avoid ongoing charges.

CloudFront does not send active health probes to origins. Instead, it evaluates origin health based on responses to actual user requests. This is called passive health checking. When your primary origin starts returning errors, CloudFront marks it unhealthy and routes to the secondary. When the primary starts returning successful responses again, CloudFront automatically prefers it. This approach reduces overhead while providing effective failover.