The Amazon Web Services are now available in an ever-expanding series of locations. You've asked us to make it easier to build applications that span multiple AWS regions and we are happy to oblige.
Today I'm pleased to announce that Amazon Route 53 is making available the same latency based routing technology that powers Amazon CloudFront to users of Amazon EC2, Elastic Load Balancing, and more. With Amazon Route 53’s new Latency Based Routing (LBR) feature, you can now have instances in several AWS regions and have requests from your end-users automatically routed to the region with the lowest latency.
Configuring Latency Based Record Sets with Amazon Route 53
DNS record sets hosted on Amazon Route 53 can now be marked as latency based in both the Route 53 API, and the Route 53 tab of the AWS Management Console. 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:
Once you have configured two or more latency based record sets with matching names and types, then the Route 53 nameservers will use network latency and DNS telemetry to choose the best record set to return for any given query.
Behind the scenes, we are constantly gathering anonymous internet latency measurements and storing them in a number of Relational Database Service instances for processing. 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.
Latency Based Routing is available for the "A", "AAAA", "CNAME", "TXT" DNS record types as well as the Route 53 specific "ALIAS to A" and "ALIAS to AAAA" record types.
We're introducing Latency Based Routing pricing at $0.75 per million queries, for the first billion queries per month, and $0.375 per million queries for all additional queries in a given month. Queries to latency based Elastic Load Balancer "ALIAS" record sets are free of charge.
A Smooth Transition to Latency Based Routing
Today, we're also unlocking another feature in Amazon Route 53. It is now possible to create "ALIAS" records that point to resource record sets within your own Route 53 hosted zone. These ALIAS records act as pointers or arrows in a decision tree, enabling you to compose latency based record sets, weighted record sets and multi-record record sets to address advanced or complex routing scenarios.
By combining weighted resource record sets and an alias to a latency based record set, it's possible to have a simple "dial" determining how often latency based routing should be used at first. By starting with a small percentage and gradually increasing that percentage any risks of regional overload or poor user experience can be minimized.
For example, when migrating from a single-region configuration with an instance in the AWS US East (Northern Virginia) region to a latency based routing configuration with instances in both US East (Northern Virginia) and EU (Ireland), we might configure a series of record sets forming a decision tree that resembles the following diagram:
With this kind of configuration, approximately 99% of DNS queries will be unaffected by latency based routing, and users will be directed to the US East (Northern Virginia) answer (192.0.2.1). The other 1% of the time, Route 53 will choose where to send the user based on network latency - some users will be directed to eu-west-1, some to us-east-1 - based on our own global connectivity measurements between the origin of the request and the two AWS regions. Gradually, these percentages can be altered and over time we can transition to a fully latency based decision process.
Combining Latency Based Routing and Weighted Round Robin Record Sets
It is also possible to combine latency based record sets and weighted round robin record sets in the opposite order. For example, you may want to distribute load across several instances in the same region using weighted round robin DNS.
In the example below, Route 53 can be configured to first use latency based routing to decide what region to direct a user to, and then if the EU (Dublin) region is selected, to apply a weighted round-robin policy with half of the answers returning 192.0.2.127 and the other half returning 192.0.2.128.
Bonus Scaling Feature: Weighting More Than 100 record Sets and Multi-record Answers
Amazon Route 53 is used by many large-scale web presences and in response to feedback from our customers we're now also enabling weighted round-robin DNS for even larger sets of answers. Until now, weighted resource record sets have been restricted to just one hundred record sets, each with just one record (e.g. IP address) each.
Firstly, a weighted "ALIAS" record set is itself now also a valid target for a weighted "ALIAS" record set. This allows for recursive weighted trees of aliases to be created. We allow up to three levels of recursion, permitting up to one million distinct weighted record sets per DNS name.
Secondly, another way to weight more than one hundred records is to create record sets each containing multiple records. For example if you have twenty Elastic IPs hosting your service it may be useful to create five record sets, each containing four IP addresses. If the DNS clients support retries then it is particularly useful to ensure that each record set contains a mix of records from different availability zones. This way, alternatives are available for clients when an availability zone is unavailable.
These kinds of multi-record record sets may now be used with weighted round-robin DNS by again using "ALIAS" records. Multi-record record sets are completely valid as a target for weighted aliases.
You can learn more about Latency Based Routing, aliasing and WRR in the Route 53 documentation.
We are very interested in hearing about how you may use the new Latency Based Routing feature in your business or application. Please take a minute and provide us feedback on this one-question Route 53 survey.
You can also learn more about Amazon Route 53 and the Latency Based Routing feature by registering for our Route 53 webinar (coming up on April 26th at 10AM PST).
-- Jeff (with lots of help from Colm MacCarthaigh);