The course is part of these learning pathsSee 2 more
Route 53 Introduction
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:
- Domain name management
- DNS failover
- Health checks
- Latency-based routing
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.
In the previous lesson, we registered a domain with Route 53 and now it's time to set up a public hosted zone that we can now respond to DNS queries for our domain.
Amazon Route 53 lets you configure DNS failover in active-active, active-passive or mixed configurations to improve the availability of your application when you have more than a single resource performing the same function, for example, a web server. This is achieved by configuring Route 53 to do health checks on the resources and to respond to DNS queries using only the healthy resources.
During this lesson, we will configure our environment to take full advantage of the high availability options that are available to us. Before we get started, let us cover our starting scenario, which is we are deploying two web servers in the ap-southeast-oneregion and we want to configure it so that if the primary fails, it will fail over to the secondary web server. The first thing that we need to do is to configure a public hosted zone for our newly registered domain, cloudacademylabs1.com from the AWS Management Console. When we create this, Route 53 will automatically create name server, NS records, and a start of authority, SOA record, for our newly created zone. As we purchase this domain, you will notice that AWS has already configured the hosted zone for us.
However, if we didn't purchase this domain through AWS, we would need to provide the four name servers records to our domain registrar or DNS service so that any DNS queries for this domain are routed to the Route 53 name servers. To create a public hosted zone, sign in to the AWS management console and open the Amazon Route 53 console. Click create hosted zone.
In the create hosted zone pane, enter a domain name and optionally a comment. Select public hosted zone in Type from the drop down menu. Click create. As we have created our public hosted zone, you will see from the console that we have name server, NS records, and start of authority, SOA records, created for our new hosted zone. So before we create the resource records for www.cloudacademylabs1.com, we need to set up DNS health checks. And as you will recall, we have two EC2 instances, running as web servers. And in the event of a failure, we want DNS requests to be routed to the healthy instance. We will cover health checks in more detail in a later lesson. But for now, from the Route 53 console, select health checks in the left side menu and then click on create health check. Enter the required values. And for the purpose of this lesson, it is the IP address of the EC2 instance. We will change the request interval to fast and then click create. We will create a second health check for the other instance as well. Now that we have configured the health checks, it's time to create the resource records for our website. From the Route 53 console, select hosted zones on the left hand menu and then select the domain from the main window. To create the resource records for our domain name, click create record set on the right side panel. You will see the "Create Record Set" frame. And from here, go to the name field and enter www. Ensure that the type is set to A. Change the TTO seconds to 60.
If you leave this as your default, when you go to associate it with a health check, it will recommend you change this value to ensure that the results aren't cached too long in the event of a failure.
In the value field under the IP address of the EC2 instance. Under routing policy, select failover from the drop down menu and select primary as the failover record type, and in the set ID, which is a unique, descriptive text of up to 128 characters. To differentiate this from other sets, we will leave the default text of www-primary and associate with healthy.
Select the radio button yes and then from the drop down menu, select the corresponding entry and click create to finish. We will now repeat this for the second instance, changing the IP address and selecting secondary as the failover record type. It's now time to test to see if it's working. Firstly, let's just use the IP addresses of each machine to see the landing pages. And as you can tell, we have a slightly different landing page for each of these. We will now open another browser window and navigate to the site by its DNS name, www.cloudacademylabs1.com and you will see the landing page we have created, which is on the primary server.
Now we will stop this instance from the AWS management console. And to be sure we will open another browser window so that there's no caching and you can now see, we now have been redirected to the secondary site.
About the Author
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