Route 53 Introduction
The course is part of these learning paths
Amazon's Route 53 provides three services: record creation (which registers the human-readable names you'd like associated with your web domains), request handling (to direct web traffic to the right servers), and health checks (to ensure that traffic isn't being directed to servers that can't handle the load).
Very few web-facing AWS deployments can really be considered complete without applying the tools Route 53 makes available, so cloud expert David Robinson will guide you through some of the more common - and useful - domain-related tasks, including:
If you'd rather focus on AWS cloud computing basics, try our AWS introductory courses.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
This lesson will cover how you can ensure high availability of your DNS, which is a critical component in your architecture and how AWS assists with the use of health checking. We have configured health checks in previous lessons to configure failover in active-active, active-pass and mixed configurations for availability of our application. In this lesson, we are going to cover in detail how DNS evaluates the health of the resources and responds to requests in both the simple and complex configuration. Simple Configuration.
Regardless of the configuration, we must first create a group of resource record sets that have the same name and type. And for the purpose of this, we will work on A type records for website www.cloudacademylabs1.com. We have a Route 53 hosted zone and a weighted resource record with health check. When Route 53 receives a query for www.cloudacademylabs1.com, it shows the resource record set based on the policy, in this case both weight and healthy, and responds with the selected resource record set. In the next image, one of the instances is unhealthy. In this case, when Route 53 receives a query for www.cloudacademylabs1.com, it will choose the resource record set based on the policy. And if it selected the unhealthy resource first, once it determines that this is unhealthy, it will back up and then recalculate the routing policy and select the next record, which is a healthy resource and then respond with the selected resource record set. So we've seen what happens when there's an unhealthy instance. But what happens if all the instances are reporting as unhealthy? In this case, to prevent No DNS answer or returning an NXDOMAIN response, Route 53 will revert to considering all resource record sets healthy as this is a better alternative as the application may be responsive to users and is failing the health checks either due to a misconfiguration or even just an intermittent error. Also, if you don't specify a health check, all instances are assumed to be healthy, which will have an impact on how the decision tree responds. And this becomes more important when we start looking at complex configurations. Complex configuration. In a complex configuration, the process of health checks works much the same as in a simple configuration like we previously discussed. The major difference is that we are using a combination of alias resource record sets, such as latency alias and non-alias resource record sets to build a decision tree that provides greater control over how Route 53 will respond to requests. In our example in the image, if Route 53 receives a query for www.cloudacademylabs1.com and based on the routing policy, it determines that the user making the request is subject to the geolocation policy. And as the value for evaluate target health is set to yes, it checks on the health of selected resource record sets. As the health check is healthy, it passes and the response is provided to the user. Following on from the above example, if the health check failed as you can see in the image, Route 53 will back out of that branch and will then follow the default for geolocation and will evaluate the latency alias resource record set with the best latency and will choose that resource record set provided it has a healthy instance and will return the applicable value to the response.
Now that you understand how Route 53 uses health checks as part of the determination process for responding to queries, let us go and configure a health check and explore the options in more detail. To create a health check from the Route 53 dashboard, select health checks and then click the blue create health check button. From here, we will enter a name for the health check and then select the protocol that the health check will use.
The options for the protocol are HTTP, HTTPS or TCP. If you select either HTTP or HTTPS, Route 53 will attempt to establish a connection and waits for an HTTP status code of 200 or greater and less than 400.
It must establish a connection within four seconds and then return the status code within two seconds after the initial connection to be considered healthy. If you select TCP, Route 53 will attempt to establish a connection with the end point within 10 seconds. After you have selected the protocol, you specify the end point by either domain name or IP address. A key point to call out here is that if you specify by domain name, this will query DNS record set. And if you want to check on the hosts, it is recommended that you specify the domain name for each of the hosts. For example, US-west-1-www.cloudacademylabs1.com and not www.cloudacademylabs1.com. If you selected HTTP or HTTPS, you can also specify a path to check. And this can be any end point that will return a HTTP response code and there's no need to add the trailing forward slash as this is added by AWS.
Next we specify the request interval, which has a default value of 30 seconds or you can set it to fast, which is 10 seconds. This value specifies the interval between receiving the response and when sending out the next query and the failure threshold is the number of times that it fails a health check before the end point is classified as unhealthy. After we have configured the interval and threshold, we can specify if we want to configure string matching. And if we do, we can specify a search string of up to 255 characters. An important point to note is that when Route 53 is determining the health of the end point, it will search for the specified string in the response body and the value that you have specified must be contained in its entirety within the first 5,120 bytes of the response body. Otherwise, it will be marked as unhealthy. Finally, you have the option to associate this with a Cloud Watch alarm, which will send you notifications when the state of the end point changes to unhealthy. To create the health check, click the blue create button in the bottom right hand corner. To delete a health check, it's a very simple process in that you go to the health check dashboard, select the health checks and then delete health check. As simple as this is, be very careful as AWS doesn't prevent you from doing this, even if the health checks are associated with your resource record sets. If you delete a health check that is in use, this will have a direct impact on DNS queries and your failover configuration, which could result in undesirable consequences.
If you need to delete a health check, you need to ensure that it's not being used by reviewing your resource record sets for each hosted zone or programmatically by running the get list resource record sets API action on each hosted zone and reviewing the responses.
During this lesson, we have discussed what is Route 53 and then we configured a domain, set up a public and private hosted zone for our domain, resource record sets and routing policies to address our high availability needs. This course has provided you with a good understanding of DNS in AWS and the necessary skills you need to go and deploy AWS Route 53 within your own environment.
David's acknowledged hands on experience in the IT industry has seen him speak at international conferences, operate in presales environments and conduct actual design and delivery services.
David also has extensive experience in delivery operations. David has worked in the financial, mining, state government, federal government and public sectors across Asia Pacific and the US