I'm in the process of building a RESTful web service that will run on AWS using Load Balancers, Auto-Scaling etc...
However as part of the service I need to ensure that client request latency is as low as possible. So I want potential users in the US to access US based EC2 instances and users in Europe to access European based servers.
Whats the best practice to achieve this? Assuming that clients just access some API endpoint (with curl for example), how do I direct traffic?
Is this a DNS setting which my domain name provider?
Or do I have an initial Load Balancer which can redirect to the appropriate regional load balancer? (sorts of defeats the purpose?!)
Or would I need to implement some type of client side logic?
Thanks!
An initial load balancer that does redirects would be extra slow -- essentially every request would have to be repeated and two different SSL connections would be involved... and client-side logic would be a maintenance headache and doesn't provide a straightforward failover mechanism.
Latency-Based Routing
If your application is hosted on Amazon EC2 instances in multiple Amazon EC2 regions, you can reduce latency for your users by serving their requests from the Amazon EC2 region for which network latency is lowest. Amazon Route 53 latency-based routing lets you use DNS to route user requests to the Amazon EC2 region that will give your users the fastest response.
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-latency
Additionally, you can integrate HTTP health checks into the mix, so that if -- for example -- the UK servers were failing their health checks, Route 53 would take them out of the mix and return responses to those clients that would send them to a different region until the nearer region came back online.
Optionally, using CloudFront (with caching disabled, if appropriate) on the front-end and latency-based routing to your server clusters on the back-end would serve to remove some of the pitfalls of strictly DNS-based load balancing, which is that some http libraries inappropriately cache DNS responses for far too long -- sometimes resolving addresses at first request and holding onto that initial value indefinitely (until restarted). This is broken behavior, but good luck explaining to a user of your service that the problem is with them, not you. CloudFront cleans this up for you to a significant extent, because clients would route to the nearest CloudFront edge, which would then forward the request over the AWS network to your nearest (to that CloudFront edge) cluster based on the current DNS responses Route 53 was providing.