When you create a resource record set, you choose a routing policy, which determines how Amazon Route 53 responds to queries:
Use a simple routing policy when you have a single resource that performs a given function for your domain, for example, one web server that serves content for the example.com website. In this case, Amazon Route 53 responds to DNS queries based only on the values in the resource record set, for example, the IP address in an A record.
Use the weighted routing policy when you have multiple resources that perform the same function (for example, web servers that serve the same website) and you want Amazon Route 53 to route traffic to those resources in proportions that you specify (for example, 40% to one server and 60% to the other). For more information about weighted resource record sets, see Weighted Routing.
Use the latency routing policy when you have resources in multiple Amazon EC2 data centers that perform the same function and you want Amazon Route 53 to respond to DNS queries with the resources that provide the best latency. For example, you might have web servers for example.com in the Amazon EC2 data centers in Ireland and in Tokyo. When a user browses to example.com, Amazon Route 53 chooses to respond to the DNS query based on which data center gives your user the lowest latency. For more information about latency resource record sets, see Latency-Based Routing.
Use the failover routing policy when you want to configure active-passive failover, in which one resource takes all traffic when it's available and the other resource takes all traffic when the first resource isn't available. Note that you can't create failover resource record sets for private hosted zones. For more information about failover resource record sets, see Configuring Active-Passive Failover by Using Amazon Route 53 Failover and Failover Alias Resource Record Sets.
Use the geolocation routing policy when you want Amazon Route 53 to respond to DNS queries based on the location of your users. For more information about geolocation resource record sets, see Geolocation Routing.
Weighted resource record sets let you associate multiple resources with a single DNS name. This can be useful for a variety of purposes, including load balancing and testing new versions of software. To create a group of weighted resource record sets, you create two or more resource record sets that have the same combination of DNS name and type, and you assign each resource record set a unique identifier and a relative weight.
When processing a DNS query, Amazon Route 53 searches for a resource record set or a group of resource record sets that have the specified name and type. For weighted resource record sets, Amazon Route 53 selects one from the group. The probability of any one resource record set being selected depends on its weight as a proportion of the total weight for all resource record sets in the group:
For example, suppose you create three resource record sets for www.example.com. The three A records have weights of 1, 1, and 3 (sum = 5). On average, Amazon Route 53 selects each of the first two resource record sets one-fifth of the time, and returns the third resource record set three-fifths of the time.
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.
To use latency-based routing, you create a latency resource record set for the Amazon EC2 resource in each region that hosts your application. When Amazon Route 53 receives a query for the corresponding domain, it selects the latency resource record set for the Amazon EC2 region that gives the user the lowest latency. Amazon Route 53 then responds with the value associated with that resource record set.
For example, suppose you have ELB load balancers in the US West (Oregon) region and in the Asia Pacific (Singapore) region, and that you've created a latency resource record set in Amazon Route 53 for each load balancer. A user in London enters the name of your domain in a browser, and DNS routes the request to an Amazon Route 53 name server. Amazon Route 53 refers to its data on latency between London and the Singapore region and between London and the Oregon region. If latency is lower between London and the Oregon region, Amazon Route 53 responds to the user's request with the IP address of your load balancer in the Amazon EC2 data center in Oregon. If latency is lower between London and the Singapore region, Amazon Route 53 responds with the IP address of your load balancer in the Amazon EC2 data center in Singapore.
Latency between hosts on the Internet can change over time as a result of changes in network connectivity and routing. Latency-based routing is based on latency measurements performed over a period of time, and the measurements reflect these changes. For example, if you have load balancers in the Oregon and Singapore Amazon EC2 regions, a request that is routed to the Oregon region this week might be routed to the Singapore region next week if latency from the user to the Singapore region improves.
You can create latency resource record sets for the following:
Amazon EC2 instances, with or without Elastic IP addresses.
ELB load balancers, which balance traffic for Amazon EC2 instances.
You can create latency resource record sets using any record type that Amazon Route 53 supports except NS or SOA. For information about supported record types, see Supported DNS Resource Record Types.
To create latency resource record sets, perform the following steps:
Create the AWS resources for your application:
If you want to use ELB load balancers, create one or more load balancers in each Amazon EC2 region in which you want to run your application. For more information, see Managing Load Balancers in the Elastic Load Balancing Developer Guide.
The name you specify when you create a load balancer is the name you'll use when you create a latency resource record set in Amazon Route 53.
If you want to use Amazon EC2 instances, launch one or more Amazon EC2 instances in each Amazon EC2 region in which you want to run your application. For more information, see Amazon EC2 Getting Started Guide.
We recommend that you assign Elastic IP addresses to your Amazon EC2 instances to ensure that the IP addresses don't change.
Create latency resource record sets in your hosted zone. For information about how to create resource record sets using the Amazon Route 53 console, see Creating Resource Record Sets by Using the Amazon Route 53 Console. For information about how to create latency resource record sets using the Amazon Route 53 API, see POST ChangeResourceRecordSets in the Amazon Route 53 API Reference.
Geolocation routing lets you choose the resources that serve your traffic based on the geographic location of your users, meaning the location from which DNS queries originate. For example, you might want all queries from Africa to be routed to a web server with an IP address of 192.0.2.111.
When you use geolocation routing, you can localize your content and present some or all of your website in the language of your users. You can also use geolocation routing to restrict distribution of content to only the locations in which you have distribution rights. Another possible use is for balancing load across endpoints in a predictable, easy-to-manage way, so that each user location is consistently routed to the same endpoint.
You can specify geographic locations by continent, by country, or by state in the United States. If you create separate resource record sets for overlapping geographic regions—for example, one resource record set for a continent and one for a country on the same continent—priority goes to the smallest geographic region. This allows you to route some queries for a continent to one resource and to route queries for selected countries on that continent to a different resource. (For a list of the countries on each continent, see Location.)
Geolocation works by mapping IP addresses to locations. However, some IP addresses aren't mapped to geographic locations, so even if you create geolocation resource record sets that cover all seven continents, Amazon Route 53 will receive some DNS queries from locations that it can't identify. You can create a default resource record set that handles both queries from IP addresses that aren't mapped to any location and queries that come from locations for which you haven't created geolocation resource record sets. If you don't create a default resource record set, Amazon Route 53 returns a "no answer" response for queries from those locations.
You cannot create two geolocation resource record sets that specify the same geographic location. You also cannot create geolocation resource record sets that have the same values for Name and Type as the Name and Type of non-geolocation resource record sets.
To improve the accuracy of geolocation routing, Amazon Route 53 supports the edns-client-subnet extension of EDNS0. (EDNS0 adds several optional extensions to the DNS protocol.) Amazon Route 53 can use edns-client-subnet only when DNS resolvers support it:
When a browser or other viewer uses a DNS resolver that does not support edns-client-subnet, Amazon Route 53 uses the source IP address of the DNS resolver to approximate the location of the user and responds to geolocation queries with the DNS record for the resolver's location.
When a browser or other viewer uses a DNS resolver that does support edns-client-subnet, the DNS resolver sends Amazon Route 53 a truncated version of the user's IP address. Amazon Route 53 determines the location of the user based on the truncated IP address rather than the source IP address of the DNS resolver; this typically provides a more accurate estimate of the user's location. Amazon Route 53 then responds to geolocation queries with the DNS record for the user's location.
For more information about edns-client-subnet, see the IETF draft Client Subnet in DNS Requests.