Yes, it is location aware even if it is using DNS. The DNS lookup is the first chance you have to direct a user to the right data center. You examine the sour

Yes, it is location aware even if it is using DNS. The DNS lookup is the first chance you have to direct a user to the right data center. You examine the source of the dns lookup and figure out the best bgp path from each data center that will get you back to the source. You then respond with an answer to the dns request that directs the user to what you think is the closest data center. You may be wrong if the user is using a useless dns cache like google dns or if they are using a big ISP that keeps its dns in one location (10 or so years ago Comcast did all dns out of its east-coast data center, people learned real fast to not try to do geodns on queries coming from these servers...) OTOH, if the user is using their ISP's "local" dns server then you are going to get a result that will be very, very close to optimal. If you guessed incorrectly then the tcp handshake will start from the user to your server and you will know that they are not at the right server. If the nature of the eventual exchange allows it (e.g. it will be repeated queries or a long data exchange) then you just hit them with a redirect and let the user re-open the connection to a server that is closer to them, or you seed the response data so that follow-up queries are all exchanged with the closest data center. If the exchange is quick and not going to be repeated a lot then you will end up adding more perceived latency by trying to re-direct once the connection is established. Putting this sort of smarts down at the application server is expensive. It is much easier to do this job at the dns lookup phase and you will get a good return on the amount of investment that this approach requires. You do need to be smart though, and make sure that you do not let geodns end up directing large batches of users that are getting service from google dns or opendns to overload a particular location. Anycast is not the solution, it is just a different approach that brings its own set of headaches into the equation (e.g. pop switches during extended exchanges)