We need to use one of our own dedicated servers in conjunction with the Route 53 service alongside our AWS instances.
Is latency based DNS supported for non AWS IP Addresses?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
Interesting question - it doesn't appear to be explicitly documented whether Amazon Route 53 supports IP addresses outside of the published Amazon EC2 Public IP Ranges, but I think it does to some extend, here's what I've figured/tested:
The introductory blog post Multi-Region Latency Based Routing now Available for AWS mentions that If you enter an EC2 instance public IP, Elastic IP, or Elastic Load Balancer target in the Route 53 console it will suggest the correct region for you - This is indeed the case, while entering a non EC2 IP address leaves this selection up to you, see Tests below. The post also states the following:
Behind the scenes, we are constantly gathering anonymous internet latency measurements [...]. These measurements help us build large tables of comparative network latency from each AWS region to almost every internet network out there. They also allow us to determine which DNS resolvers those end-users generally use.
Furthermore, the post mentions that Latency Based Routing is available for the "A", "AAAA", "CNAME", "TXT" DNS record types as well [...].
With the above background information I've created a latency based resource record set with EC2 instances us-east-1, us-west-2, ap-southeast-1, ap-southeast-2 and added a non AWS router/gateway of ours in Europe, specifying eu-west-1 as region accordingly.
I've used a low TTL and included/excluded and cross tested the respective DNS responses from these four instances and Route 53 delivered the desired result indeed, i.e. responding with the non AWS IP address in eu-west-1 where appropriate and depending on which regions have been included in the set.
Latency based routing to non AWS IP addresses seems to work to the extend that you need to subsume your own addresses to one of the available AWS regions - this does make sense, insofar AWS needs to employ latency measurements for non AWS routes anyway to achieve the desired shortest path analysis from an end user perspective and these systems are mostly running outside of AWS.