Amazon Route53

DNS Basic

The record type you enter in a zone file’s resource record will determine how the record’s data is formatted and how it should be used. There are currently around 40 types in active use. Here is some common DNS record types:

An ALIAS record generally maps a name onto an AWS resource.

You can use ALIAS records to route traffic to a resource — such as an elastic load balancer - without specifying its IP address. Although the use of alias records has not yet been standardized across providers, Route 53 makes them available within record sets, allowing you to connect directly with network-facing resources running on AWS.

Amazon Route53

With those DNS basics out of the way, it’s time to turn our attention back to AWS. Route 53 provides more than just basic DNS services. In fact, it focuses on four distinct areas:

• Domain registration
• DNS management
• Availability monitoring (health checks)
• Traffic management (routing policies)

Route 53 now also provides an Application Recovery Controller through which you can configure recovery groups, readiness checks, and routing control.

In case you’re curious, the “53” in Route 53 reflects the fact that DNS traffic uses TCP or UDP port 53.

1. A user opens a web browser, enters www.example.com in the address bar, and presses Enter.

2. The request for www.example.com is routed to a DNS resolver, which is typically managed by the user's internet service provider (ISP), such as a cable internet provider, a DSL broadband provider, or a corporate network.

3. The DNS resolver for the ISP forwards the request for www.example.com to a DNS root name server.

4. The DNS resolver forwards the request for www.example.com again, this time to one of the TLD name servers for .com domains. The name server for .com domains responds to the request with the names of the four Route 53 name servers that are associated with the example.com domain.
   The DNS resolver caches (stores) the four Route 53 name servers. The next time someone browses to example.com, the resolver skips steps 3 and 4 because it already has the name servers for example.com. The name servers are typically cached for two days.

5. The DNS resolver chooses a Route 53 name server and forwards the request for www.example.com to that name server.

6. The Route 53 name server looks in the example.com hosted zone for the www.example.com record, gets the associated value, such as the IP address for a web server, 192.0.2.44, and returns the IP address to the DNS resolver.

7. The DNS resolver finally has the IP address that the user needs. The resolver returns that value to the web browser.

   The DNS resolver also caches the IP address for example.com for an amount of time that you specify so that it can respond more quickly the next time someone browses to example.com. For more information, see time to live (TTL).

8. The web browser sends a request for www.example.com to the IP address that it got from the DNS resolver. This is where your content is, for example, a web server running on an Amazon EC2 instance or an Amazon S3 bucket that's configured as a website endpoint.

9. The web server or other resource at 192.0.2.44 returns the web page for www.example.com to the web browser, and the web browser displays the page.

In Route 53, AWS assigns four name servers for all domains, as shown in the screenshot: one for .com, one for .net, one for .co.uk, and one for .org. Why? For higher availability! If there is an issue with the .net DNS services, the other three continue to provide high availability for your domains.

Amazon Route 53 health checks

1. You create a health check and specify values that define how you want the health check to work, such as the following:

   • The IP address or domain name of the endpoint, such as a web server, that you want Route 53 to monitor. (You can also monitor the status of other health checks, or the state of a CloudWatch alarm.)
   • The protocol that you want Amazon Route 53 to use to perform the check: HTTP, HTTPS, or TCP.
   • How often you want Route 53 to send a request to the endpoint. This is the request interval.
   • How many consecutive times the endpoint must fail to respond to requests before Route 53 considers it unhealthy. This is the failure threshold.
   • Optionally, how you want to be notified when Route 53 detects that the endpoint is unhealthy. When you configure notification, Route 53 automatically sets a CloudWatch alarm. CloudWatch uses Amazon SNS to notify users that an endpoint is unhealthy.

2. Route 53 starts to send requests to the endpoint at the interval that you specified in the health check.

   • If the endpoint responds to the requests, Route 53 considers the endpoint to be healthy and takes no action.

3. If the endpoint doesn't respond to a request, Route 53 starts to count the number of consecutive requests that the endpoint doesn't respond to:

   • If the count reaches the value that you specified for the failure threshold, Route 53 considers the endpoint unhealthy.
   • If the endpoint starts to respond again before the count reaches the failure threshold, Route 53 resets the count to 0, and CloudWatch doesn't contact you.

4. If Route 53 considers the endpoint unhealthy and if you configured notification for the health check, Route 53 notifies CloudWatch.

   • If you didn't configure notification, you can still see the status of your Route 53 health checks in the Route 53 console. For more information, see Monitoring health check status and getting notifications.

5. If you configured notification for the health check, CloudWatch triggers an alarm and uses Amazon SNS to send notification to the specified recipients.

Public and private hosted zones

