Getting started with Route53 is a very simple and straightforward process. From the AWS Management Console, select the Route53 option from the Networking group, as shown here:

This will bring up the Route53 Management Console for the first time. Using this console, you can create and configure your very own custom domain names as well as configure health checks and traffic routing policies as per your requirements. First up, let's go ahead and create a simple hosted zone for our demo application all-about-dogs.com.

A hosted zone is nothing more than a logical container that holds information on how you wish to route traffic for your application. You create a hosted zone for your custom domain (all-about-dogs.com) and then create one or more resource record sets to tell the DNS service how you want traffic to be routed for that domain. If your Hosted Zone routes traffic over the Internet, then it is called a public hosted zone, and conversely if you are routing within an Amazon VPC, it is called a private hosted zone. Once your hosted zone is created, Route 53 will automatically create a Name Server (NS) record and a Start Of Authority (SOA) record for that zone. The NS record identifies the four name servers that Route53 creates for you. You can then provide these four NS records to a registrar or your DNS service provider, such as https://in.godaddy.com/, so that your application's DNS queries are routed to Amazon Route53's name servers.

Here is a pictorial representation of how things actually work out. In this case, our demo application's domain name is already registered with http://www.godaddy.com/; however, you can alternatively use any other domain provider of your choice, or Route53's newly launched domain registrar service as well:

