I registered my first domain name almost 20 years ago! Back then, the mapping from a domain name to a server was simple and straightforward. Load balancers, geographic redundancy, website monitoring, cloud computing, and the like had not yet entered the scene. The mapping was always from a domain name to a single, unchanging IP address.
Today of course, the situation is a lot different. The mapping from domain name to IP address is no longer necessarily 1 to 1. Sophisticated sites can route requests to servers that are as close as possible to the requester, and may also want to use the requester’s location in other ways.
Route 53 Traffic Flow
In order to make it easier for you to build and run cloud-based applications that embody these characteristics, we introduced a new Traffic Flow feature for Amazon Route 53 last week. You can use this feature to build a routing system that uses a combination of geographic location, latency, and availability to route traffic from your users to your cloud or on-premises endpoints.
You can build your traffic routing policies from scratch, or you can pick a template from a library and then customize it. You can create multiple policies for a given DNS name, and decide which one is active at any given time. Even better, you can do all of this graphically, from within the Route 53 Console.
Creating a Traffic Policy
I will create a traffic policy for one of my domain names, doordesk.com. I start by entering a name and a description:
The console displays the graphical traffic policy editor:
The Start point is simply a DNS entry:
It can connect to several different types of rules and endpoints:
If I choose to create a new endpoint, the editor prompts me for the details:
I can map the Start point to an IP address by choosing Value and entering the address:
At this point I have designed a simple policy that maps the A record to a fixed IP address.
Perhaps I have a production server and a pre-production server, and I would like to send 95% of the traffic to the first one and the remaining 5% to the second. I can do this by creating a Weighted rule that looks like this:
As you can see above, I can also point each element of the rule at one of my Route 53 health checks. If I do this, traffic will be routed to the endpoint only if the health check indicates that the endpoint is healthy.
I can also create a Failover rule. For example, I can route traffic to an IP address if the server is healthy, and to a static, fallback website hosted in S3 if it is not. Here’s how I do that:
The next option is to create a Geolocation rule. I can use a rule of this type to route traffic based on the geographic origin of the DNS query. Here’s a sample:
The final type of rule is called a Latency rule. A rule of this type routes traffic to the AWS region with the lowest latency, as measured from the location of the DNS request. Perhaps I have EC2 instances in the US East (Northern Virginia) and Asia Pacific (Tokyo) regions, and want to provide a good experience by routing traffic as appropriate. Here’s how I would set that up:
The rules can be combined to create more complex traffic flows. Here’s part of a policy that combines Geolocation, Latency, Weighting, and Failover rules, in that order:
After all of this experimentation, I moved ahead with the first policy that I showed up: a simple mapping from IP address to endpoint. I clicked on Save as new version.
Create Policy Records
The next is to create policy records that actually implement (DNS-wise) the traffic policy. The console makes this really easy. I simply select the domain name and the DNS name:
When this action finishes (generally within a minute or two), the DNS records for the new policy take effect in Route 53. As is always the case when you make changes, the DNS TTL (Time to Live) for the domain can mean that changes can take a while to propagate to other DNS servers and to client applications that cache the results of DNS lookups.
You can create and store multiple versions of each of your traffic policies, and then put any desired version in to effect (by creating policy records) as desired:
This new feature is available now and you can start using it today. To learn more, read about Using Traffic Flow to Route DNS Traffic in the Route 53 Developer Guide. Pricing starts at $50.00 per policy record per month (see Route 53 Pricing for more info).