Amazon Route 53 is a scalable and highly available DNS service that translates human readable website names like www.hava.io into the numeric IP address location of the target website host (13.35.145.107) or a private VPC or application endpoint.
Route 53 also performs health checks on the connections to ensure the resources you are connecting to are available. If a problem occurs you can instruct route 53 to notify you and also route traffic away from the dead resource to an alternate endpoint.
Route 53 is built on high availability AWS infrastructure and leverages a global network of Anycast DNS servers that automatically route user traffic to the optimal location for them. This ensures low query latency for end users and faster updates of DNS records when you make changes.
The service is able to scale in response to large query volumes automatically, so you do not need to worry about the management of high volume events.
Route 53 instances are visualised on the AWS diagrams automatically generated by hava.io
One of the major benefits of using Route 53 when you are building websites and applications on AWS infrastructure is the native integration of Route 53 with other AWS services. You can for instance map a route 53 domain name directly to an EC2 instance, an elastic load balancer, an S3 bucket, a cloudfront distribution just to name a few. You can also integrate IAM to restrict access to specific parts of Route 53.
While you would typically use the AWS console to create and configure DNS settings to have a domain connection up and running in minutes, you can also use the Route 53 API to programmatically integrate Route 53 actions, like creating a new DNS record when an EC2 instance is provisioned.
Routing policies can be created to configure DNS routing behaviours. For example a geolocation policy can route traffic to different endpoints based on user location, or a weighted routing policy can route traffic to multiple endpoints or resources based on the criteria specified.
Route 53 provides a domain registration service. You can search for available domain names and purchase/register them via Route 53. Just like other domain registrars, you can transfer domains you already own into Route 53 and also transfer them out to another registrar.
As part of the domain establishment, Route 53 provides a managed DNS hosting service that creates hosted zones for domains. This is the authoritative name server for the zone and hosts the zone records, cnames and aliases.
Route 53 has in-built health checks ensuring that traffic is only routed to healthy endpoints. These endpoints are reached via the Route53 Resolver which is built in to AWS VPC so you don’t need to include custom DNS servers within the VPC and also resolves DNS queries for internet routable domains and private hosted zone domains.
Route 53 Hosted Zones
A hosted zone is a collection of DNS information. These records describe how you want to route traffic for the nominated domain and it’s subdomains.
A hosted zone has the same name as the primary domain and can be either a public or private hosted zone.
A public hosted zone describes how you want to route traffic for the domain in the public internet while a private hosted zone defines how you want to route traffic in a private AWS VPC.
How to create a Route 53 Public Hosted Zone.
To create a public hosted zone, open up the Route 53 dashboard from your AWS management console which can be found in the Network & Content Delivery section.
You can then enter the domain name which becomes the name of the hosted zone and select the type as public hosted zone.
Once created you can then add additional A records, cname and other records for aliases and subdomains.
How to create a Route 53 Private Hosted Zone
Creating a private zone starts in the same place however when you select the private hosted zone radio button, a new dialogue appears where you can select the VPC or VPC’s you want to route traffic to when someone enters the domain url.
When connecting to a VPC you need to set the VPC properties enableDnsHostnames and enableDnsSupport to true.
A typical use case would be providing access to a within one of your EC2 instances. You could create an A record for a subdomain called db.mydomain.com which points to the IP address of the database server. Other applications that exist within the VPCs associated with the primary domain would then be able to use db.mydomain.com to access the database.
Private Hosted Zones use the Route 53 resolver to route traffic using the second CIDR Ip address associated with a VPC. Any resource within a VPC can resolve public and private domain names.
When you create a private hosted zone, the routing policies are limited to Simple, Failover, Weighted and multi-value answer records. Health checks are only supported for Failover, Multi-value answer and Weighted record types.
Split view or split horizon DNS can be created with Route 53 where duplicate public and private zones are created with the same Domain and sub domains. This provides different internal and external IP addresses for the same domain, website or application.
Alias records can be used to route traffic to AWS resources. You could for instance point an alias to an elastic load balancer. The advantage of the native integration is that if the ELB changes IP addresses for some reason, Route 53 will automatically respond to DNS queries using the new IP address.
Route 53 Health Checks
You can set up health checks to monitor endpoints such as IP address or domain name. When a health check fails, you can nominate how and who to notify about the health check failure.
You can also set up calculated health checks where combinations of existing health checks can be tested before failure notification. You could test whether check 1 OR check 2 has failed, so if either fails, you get notified. Or you could test whether check 1 AND check 2 have failed, so that both health checks must fail before you are notified.
Cloudwatch alarms can also be used as the basis to trigger a Route 53 Health check. Say for instance your DNS set up is pointing to an elastic load balancer. If you have cloudwatch monitoring the number of healthy resources attached to the ELB and the number drops below an acceptable level, the cloudwatch status can be used to trigger the Route53 health check failure and subsequent notification.
Route 53 Routing Policies
When you create a record there are a number of policy types you can choose to apply that tells Route 53 how to respond to DNS queries.
Simple Routing Policy
This is used for a single resource like a web server. There is no special routing activity with the simple policy, all traffic is delivered to the specified endpoint.
Failover Routing
This policy will route traffic to a healthy resource, but will swap out to a nominated alternative endpoint should the primary resource become unavailable or unhealthy. The alternate resource could be as simple as a static website stored in S3 through to a nested chain of alternate EC2 or other endpoints.
Geolocation Routing
When you want to tailor your content to a geographic location, or restrict content to specific locations you can use geolocation routing to achieve this. You can specify particular continents, countries or by state and send the traffic to different endpoints that could contain different language or currency content, content appropriate for that location.
Geo routing is also a useful method of load balancing website traffic over a wider area.
Geoproximity Routing
This lets you route traffic using Route53 traffic flow. Using either AWS region or latitude/longitude you can send traffic to the nearest resource endpoint for better latency or content localization.
Latency-based Routing
If your application is hosted in multiple AWS Regions, you can improve performance for your users by serving requests from the AWS Region that provides the lowest latency.
To use latency-based routing, you create latency records for your resources that are located in multiple AWS Regions. When Route 53 receives a query for your domain or subdomain it determines which AWS Regions you've created latency records for, determines which region gives the user the lowest latency based on their location, 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.
Multi-Value Answer Routing
With this policy you provide a number of values, like IP addresses for web servers to be used in response to DNS queries. Route 53 will then test whether the provided endpoint is healthy, so it always has a pool of healthy resource to share traffic amongst to improve latency, availability and a form of simple load balancing.
Weighted Routing
This policy allows you to define multiple endpoints associated with the same domain name endpoint. It then allows you to specify what percentage of traffic is routed to each endpoint. This can be used for load balancing, but is also useful when testing new software or UI versions for a small cohort of users.
So that's a quick run through Amazon Route 53 and what it's used for.
If you are building on AWS or GCP and Azure for that matter, you already know the value of an accurate network topology diagram. Hava automatically generates network infrastructure and security diagrams by simply connection your cloud account to Hava. Once connected, Hava will detect changes in your cloud configuration then generate new diagrams and store the superseded diagrams in version history.
If you are not yet enjoying hands-free accurate AWS architecture diagrams, we invite you to check out Hava. There's a 14 day free trial, no credit card required. Find out more using the button below.
