What Amazon Route 53 brings to the DNS table
Amazon Route 53 is a highly available and scalable Domain Name System (DNS) service offered by AWS. It is named by the TCP or UDP port 53, which is where DNS server requests are addressed. Like any DNS service, Route 53 handles domain registration and routes users’ internet requests to your application — whether it’s hosted on AWS or elsewhere.
But Route 53 also intelligently directs traffic based on sophisticated routing policies and — through automated health checks — away from servers that might be failing.
Like many AWS services, Route 53 is a pay-as-you-go service. You will be charged for the number of hosted zones you create and maintain and by the number of requests routed. In a previous post, we discussed some of the basics of how DNS works. Now we will explore the value that Route 53 can create for your domain needs and why and how you might want to migrate your domains over to Route 53.
To dive into Amazon Route 53, Cloud Academy’s Working with AWS’s Domain Name System: Amazon Route 53 is your go-to course. You’ll see that our Route 53 course is part of a larger Learning Path covering AWS Networking & Content Delivery. This includes more pieces to the puzzle, such as Hands-on Labs walking you through creation of a CloudFront Content Delivery Network (CDN).
Why you should consider migrating to Amazon Route 53
Route 53 offers powerful policies to allow for efficient DNS requests. Once you’ve got your domain up and running, you can choose a routing policy that best fits your needs. To get the most out of the service, however, you’ll need to properly understand the function of each policy type.
Simple routing policy
This is the most common and, as the name suggests, simplest routing type. If, say, your application server has a public IP address of 205.251.242.103, and you’d like to use the human-readable address of amazon.com (assuming it’s available, of course), then you would use Amazon Route 53 to map amazon.com to your IP. From then on, any browser requests for amazon.com would be directed to 205.251.242.103.
Weighted routing policy
By assigning different numeric weights (or “priorities”) to multiple servers providing a web service, you can direct a higher or lower percentage of your incoming traffic to one particular server over another. This kind of routing can be useful for load balancing and testing new versions of a software package.
Latency-based routing policy
A latency-based policy directs traffic requests to the server that will be able to respond with the lowest possible latency (delay). You could, for instance, run your application in multiple AWS regions, and Route 53 will automatically route users to those that will deliver the quickest.
Failover routing policy
A failover policy will send all traffic to the server you set as primary for as long as that server is still healthy. If, however, health checks determine that it’s failing, traffic will be diverted to a designated backup resource.
Geolocation routing policy
This policy lets you designate resource targets based on your users’ geographic location. So, for example, you might want all queries from India to be routed to a server located in the same physical region in order to limit latency.
Important features
Domain registration. You can purchase domains from all top-level domains (.com, .net, .org, etc.) directly from Route 53, avoiding the need to migrate altogether. Route 53 also provides privacy protection for your WHOIS record at no extra charge.
Private DNS. Private DNS records let you create private hosted zones and route traffic using easily managed domain names within your VPCs. This can, for instance, allow you to quickly switch between IP-based resources without the need to update multiple embedded links.
Health check. Route 53 monitors the health of your application and, when an outage is detected, redirects users to a healthy resource.
AWS service integration. Route 53 is tightly integrated with Elastic Load Balancing (ELB), CloudFront, and S3. You can easily route traffic to an ELB CNAME record, a static website hosted on S3, or generate custom domains for your CloudFront URLs.
Alias records. Instead of an IP address, an alias resource record can, for instance, point directly to a CloudFront distribution, ELB load balancer, or Amazon S3 bucket. This way, even if the IP addresses of the underlying resources should change, traffic will still be sent to the correct endpoint.
Migration options
-
Leave your domain name with your own registrar
If you would like to use Route 53’s routing features, but have no need to move your domain name from its current registrar, you simply need to give your registrar the new name server addresses you’ll get from Route 53 upon creating a hosted zone. Once you have updated your name servers with your own providers, Route 53 will ensure the routing of all new domain requests through its own name servers.
-
Migrate your domain name
When you decide to migrate, you will need to get the DNS record data from your DNS provider. You will then import this data to a Route 53 hosted zone, and replace the registrar’s name server records with AWS name servers that you get by clicking on “GethostedZone.” Depending on your TTL settings, changes will take place within 24 to 48 hours.
Route 53 resolver for hybrid clouds
In late 2018, Amazon released an expanded version of its resolver, but in a position to help solve DNS issues in hybrid cloud environments.
The typical hybrid cloud DNS setup
Normally in a hybrid situation, you use a managed VPN or AWS Direct Connect to merge your private data center to one of your Amazon VPCs. The problem that occurs is that when customers go to perform a lookup across this pre-established connection (i.e., your private cloud to your VPC is AWS) the connection is not able to happen.
So what do people do in this situation? One thing they can do is take an on-premises DNS server and manually re-route a request to another server in an Amazon VPC. Customers might have to put their own custom DNS server in every VPC. Sounds like a lot of work, doesn’t it?
How Route 53 Resolver helps
Route 53 Resolver for Hybrid Clouds (or .2 as it used to be called) is included in the main Route 53 service offering and helps you by acting as a resolver for DNS requests between your private cloud and the entities in your VPC. It can perform both inbound communication (from an on-premises location to your VPC) and outbound (from your VPC back out to your data center).
In addition, the Resolver for Hybrid Clouds lets you use a single endpoint for multiple VPCs within a single region. Simplification is good.
Other advantages
Ok, so you’re interested in leveraging Route 53’s strengths and migrating your DNS needs to it. How else can Route 53 help?
- Security — Route 53 can use the benefits of AWS Identity Access Management (IAM) to limit the who can access your VPC and what they can access. AWS IAM allows the user control access to web services and resources securely for your users. IAM allows for the creation and management of AWS users/groups, and the assignment of permissions to allow/deny access to AWS resources.
- Reliability — As the policies above show, Route 53 is designed to help your system stay running, thanks to everything from latency-based to geographically-based policies. Being an AWS-native service, it’s in a good position to play nicely with all the other AWS services in your deployment.
- Cost savings — Route 53 provides an efficient way to redirect website requests without extra hardware, and doesn’t charge for queries to certain AWS resources such as S3 buckets, ELBs, VPC endpoints, or CloudFront distributions.
- Service level agreement — Route 53 provides service credits if the monthly uptime percentage fails to meet the service commitment in any billing cycle.
- Time to propagate — Route 53 is designed to distribute DNS record updates to a network of DNS servers in approximately 60 seconds under typical work conditions.
For more insight into Amazon’s DNS service, check out Cloud Academy’s Route 53 course. You’ll learn all the details of how this service works and how to quickly set it up as part of the standard process in your AWS VPC toolbox.
