# Choosing a routing policy When you create a record, you choose a routing policy, which determines how Amazon Route 53 responds to queries: + **Simple routing policy** – Use for a single resource that performs a given function for your domain, for example, a web server that serves content for the example.com website. You can use simple routing to create records in a private hosted zone. + **Failover routing policy** – Use when you want to configure active-passive failover. You can use failover routing to create records in a private hosted zone. + **Geolocation routing policy** – Use when you want to route traffic based on the location of your users. You can use geolocation routing to create records in a private hosted zone. + **Geoproximity routing policy** – Use when you want to route traffic based on the location of your resources and, optionally, shift traffic from resources in one location to resources in another location. You can use geoproximity routing to create records in a private hosted zone. + **Latency routing policy** – Use when you have resources in multiple AWS Regions and you want to route traffic to the Region that provides the best latency. You can use latency routing to create records in a private hosted zone. + **IP-based routing policy** – Use when you want to route traffic based on the location of your users, and have the IP addresses that the traffic originates from. + **Multivalue answer routing policy** – Use when you want Route 53 to respond to DNS queries with up to eight healthy records selected at random. You can use multivalue answer routing to create records in a private hosted zone. + **Weighted routing policy** – Use to route traffic to multiple resources in proportions that you specify. You can use weighted routing to create records in a private hosted zone. **Topics** + [ # Simple routing ](routing-policy-simple.md) + [ # Failover routing ](routing-policy-failover.md) + [ # Geolocation routing ](routing-policy-geo.md) + [ # Geoproximity routing ](routing-policy-geoproximity.md) + [ # Latency-based routing ](routing-policy-latency.md) + [ # IP-based routing ](routing-policy-ipbased.md) + [ # Multivalue answer routing ](routing-policy-multivalue.md) + [ # Weighted routing ](routing-policy-weighted.md) + [ # How Amazon Route 53 uses EDNS0 to estimate the location of a user ](routing-policy-edns0.md) # Simple routing Simple routing lets you configure standard DNS records, with no special Route 53 routing such as weighted or latency. With simple routing, you typically route traffic to a single resource, for example, to a web server for your website. You can use simple routing policy for records in a private hosted zone. If you choose the simple routing policy in the Route 53 console, you can't create multiple records that have the same name and type, but you can specify multiple values in the same record, such as multiple IP addresses. (If you choose the simple routing policy for an alias record, you can specify only one AWS resource or one record in the current hosted zone.) If you specify multiple values in a record, Route 53 returns all values to the recursive resolver in random order, and the resolver returns the values to the client (such as a web browser) that submitted the DNS query. The client then chooses a value and resubmits the query. With simple routing policy, although you can specify multiple IP addresses, these IP addresses are not health checked. For information about values that you specify when you use the simple routing policy to create records, see the following topics: + [Values specific for simple records](resource-record-sets-values-basic.md) + [Values specific for simple alias records](resource-record-sets-values-alias.md) + [Values that are common for all routing policies](resource-record-sets-values-shared.md) + [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md) # Failover routing Failover routing lets you route traffic to a resource when the resource is healthy or to a different resource when the first resource is unhealthy. The primary and secondary records can route traffic to anything from an Amazon S3 bucket that is configured as a website to a complex tree of records. For more information, see [Active-passive failover](dns-failover-types.md#dns-failover-types-active-passive). You can use failover routing policy for records in a private hosted zone. For information about values that you specify when you use the failover routing policy to create records, see the following topics: + [Values specific for failover records](resource-record-sets-values-failover.md) + [Values specific for failover alias records](resource-record-sets-values-failover-alias.md) + [Values that are common for all routing policies](resource-record-sets-values-shared.md) + [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md) # Geolocation routing Geolocation routing lets you choose the resources that serve your traffic based on the geographic location of your users, meaning the location that DNS queries originate from. For example, you might want all queries from Europe to be routed to an Elastic Load Balancing load balancer in the Frankfurt Region. 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 records for overlapping geographic regions—for example, one record for North America and one for Canada—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](resource-record-sets-values-geo.md#rrsets-values-geo-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 records 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 record that handles both queries from IP addresses that aren't mapped to any location and queries that come from locations that you haven't created geolocation records for. If you don't create a default record, Route 53 returns a "no answer" response for queries from those locations. You can use geolocation routing for records in both public and private hosted zones. For more information, see [How Amazon Route 53 uses EDNS0 to estimate the location of a user](routing-policy-edns0.md). For information about values that you specify when you use the geolocation routing policy to create records, see the following topics: + [Values specific for geolocation records](resource-record-sets-values-geo.md) + [Values specific for geolocation alias records](resource-record-sets-values-geo-alias.md) + [Values that are common for all routing policies](resource-record-sets-values-shared.md) + [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md) # Geolocation routing in private hosted zones For private hosted zones, Route 53 responds to DNS queries based on the AWS Region of the VPC that the query originated from. For the list of AWS Regions, see [Regions and zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) in the *Amazon EC2 user guide*. If the DNS query originates from an on-premises part of a hybrid network, it will be considered as having originated from the AWS Region that the VPC is located in. If you include health checks, you can create default records for: + IP addresses that aren't mapped to geographic locations. + DNS queries that come from locations that you haven't created geolocation records for. If the geolocation record for the DNS query's region is unhealthy, the default record will be returned (if it is healthy). In the example configuration in the following figure, DNS queries coming from an us-east-1 AWS Region (Virginia) will be routed to the 1.1.1.1 endpoint. ![\[A screenshot that shows a geolocation record for a private hosted zone.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/geolocation-phz.png) # Geoproximity routing Geoproximity routing lets Amazon Route 53 route traffic to your resources based on the geographic location of your users and your resources. It routes traffic to the closest resource that is available. You can also optionally choose to route more traffic or less traffic to a given resource by specifying a value, known as a *bias*. A bias expands or shrinks the size of the geographic region from which traffic is routed to a resource. You create geoproximity rules for your resources and specify one of the following values for each rule: + If you're using AWS resources, specify the AWS Region or Local Zone Group that you created the resource in. + If you're using non-AWS resources, specify the latitude and longitude of the resource. To use AWS Local Zones, you have to first enable them. For more information, see [Getting started with Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) in the *AWS Local Zones User Guide*. To learn about the difference between AWS Regions and Local Zones, see [Regions and Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) in the *Amazon EC2 User Guide*. To optionally change the size of the geographic region from which Route 53 routes traffic to a resource, specify the applicable value for the bias: + To expand the size of the geographic region from which Route 53 routes traffic to a resource, specify a positive integer from 1 to 99 for the bias. Route 53 shrinks the size of adjacent regions. + To shrink the size of the geographic region from which Route 53 routes traffic to a resource, specify a negative bias of -1 to -99. Route 53 expands the size of adjacent regions. **Note** We're updating the Traffic Flow console for Route 53. During the transition period, you can continue to use the old console. Choose the tab for the console you are using. + [New console](#traffic-flow-geoprox-routing-map-new) + [Old console](#traffic-flow-geoprox-routing-map-old) ------ #### [ New console ] The following map shows four AWS Regions (numbered 1 through 5): 1. US West (Oregon) 1. Europe (Frankfurt) 1. Asia Pacific (Tokyo) 1. Africa (Cape Town) 1. Middle East (Bahrain) **Note** The maps are available only with Traffic Flow. ![\[A map of the world that shows how traffic is routed when you have geoproximity records for resources in the AWS Regions in US West (Oregon), Europe (Frankfurt), Asia Pacific (Tokyo), Africa (Cape Town) and Middle East (Bahrain).\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png) The following map shows what happens if you add a bias of \$125 for the US West (Oregon) Region (number **1** on the map). Traffic is routed to the resource in that Region from a larger portion of North America and from all of South America than previously. ![\[A map of the world that shows how traffic is routed when you add a bias of +25 in the US East (Northern Virginia) Region.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png) The following map shows what happens if you change the bias to -25 for the US West (Oregon) Region. Traffic is routed to the resource in that Region from smaller portions of North and South America than previously, and more traffic is routed to resources in the adjacent regions **2**, **3**, and **4**. ![\[A map of the world that shows how traffic is routed when you add a bias of -25 in the US West (Oregon) Region.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png) ------ #### [ Old console ] The following map shows four AWS Regions (numbered 1 through 4) and a location in Johannesburg, South Africa that is specified by latitude and longitude (5). **Note** The maps are available only with Traffic Flow. ![\[A map of the world that shows how traffic is routed when you have geoproximity records for resources in the AWS Regions in US West (Oregon), US East (N. Virginia), Europe (Paris), and Asia Pacific (Tokyo), and you have a record for a non-AWS resource in Johannesburg, South Africa.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png) The following map shows what happens if you add a bias of \$125 for the US East (N. Virginia) Region (number **2** on the map). Traffic is routed to the resource in that Region from a larger portion of North America than previously, and from all of South America. ![\[A map of the world that shows how traffic is routed when you add a bias of +25 in the US East (Northern Virginia) Region.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png) The following map shows what happens if you change the bias to -25 for the US East (N. Virginia) Region. Traffic is routed to the resource in that Region from smaller portions of North and South America than previously, and more traffic is routed to resources in the adjacent regions **1**, **3**, and **5**. ![\[A map of the world that shows how traffic is routed when you add a bias of -25 in the US East (N. Virginia) Region.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png) ------ The effect of changing the bias for your resources depends on a number of factors, including the following: + The number of resources that you have. + How close the resources are to one another. + The number of users that you have near the border area between geographic regions. For example, suppose you have resources in the AWS Regions US East (N. Virginia) and US West (Oregon), and you have a lot of users in Dallas, Austin, and San Antonio, Texas, USA. Those cities are approximately equidistant between your resources, so a small change in bias could result in a large swing in traffic from resources in one AWS Region to another. We recommend that you change the bias in small increments to prevent overwhelming your resources, due to an unanticipated swing in traffic. For more information, see [How Amazon Route 53 uses EDNS0 to estimate the location of a user](routing-policy-edns0.md). ## How Amazon Route 53 uses bias to route traffic Here's the formula that Amazon Route 53 uses to determine how to route traffic: **Bias** `Biased distance = actual distance * [1 - (bias/100)]` When the value of the bias is positive, Route 53 treats the source of a DNS query and the resource that you specify in a geoproximity record (such as an EC2 instance in an AWS Region) as if they were closer together than they really are. For example, suppose you have the following geoproximity records: + A record for web server A, which has a positive bias of 50 + A record for web server B, which has no bias When a geoproximity record has a positive bias of 50, Route 53 halves the distance between the source of a query and the resource for that record. Then Route 53 calculates which resource is closer to the source of the query. Suppose web server A is 150 kilometers from the source of a query and web server B is 100 kilometers from the source of the query. If neither record had a bias, Route 53 would route the query to web server B because it's closer. However, because the record for web server A has a positive bias of 50, Route 53 treats web server A as if it's 75 kilometers from the source of the query. As a result, Route 53 routes the query to web server A. Here's the calculation for a positive bias of 50: ``` Bias = 50 Biased distance = actual distance * [1 - (bias/100)] Biased distance = 150 kilometers * [1 - (50/100)] Biased distance = 150 kilometers * (1 - .50) Biased distance = 150 kilometers * (.50) Biased distance = 75 kilometers ``` # Latency-based routing If your application is hosted in multiple AWS Regions, you can improve performance for your users by serving their requests from the AWS Region that provides the lowest latency. **Note** Data about the latency between users and your resources is based entirely on traffic between users and AWS data centers. If you aren't using resources in an AWS Region, the actual latency between your users and your resources can vary significantly from AWS latency data. This is true even if your resources are located in the same city as an AWS Region. To use latency-based routing, you create latency records for your resources in multiple AWS Regions. When Route 53 receives a DNS query for your domain or subdomain (example.com or acme.example.com), it determines which AWS Regions you've created latency records for, determines which Region gives the user the lowest latency, and then selects a latency record for that Region. Route 53 responds with the value from the selected record, such as the IP address for a web server. For example, suppose you have Elastic Load Balancing load balancers in the US West (Oregon) Region and in the Asia Pacific (Singapore) Region. You create a latency record for each load balancer. Here's what happens when a user in London enters the name of your domain in a browser: 1. DNS routes the query to a Route 53 name server. 1. Route 53 refers to its data on latency between London and the Singapore Region and between London and the Oregon Region. 1. If latency is lower between the London and Oregon Regions, Route 53 responds to the query with the IP address for the Oregon load balancer. If latency is lower between London and the Singapore Region, Route 53 responds with the IP address for the Singapore load balancer. 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 taken over a period of time, and the measurements reflect these changes. A request that is routed to the Oregon Region this week might be routed to the Singapore Region next week. **Note** When a browser or other viewer uses a DNS resolver that supports the edns-client-subnet extension of EDNS0, the DNS resolver sends Route 53 a truncated version of the user's IP address. If you configure latency-based routing, Route 53 considers this value when routing traffic to your resources. For more information, see [How Amazon Route 53 uses EDNS0 to estimate the location of a user](routing-policy-edns0.md). You can use latency routing policy for records in a private hosted zone. For information about values that you specify when you use the latency routing policy to create records, see the following topics: + [Values specific for latency records](resource-record-sets-values-latency.md) + [Values specific for latency alias records](resource-record-sets-values-latency-alias.md) + [Values that are common for all routing policies](resource-record-sets-values-shared.md) + [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md) # Latency-based routing in private hosted zones For private hosted zones, Route 53 answers DNS queries with an endpoint that is in the same AWS Region, or is closest in distance to the AWS Region of the VPC that the query originated from. **Note** If you have an outbound endpoint forwarded to an inbound endpoint, the record will resolve based on where the inbound endpoint is, not the outbound endpoint. If you include health checks, and the record with the lowest latency to the query's origin is unhealthy, a healthy endpoint with the next lowest latency is returned. In the example configuration in the following figure, DNS queries coming from a us-east-1 AWS Region, or closest to it, will be routed to the 1.1.1.1 endpoint. DNS queries from us-west-2, or closest to it, will be routed to the 2.2.2.2 endpoint. ![\[A screenshot that shows two latency records for a private hosted zone.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/latency-phz.png) # IP-based routing With IP-based routing in Amazon Route 53, you can fine-tune your DNS routing by using your understanding of your network, applications, and clients to make the best DNS routing decisions for your end users. IP-based routing gives you granular control to optimize performance or reduce network costs by uploading your data to Route 53 in the form of user-IP-to-endpoint mappings. Geolocation and latency-based routing is based on data that Route 53 collects and keeps up to date. This approach works well for the majority of customers, but IP-based routing offers you the additional ability to optimize routing based on specific knowledge of your customer base. For example, a global video content provider might want to route end users from a particular internet service provider (ISP). Some common use cases for IP-based routing are the following: + You want to route end users from certain ISPs to specific endpoints so you can optimize network transit costs or performance. + You want to add overrides to existing Route 53 routing types, such as geolocation routing, based on your knowledge of your clients' physical locations. **Managing IP ranges and associating them to a resource record set (RRSet)** For IPv4, you can use CIDR blocks between 1 and 24 bits of length, inclusive, while for IPv6, you can use CIDR blocks between 1 and 48 bits of length, inclusive. To define a zero bit CIDR block (0.0.0.0/0 or ::/0), use the default ("\$1") location. For DNS queries with a CIDR longer than the one specified in the CIDR collection, Route 53 will match it to the shorter CIDR. For example, if you specify 2001:0DB8::/32 as the CIDR block in your CIDR collection and a query originates from 2001:0DB8:0000:1234::/48, it will match. If, on the other hand, you specify 2001:0DB8:0000:1234::/48 in your CIDR collection and a query originates from 2001:0DB8::/32, this will not match and Route 53 will answer with the record for the default ("\$1") location. You can group sets of CIDR blocks (or IP ranges) into CIDR locations, which are in turn grouped into reusable entities called CIDR collections: **CIDR block** An IP range in CIDR notation, for example, 192.0.2.0/24 or 2001:DB8::/32. **CIDR location** A named list of CIDR blocks. For example, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:DB8::/32 ]. The blocks in a CIDR location list don't have to be adjacent or the same range. A single location can have both IPv4 and IPv6 blocks, and this location can be associated to both A and AAAA record sets, respectively. The location name is often a location by convention, but can be any string, for example, *Company-A*. **CIDR collection** A named collection of locations. For example, mycollection = [example-isp-seattle, example-isp-tokyo]. IP-based routing resource record sets reference a location in a collection, and all resource record sets for the same record set name and type must reference the same collection. For example, if you create websites in two Regions and want to direct DNS queries from two different CIDR locations to a specific website based on the originating IP addresses, then both of those locations must be listed in the same CIDR collection. You cannot use IP-based routing policy for records in a private hosted zone. For information about values that you specify when you use the IP-based routing policy to create records, see the following topics: + [Values specific for IP-based records](resource-record-sets-values-ipbased.md) + [Values specific for IP-based alias records](resource-record-sets-values-ipbased-alias.md) + [Values that are common for all routing policies](resource-record-sets-values-shared.md) + [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md) **Topics** + [ # Creating a CIDR collection with CIDR locations and blocks ](resource-record-sets-creating-cidr-collection.md) + [ # Working with CIDR locations and blocks ](resource-record-sets-working-with-cidr-locations.md) + [ # Deleting a CIDR collection ](resource-record-sets-delete-cidr-collection.md) + [ # Moving a geolocation to IP-based routing ](resource-record-sets-move-geolocation-to-cidr.md) # Creating a CIDR collection with CIDR locations and blocks To get started, create a CIDR collection and add CIDR blocks and locations to it. **To create a CIDR collection using the Route 53 console** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **IP-based routing**, and then **CIDR collections**. 1. Select **Create CIDR collection**. 1. In the **Create CIDR collection** pane, under **Details**, enter a name for the collection. 1. Choose **Create collection** to create an empty collection. - or - In the **Create CIDR locations** section, enter a name for the CIDR location in the **CIDR location** box. The location name can be any identifying string, for example **company 1**, or **Seattle**. It doesn't have to be an actual geographic location. **Important** The CIDR location name has a maximum length of 16 characters. Enter the CIDR blocks in the **CIDR blocks** box one per line. These can be IPv4 or IPv6 addresses ranging from /0 to /24 for IPv4 and /0 to /48 for IPv6. 1. After you have entered the CIDR blocks, choose **Create CIDR collection**, or **Add another location** to keep entering locations and CIDR block. You can enter multiple CIDR locations per collection. 1. After you have entered CIDR locations, choose **Create CIDR collection**. # Working with CIDR locations and blocks **To work with CIDR locations by using the Route 53 console** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **IP-based routing**, **CIDR collections** and then, in the **CIDR collections** section, click on a link to a CIDR collection in the **Collection name** list. On the **CIDR locations** page, you can create a CIDR location, delete it, or edit a location and its blocks. + To create a location, choose **Create CIDR location**. + In the **Create CIDR location** pane, enter a name for the location, the CIDR blocks associated with the location, and then choose **Create**. + To view a CIDR location and the blocks within, choose the radio button next to a location to display its name and CIDR blocks in the location pane. In this pane, you can also choose **Edit** to update the name of the location or its CIDR blocks. Choose **Save** when you have finished editing. + To delete a CIDR location and the blocks within, choose the radio button next to the location you want to delete, and then choose **Delete**. To confirm deletion, enter the location name in the text input field and choose **Delete** again. **Important** Deleting a CIDR location can't be undone. If you have any DNS records associated with the location, your domain might become unreachable. # Deleting a CIDR collection **To delete a CIDR collection, its locations, and blocks by using the Route 53 console** 1. Sign in to the AWS Management Console and open the Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. In the navigation pane, choose **IP-based routing** and then **CIDR collections**. 1. In the **CIDR collections** section, click the linked name of the collection that you want to delete. 1. On the **CIDR locations** page, select each location one at a time, choose **Delete**, enter its name in the dialog box, and then choose **Delete**. You must delete each location associated with a CIDR collection before you can delete the collection. 1. After the deletion of each CIDR location is complete, on the **CIDR locations** page, choose the radio button next to the collection you want to delete, and then choose **Delete**. # Moving a geolocation to IP-based routing If you are using either geolocation or geoproximity routing policies, and you’re consistently seeing specific clients routed to an endpoint that isn’t optimal based on their physical location or network topology, you can better target these clients’ public IP ranges by using IP-based routing. The following table contains an example geolocation configuration for an existing geolocation routing that we will fine-tune for California IP ranges. | Record set name | Routing policy and origin | IP address of the application endpoint | | --- | --- | --- | | example.com | Geolocation-routing (US) | `198.51.100.1` | | example.com | Geolocation-routing (EU) | `198.51.100.2` | To override IP ranges from California to go to a new application endpoint, first recreate the geolocation routing under a new record set name. | Record set name | Routing policy and origin | IP address of the application endpoint | | --- | --- | --- | | geo.example.com | Geolocation-routing (US) | `198.51.100.1` | | geo.example.com | Geoloaction-routing (EU) | `198.51.100.2` | Then, create IP-based routing records and a default record that points to your recently recreated geolocation routing recordset. | Record set name | Routing policy and origin | IP address of the application endpoint | | --- | --- | --- | | example.com | IP-based routing (default) | Alias record to geo.example.com application endpoint that you want to be the default. For example, `198.51.100.1`. | | example.com | IP-based routing (California IP ranges) | `198.51.100.3` | # Multivalue answer routing Multivalue answer routing lets you configure Amazon Route 53 to return multiple values, such as IP addresses for your web servers, in response to DNS queries. You can specify multiple values for almost any record, but multivalue answer routing also lets you check the health of each resource, so Route 53 returns only values for healthy resources. It's not a substitute for a load balancer, but the ability to return multiple health-checkable IP addresses is a way to use DNS to improve availability and load balancing. To route traffic approximately randomly to multiple resources, such as web servers, you create one multivalue answer record for each resource and, optionally, associate a Route 53 health check with each record. Route 53 responds to DNS queries with up to eight healthy records and gives different answers to different DNS resolvers. If a web server becomes unavailable after a resolver caches a response, client software can try another IP address in the response. Note the following: + If you associate a health check with a multivalue answer record, Route 53 responds to DNS queries with the corresponding IP address only when the health check is healthy. + If you don't associate a health check with a multivalue answer record, Route 53 always considers the record to be healthy. + If you have eight or fewer healthy records, Route 53 responds to all DNS queries with all the healthy records. + When all records are unhealthy, Route 53 responds to DNS queries with up to eight unhealthy records. You can use multivalue answer routing policy for records in a private hosted zone. For information about values that you specify when you use the multivalue answer routing policy to create records, see [Values specific for multivalue answer records](resource-record-sets-values-multivalue.md) and [Values that are common for all routing policies](resource-record-sets-values-shared.md). # Weighted routing Weighted routing lets you associate multiple resources with a single domain name (example.com) or subdomain name (acme.example.com) and choose how much traffic is routed to each resource. This can be useful for a variety of purposes, including load balancing and testing new versions of software. To configure weighted routing, you create records that have the same name and type for each of your resources. You assign each record a relative weight that corresponds with how much traffic you want to send to each resource. Amazon Route 53 sends traffic to a resource based on the weight that you assign to the record as a proportion of the total weight for all records in the group: ![\[Formula for how much traffic is routed to a given resource: weight for a specified record / sum of the weights for all records.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/WRR_calculation.png) For example, if you want to send a tiny portion of your traffic to one resource and the rest to another resource, you might specify weights of 1 and 255. The resource with a weight of 1 gets 1/256th of the traffic (1/(1\$1255)), and the other resource gets 255/256ths (255/(1\$1255)). You can gradually change the balance by changing the weights. If you want to stop sending traffic to a resource, you can change the weight for that record to 0. For information about values that you specify when you use the weighted routing policy to create records, see the following topics: + [Values specific for weighted records](resource-record-sets-values-weighted.md) + [Values specific for weighted alias records](resource-record-sets-values-weighted-alias.md) + [Values that are common for all routing policies](resource-record-sets-values-shared.md) + [Values that are common for alias records for all routing policies](resource-record-sets-values-alias-common.md) You can use weighted routing policy for records in a private hosted zone. ## Health checks and weighted routing If you add health checks to all the records in a group of weighted records, but you give nonzero weights to some records and zero weights to others, health checks work the same as when all records have nonzero weights with the following exceptions: + Route 53 initially considers only the nonzero weighted records, if any. + If all the records that have a weight greater than 0 are unhealthy, then Route 53 considers the zero-weighted records. The following table details the behavior when the 0-weight record includes a health check: | | Record 1 | Record 2 | Record 3 | | --- |--- |--- |--- | | Weight | 1 | 1 | 0 | | Includes health check? | Yes | Yes | Yes | | | | --- | | Health check status | Unhealthy | Unhealthy | Healthy | | DNS query answered? | No | No | Yes | | | | --- | | Health check status | Unhealthy | Unhealthy | Unhealthy | | DNS query answered? | Yes | Yes | No | | | | --- | | Health check status | Unhealthy | Healthy | Unhealthy | | DNS query answered? | No | Yes | No | | | | --- | | Health check status | Healthy | Healthy | Unhealthy | | DNS query answered? | Yes | Yes | No | | | | --- | | Health check status | Healthy | Healthy | Healthy | | DNS query answered? | Yes | Yes | No | The following table details the behavior when the 0-weight record doesn't include a health check: | | Record 1 | Record 2 | Record 3 | | --- |--- |--- |--- | | Weight | 1 | 1 | 0 | | Includes health check? | Yes | Yes | No | | | | --- | | Health check status | Healthy | Healthy | N/A | | DNS query answered? | Yes | Yes | No | | | | --- | | Health check status | Unhealthy | Unhealthy | N/A | | DNS query answered? | No | No | Yes | | | | --- | | Health check status | Unhealthy | Healthy | N/A | | DNS query answered? | No | Yes | No | # How Amazon Route 53 uses EDNS0 to estimate the location of a user To improve the accuracy of geolocation, geoproximity, IP-based, and latency routing, Amazon Route 53 supports the edns-client-subnet extension of EDNS0. (EDNS0 adds several optional extensions to the DNS protocol.) 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, 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 Route 53 a truncated version of the user's IP address. 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. Route 53 then responds to geolocation queries with the DNS record for the user's location. + EDNS0 is not applicable to private hosted zones. For private hosted zones Route 53 uses data from the VPC Resolvers in the AWS Region that the private hosted zone is in to make geolocation and latency routing decisions. For more information about edns-client-subnet, see the EDNS Client Subnet RFC, [Client Subnet in DNS Requests](https://www.rfc-editor.org/rfc/rfc7871).