What are the Route53 policy

Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. It is designed to give developers and businesses an extremely reliable and cost effective way to route end users to Internet applications by translating names like www.example.com into the numeric IP addresses like 192.0.2.1 that computers use to connect to each other. Amazon Route 53 is fully compliant with IPv6 as well.

AWS also provide some policy for route 53. those policy are very help full for low-latency, fault-tolerant architectures.

Policies

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.

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.

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.

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 ELB 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.)

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.

Geoproximity routing (traffic flow only)

Geoproximity routing lets Amazon Route 53 route traffic to your resources based on the geographic location of your users and your resources. You can also optionally choose to route more traffic or less 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.

To use geoproximity routing, you must use Route 53 traffic flow. You create geoproximity rules for your resources and specify one of the following values for each rule:

1. If you’re using AWS resources, the AWS Region that you created the resource in
2. If you’re using non-AWS resources, the latitude and longitude of the resource

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:

1. 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.
2. 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.

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).

The following map shows what happens if you add a bias of +25 for the US East (Northern 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.

The following map shows what happens if you change the bias to -25 for the US East (Northern 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.

The effect of changing the bias for your resources depends on a number of factors, including the following:

1. The number of resources that you have.
2. How close the resources are to one another.
3. 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 (Northern Virginia) and US West (Oregon) and you have a lot of users in Dallas, Austin, and San Antonio, Texas, USA. Those cities are roughly 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 the other.

We recommend that you change the bias in small increments to prevent overwhelming your resources due to an unanticipated swing in traffic.

How Amazon Route 53 uses bias to route traffic

Here’s the formula that Amazon Route 53 uses to determine how to route traffic:

Positive bias

Biased distance = actual distance * [1 - (bias/100)]

Negative 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

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 ELB load balancers in the US West (Oregon) Region and in the Asia Pacific (Singapore) Region. You created 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.
2. Route 53 refers to its data on latency between London and the Singapore region and between London and the Oregon region.
3. 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 performed 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.

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:

1. 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.
2. If you don’t associate a health check with a multivalue answer record, Route 53 always considers the record to be healthy.
3. If you have eight or fewer healthy records, Route 53 responds to all DNS queries with all the healthy records.
4. When all records are unhealthy, Route 53 responds to DNS queries with up to eight unhealthy records.

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:

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+255)), and the other resource gets 255/256ths (255/(1+255)). 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.