Route 53 supports both public **and private **hosted zones. Public hosted zones have a route to internet-facing resources and resolve from the internet using global routing policies. Meanwhile, private hosted zones have a route to VPC resources and resolve from inside the VPC. It helps to integrate with on-premises private zones using forwarding rules and endpoints.

• Working with public hosted zones

• Working with private hosted zones

Routing policy

Route 53 provides the following seven types of routing policies for traffic:

• Simple routing policy – This is used for a single resource (for example, a web server cre- ated for the www.example.com website). The limitation of simple routing is that it doesn’t support health checks. There are no checks that the resource being pointed out by the record is actually operational.

• Failover routing policy – This is used to configure active-passive failover. A failover routing policy will direct traffic to the resource you identify as primary as long as health checks confirm that the resource is running properly. Should the primary resource go offline, subsequent traffic will be sent to the resource defined within a second record set and designated as secondary. As with other policies, the desired relationship between record sets is established by using matching set ID values for each set.

• Geoproximity routing policy – This is used for geolocation when users are shifting from one location to another. 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.

• Latency routing policy – This optimizes the best latency for the resources deployed in multiple AWS Regions. Latency- based routing lets you leverage resources running in multiple AWS regions to provide service to clients from the instances that will deliver the best experience. Practically this means that, for an application used by clients in both Asia and Europe, you could place parallel resources in, say, the ap-southeast-1 and eu-west-1 regions. You then create a record set for each resource using latency- based policies in Route 53, with one pointing to your ap-southeast-1 resource and the other to eu-west-1. Assuming you gave both record sets the same value for Set ID, Route 53 will know to direct requests for those resources to the instance that will provide the lowest latency for each client.

• Geolocation routing policy – This routes traffic based on the user’s location. Unlike latency policies that route traffic to answer data requests as quickly as possible, geolocation uses the continent, country, or U.S. state where the request originated to decide what resource to send. This can help you focus your content delivery, allowing you to deliver web pages in customer-appropriate languages, restrict content to regions where it’s legally permitted, or generate parallel sales campaigns. You should be aware that Route 53 will sometimes fail to identify the origin of a requesting IP address (particularly when the requests come from VPN users). You might want to configure a default record to cover those cases.

• Multivalue answer routing policy – This is used to respond to DNS queries with up to eight healthy, randomly selected records. It’s possible to combine a health check configuration with multivalue routing to make a deployment more highly available. Each multivalue-based record set points to a single resource and can be associated with a health check. As many as 8 records can be pointed to parallel resources and connected to one another through matching set ID values. Route 53 will use the health checks to monitor resource status and randomly route traffic among the healthy resources.

It’s not a substitute for a load balancer, which handles the actual connection process from a network perspective. But the ability to return multiple heal checkable IP addresses is a way to use DNS to improve availability of an application.

• Weighted routing policy – This is used to route traffic to multiple resource properties as defined by you (for example, you want to say 80% traffic to site A and 20% to site B). A weighted policy will route traffic among multiple resources according to the ratio you set. To explain that better, imagine you have three servers (or load balancers representing three groups of servers), all hosting instances of the same web application. One of the servers (or server groups) has greater unused compute and memory capacity and can therefore handle far more traffic. It would be inefficient to send equal numbers of users to each of the servers. Instead, you can assign the larger server a numeric weight of, say, 50 and then 25 to the other two. That would result in half of all requests being sent to the larger server and 25 percent to each of the others. To configure a weighted policy in Route 53, you create a separate record set for each of your servers, give the same value for the set ID of each of the record sets, and then enter an instance- appropriate numeric value for the weight. The matching set IDs tell Route 53 that those record sets are meant to work together.

• IP-based routing - With IP-based routing, you can create a series of Classless Inter-Domain Routing (CIDR) blocks that represent the client IP network range and associate these CIDR blocks with locations. 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.

Route 53 Traffic Flow

https://aws.amazon.com/blogs/aws/new-route-53-traffic-flow/

Route 53 Traffic Flow is a console-based graphical interface that allows you to visualize complex combinations of routing policies as you build them.

Because it integrates routing policies with all the possible resource endpoints associated with your AWS account, Traffic Flow can make it simple to quickly build a sophisticated routing structure. You can also use and customize routing templates.
Traffic Flow offers geoproximity routing, which gives you the precision of geolocation routing but at a far finer level. Geoproximity routing rules can specify geographic areas by their relationship either to a particular longitude and latitude or to an AWS region. In both cases, setting a bias score will define how widely beyond your endpoint you want to apply your rule.

Route 53 Resolver

You can now extend Route 53’s powerful routing tools across your hybrid infrastructure using Route 53 Resolver. Resolver can manage bidirectional address queries between servers running in your AWS account and on- premises resources. This can greatly simplify workloads that are meant to seamlessly span private and public platforms.