I'm trying to design a multi-region architecture using Route 53, CloudFront, and S3 or API Gateway for better disaster recovery. Our current setup primarily runs in eu-west-1, but we're looking to add eu-central-1. We intend to use Route 53's weighted routing policies, incorporating health checks for both regions. Initially, we thought about setting up two CloudFront instances—one for eu-west-1 and another for eu-central-1. The idea is that users hitting myapp.com would be routed through Route 53 to the correct CloudFront instance based on health checks and weights. Additionally, we want to access each instance separately via their respective subdomains like eu-west-1.myapp.com and eu-central-1.myapp.com.
We've created a combination of Route 53 records to achieve this arrangement:
1. Weighted alias for myapp.com directing to eu-west-1.myapp.com
2. Weighted alias for myapp.com directing to eu-central-1.myapp.com
3. Simple alias for eu-west-1.myapp.com pointing to a specific CloudFront distribution
4. Simple alias for eu-central-1.myapp.com pointing to another distribution
However, we are facing issues with SSL connections, as we encounter a 'Handshake failed' error. We're not sure if this setup is actually feasible or if there's an underlying configuration issue with CloudFront or our SSL certificates. While a single CloudFront instance with failover origins is an option, I'm leaning towards an active-active model that leverages Route 53's routing and health checks. I would love to hear how others are managing setups like this!
1 Answer
Honestly, I wouldn't go down the path of setting up two separate CloudFront instances. CloudFront is designed to be global and distributed, so managing origins rather than separate distributions will make your life easier. Have you thought about using origin failover instead? This would allow you to keep the traffic flowing even if one region goes down. Just route myapp.com to the primary CloudFront instance and let it manage the origins for you with a simple health check setup.
Thanks for the insight! I had not thought of relying solely on the origin failover approach. It sounds like a more efficient way to handle potential downtime.