To create your very own hosted zone, select the Create Hosted Zone option from the Route53 dashboard. This will bring up the Create Hosted Zone panel, as shown in the following screenshot. Provide a suitable Domain Name (in this case, I have provided our demo application's name all-about-dogs.com) and an optional Comment as well. Next, from the Type drop-down menu, select the option Public Hosted Zone, as shown. Click on Create once all the required fields are filled in:

You should get two record sets created as shown. The first record set is your hosted zone's NS record set that contains the four name servers, and the second record set is the SOA record set. Each new hosted zone that you create will contain its own unique NS and SOA record sets:

Once your hosted zone is created, the next step is where you create a new resource record set. A resource record set basically tells the DNS how the traffic should be routed for that particular domain. For example, you may want to route all Internet traffic for your domain name all-about-dogs.com to a specific IP address of an instance or an ELB, or you may even want all your e-mails to be routed to a specific mail server with the domain name mail.all-about-dogs.com and so on.

Each resource record set that you create will include the name of your domain, a record type, and other miscellaneous information applicable to that particular record type, such as Time To Live (TTL), routing policies, and health checks. Here are some of the commonly used record set types provided by Route53:

To create your own record set, simply select the Create Record Set option from the hosted zone dashboard. This will bring up the Create Record Set panel as shown in the following screenshot. Now in my case, I want to route all of my incoming application traffic on the ELB, which is hosted in us-west-2, via a domain name of www.all-about-dogs.com. In this case, I provided the value www in the record set Name field. Alternatively, you can provide any meaningful value there as per your requirements. Next, from the Type drop-down menu, select the CNAME - Canonical Name option. We will be using CNAME because the ELB is provided by a default DNS name, which you can obtain by selecting your ELB from the EC2 Management Dashboard and noting down its DNS name, which is generally of the following format: US-WEST-PROD-LB-01-1582564436.us-west-2.elb.amazonaws.com. Once done, paste the ELB's DNS name in the Value field. You can optionally edit the TTL (seconds) value; however, I have chosen to stick with the default of 300 seconds.

Next, select an appropriate routing policy based on your requirements. There are five routing policies provided, using which you can decide the best mechanism to route your queries to Route53. They are as follows:

Coming back to our record set, for this particular scenario I opted to go for the latency-based routing for my application. Select the Latency option from the Routing Policy drop-down list. This will provide you with an option to select an associated region to route your traffic to. In this case, I selected the us-west-2 region where my ELB is currently present. The final step is to provide a meaningful and unique Set ID or description for this particular record set. Once done, complete the record set creation process by selecting the Create option, as shown:

Once your record set is created, it will be displayed along the NS and the SOA records that were created by Route53 when the hosted zone was first deployed. You can create additional record sets for your hosted zone using the same steps as mentioned.

It's all ok to create individual record sets using the previously described method, but what if you had multiple resources present across multiple locations and each resource required a different routing policy and configuration? This can become a real pain point when you look at it from a management point of view and that is precisely the reason why AWS recently launched an interactive visual tool called traffic flow.

Traffic flow basically provides you with an easy to use interface using which you can create and manage complex traffic policies, all within a fraction of the time. Using the tool is a fairly simple and straightforward process. You start off by creating one or more traffic policies, each containing multiple routing and configuration options in the form of policy records. You can even create multiple versions of the same traffic policy and use different versions to roll out or roll back configuration changes as you see fit.

To create your first traffic policy, select the Traffic policies option from the Route53 Management dashboard. Next, select the Create traffic policy option to get started. Provide a suitable Policy name and Version description as required. Click on Next to continue. This will bring up the Create traffic policy page where you can use the Start Point and the Connect to options to create child rules and endpoints. To delete any child rule, simply select close (marked by x) in the upper-right corner of each rule box.

The Start Point actually is where you choose the DNS type that you want Route 53 to assign to all of the resource record sets. Use the following DNS types if you wish to route traffic to the following AWS resources:

Once you have defined the Start Point value, you can use the Connect to option to select an applicable rule or endpoint based on the design for your configuration. The rules can be anything from Weighted rules to Failover, Geolocation, and even Latency-based rules. Once done, click on the Create traffic policy option to complete the traffic policy's creation:

Do note that once your traffic policy is created, each edit of it will end up creating a new version of it. The previous versions of the policy are retained unless you choose to delete them explicitly. You can even create a new Traffic policy by importing a JSON-based document that describes all of the endpoints and rules that you want to include in the policy. To know more about traffic policy document format and how you can use them for your own scenarios, go to http://docs.aws.amazon.com/Route53/latest/APIReference/api-policies-traffic-policy-document-format.html.

Route53 also provides a mechanism using which you can effectively monitor the health and performance of your web application as well as other resources using the health check facility provided. Health checks can be configured to periodically monitor the health of your application in a very similar way that ELB does. All you need to do is provide your application's URL or endpoint and configure the notification alarm. That's it! The rest is completely taken care of by Route53.

To create your very own health check, select the Health checks option from the Route53 dashboard. Next, click on the Create health check option to get started. This will bring up the Configure health check page. The first thing you need to do is provide a suitable name for your health check using the Name field. Next, select for what you wish to configure this health check. There are two options available: you can either monitor an Endpoint, such as an instance or an ELB or even your application's endpoint, or you can select to monitor the Status of other health checks as well:

For this example, I opted to go for Endpoint monitoring. Next, configure the details to monitor your endpoint in the Monitor an endpoint section. Here, too, you have the flexibility to select between having an IP address or a Domain name as an endpoint.

From the Protocol drop-down list, select the appropriate protocol you want Route53 to use to check the health of your endpoint. Currently, the valid values provided are HTTP, HTTPS and TCP. For this particular scenario, I opted for the HTTP protocol as shown. In this case, Route 53 will try to establish a connection with the application using the HTTP protocol. If the connection is successful, Route 53 will submit an HTTP request and wait for an HTTP response in the form of a status code of 200 or greater but less than 400.

In the Domain name field, provide the domain name of the endpoint that you wish Route53 to monitor and also provide the Port on which Route53 will communicate. By default, port 80 is selected for your HTTP protocol and so port 443 is selected, in case you have selected HTTPS as the protocol. The final field left now is the Path field, which specifies the path that you wish Route53 to request when performing health checks. Do note that this field is only valid for HTTP and HTTPS protocols. If no value is provided here, then Route53 will automatically start requesting the Domain name itself:

Once done, you can optionally edit the Request Interval and Failure threshold levels from the Advanced configuration section, as shown in the following screenshot. Do remember that changing the request interval from Standard (30 seconds) to Fast (10 seconds) results in an additional payment. To know more about how Route53 is priced, check http://aws.amazon.com/route53/pricing/#Health_Checks:

With these settings configured, you can now proceed to the final step of the configuration where you can create or reuse an SNS notification to notify you in case a health check fails. Click on Next to continue with the health check creation process.

You can specify health checks to provide you with SNS notifications using the final configuration page as shown here. Select Yes to create an alarm and choose either Existing SNS topic or New SNS topic to send notifications to. Once you are happy with your settings, click on Create health check to complete the process:

Health checks also help you to design and configure DNS failover scenarios. For example, if your web application is running ten EC2 instances in the backend, five present in one region and the other five in another, then you can configure Route53 to check the health of those instances and respond only to the servers that are healthy. Using this mechanism, you can configure active-active or even active-passive failover scenarios and maintain the uptime of your applications. For a complete overview and guidance on how you can leverage DNS failover for your applications, refer to Route53's developer's guide: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html.