I have two web applications, one in Amazon's US-West-1 region and one in the US-East-1 region running on EC2. For the most part, they do the same thing, but they service different customers based on the customer's location. Each application references a separate ElastiCache cluster in the respective region.

I currently have a CNAME record in Route53 pointing a subdomain (i.e. cache.domain.com) to the US-West-1 ElastiCache cluster's endpoint so the web application running on an EC2 instance in US-West-1 can easily reference it. Now, I'd like the other web application running in US-East-1 to resolve the same domain name (cache.domain.com) to the endpoint of ElastiCache cluster in its region, US-East-1.

So far, I've tried using a Geolocation routing policy with two CNAME records for cache.domain.com, one using "Default" as the location, which redirects to the US-West-1 endpoint and the other using United States as the location and Virginia as the sublocation which redirects to the US-East-1 endpoint. For some reason, cache.domain.com is still resolving to the US-West-1 endpoint on the EC2 instance in US-East-1.

Since ElastiCache only assigns URLs with FQDNs as cluster endpoints, I can't just use the hosts file to override DNS resolution on my US-East-1 server, which would make things easier. Is there any other way to do this?

  • What about Latency-Based Routing on Route53? That should work. Is keeping the clients in the same region a requirement? What if a region experiences an outage? – Jim G. Nov 12 '14 at 23:16
  • Yes, for us it's really a requirement. We'll probably build in some mechanism for failover later, first with redundancy across availability zones within each region, and then across regions, but our software requires extremely low response times, so having to failover to another region would likely cause a partial outage for us anyway. My question though was really an internal one unrelated to external clients. I need my EC2 servers in each region to resolve one domain name to different domain names (happens to be ElastiCache endpoints) based on the EC2 server's region. – Brian Krebs Nov 12 '14 at 23:31
  • As far as latency-based routing, I skipped that in favor of geo-based originally because the latter sounded more repeatable. I can't have Route53 for some reason deciding at times that my EC2 server in US-East-1 is better off resolving to the ElastiCache endpoint in US-West-1 since there's no access allowed between them. I haven't read up yet on exactly how Route53 determines "lowest latency" so maybe that's not an issue. I'm going to give it a shot now. I'll report back. – Brian Krebs Nov 12 '14 at 23:41
  • For your internal stuff, just use static names that will always refer to the correct region and availability zone. Then your instances in, e.g. us-east-1 can always reach the right endpoint. – Michael Hampton Nov 13 '14 at 4:14
  • The problem is, I was trying to keep my application code as clean as possible, so the ElastiCache cluster endpoint could always be referred to as cache.domain.com and some other mechanism would be able to resolve it to the correct real endpoint for that region. For now, I've basically impplemeneted your suggestion by muddying up my application code in order to statically define FQDNs for the ElastiCache endpoint configured with a property on each application node. I'd still love to find a cleaner way, but maybe DNS isn't the answer. Thanks for your suggestion! – Brian Krebs Nov 13 '14 at 23:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.