Amazon Route 53 is the AWS answer to a well-known, reliable, cost-effective service for managing and maintaining domains. Route 53 is an Amazon Web Service, a highly available and scalable cloud Domain Name System (DNS) that connects the internet traffic to the web servers hosting your Web application.
Route 53 lets developers and organizations route end users to their web applications in a very reliable and cost-effective manner.
Like a traditional Domain Name System (DNS), Route 53 translates domain names into IP addresses to direct global traffic to your website. Route 53 converts World Wide Web addresses like www.example.com
to IP addresses like 10.20.30.40
.
Why is it called Route 53?
In the name Route 53, "Route" is a likely reference to the U.S. Routes featuring the United States Numbered Highway System, often called U.S. Routes or U.S. Highways. The "53" is a possible reference to the TCP/UDP port 53 used for DNS server requests.
How does Route 53 work?
AWS Route 53 connects customer and service requests to your infrastructure running in AWS. These requests may originate from AWS ELB, Amazon EC2 instances, or Amazon S3 buckets. AWS Route 53 also routes users to your infrastructure outside of AWS.
With Route 53, you can also set up DNS health checks, continuously monitor your applications' ability to recover from failures, and control application recovery using Route 53 Application Recovery Controller service.
AWS Route 53 traffic flow helps you manage traffic globally via various routing types, including latency-based routing, geo DNS, weighted round-robin, and geo proximity. All Route 53 routing types can be easily combined with DNS Failover to enable various low-latency, fault-tolerant architectures.
Some of the features of Route 53 include;
If a web application requires a domain name, Route 53 service helps to register the name for the website (i.e., domain name).
You can register your custom domain name by purchasing one from AWS if the domain name is available or move your current domain name to AWS with Route 53.
Route 53 also works with other AWS services to automatically route the user to a healthy resource if any failure is detected at any level.
What is commonly mentioned with Route 53
Records
Records are created to route internet traffic to the resources. Records are usually objects in the hosted zone that determine how traffic is routed for a domain name for it to reach the resources. Each record entry in a hosted zone must end with the name of the hosted zone.
Hosted zone
It is a collection of records containing information about how to route traffic for all the domains and subdomains. When you register a domain name with Route 53, a public hosted zone with the same name as the domain name is also created.
DNS Recursor
A DNS recursor is responsible for receiving queries from the client machines and making additional requests to fulfill the DNS query. It is the librarian that finds the specific book you asked for, using a recursive search.
DNS query
A DNS query is the request for information about a resource, in this case, a webserver through its domain name, that is sent from a DNS client to a DNS server.
Alias records
In the AWS world, Alias records help route internet traffic to other AWS resources like an S3 Bucket or Amazon CloudFront. Alias records are usually created in the top node of the DNS namespace.
Name servers
A name server in the DNS resource pipeline translates domain names into IP addresses, allowing you to find the specific web server that matches your DNS query. It ensures that your request is routed to the correct resources.
DNS failover
DNS failover is a DNS routing method that routes traffic from an unhealthy resource to a healthy resource, usually a web server, whenever a resource failure is detected.
Routing policy; A Routing policy usually determines how Amazon Route 53 responds to queries.
DNS query
A request submitted by a computer or a smartphone to the Domain Name System (DNS) to connect to a resource associated with a domain name. When you search for amazon.com, you generate a DNS query for a web server that matches amazon.com to the DNS service.
Root Nameserver
It's the first step to converting human-readable hostnames like Amazon.com into IP addresses. Think of a Root nameserver as the library index used to find the location of a particular book on the shelves.
TLD Nameserver
Think of a top-level domain server (TLD) as a specific rack of books in a library. The TLD nameserver is the next step to discovering the specific IP address, and the last part of the hostname (for example, the TLD server is "com") is hosted in it.
Authoritative Name Server
An Authoritative Name Server is the final nameserver in terms of web search. Think of it like a dictionary on a rack of books that translates a specific name into its definition. The authoritative nameserver is the final step in the nameserver query.
Domain Registration
With a scalable DNS management service like Route 53, users can either transfer management of existing domains or register new domain names to AWS Route 53 and enjoy consolidated management and billing from one console.
Traffic Management
AWS Route 53 provides intelligent traffic routing based on parameters, including the health of endpoints, proximity, and latency, among many more.
Route 53 performs real-time Health Checks and Failover operations depending upon the specific configurations; Route 53 then directs internet traffic to a healthy target. The health-checking agents will route the traffic to healthy endpoints if any unhealthy endpoint is found.
The function of the health check feature is to generate CloudWatch metrics that trigger AWS Lambda functions to perform appropriate corrective actions.
DNS Routing Strategies
Simple routing policy
It is a simple Route 53 routing technique that can route internet traffic to a single resource. With simple routing, routing multiple records with the same name cannot be created, but multiple values ( such as multiple IP addresses ) can be specified in the same record. Simple routing is used for a single resource that performs a given function for a particular domain. It allows configuring DNS with no unique Route 53 Routing.
Failover routing policy
Whenever a resource goes unhealthy, this policy allows routing the traffic from an unhealthy resource to another or alternate resource. It uses an ELB (Elastic Load Balancing) setup with one resource in active mode and the other in standby mode. It switches automatically when there is a failover. One of the sites is active and serves all the traffic at a time, while the other Disaster Recover (DR) site remains in standby mode. The health of the primary site is monitored by Route 53 using the health check feature.
Geolocation routing policy
This routing policy routes the traffic to resources based on the user's geographic location. Geographic locations can be specified by continent, country, or state. It localizes the content or website in the language of the user. These are specified by continent or by country. The Geolocation Routing Policy routes the traffic as per the geographic location from where the DNS query originated. With the help of this policy, the traffic can be sent to resources in the same region from where the request originated.
Geo proximity routing policy
It routes traffic based on the user's geographical location and the type of content the user wants to access. The user can optionally shift traffic from resources at one location to resources at another location. Using this policy, a user can redirect more traffic to one location than another by specifying a value known as bias. The function of a bias is to expand or shrink the size of the geographic region from which traffic is routed to a resource. A Route 53 traffic flow must be used to use geo proximity routing.
Latency routing policy
Latency Routing is used when the resources are in multiple AWS Regions, and the traffic needs to be routed to the region that provides the best latency. A latency-based routing policy is used if your website has to be hosted in multiple regions, but users need extremely low latency when accessing your website. To use this policy, the resource latency records are created in multiple AWS regions.
Multivalue routing policy
It is used when users want Route 53 to return multiple values in response to DNS queries. It first checks the health of resources and then returns the multiple values only for the health resources.
Weighted routing policy
This routing policy routes traffic to multiple resources with a single domain name according to the proportion decided by the user. It routes multiple resources with a single domain name and controls the traffic routed to each resource. It is mainly useful for testing and load-balancing new versions of the software. A Weighted Routing Policy is used when multiple resources exist for the same functionality, and the traffic must be split between the resources based on specified weights.
Should you use Route 53, and why?
Highly Reliable: Route 53 is built using AWS's highly available and reliable infrastructure. The distributed nature of the AWS DNS servers helps ensure a consistent ability to route the end-users to the web application.
Scalable: It automatically scales the resources during traffic spikes and handles large queries without the user's intervention.
Easy to use: Very user-friendly and easy to configure DNS settings. Route 53 can begin responding to DNS queries within minutes and be mapped easily to any resource.
Health Check: Route 53 monitors the health of the application. If any failure is detected, it automatically redirects the user to a healthy resource before the customer can identify the problem.
Flexible: You can decide which policy you want to use at a given time.
Simple: Using routing types, Route 53 helps to manage traffic globally.
Cost-effective: Payment is made only according to the services used.
Secure: By integrating it with IAM, access to Amazon Route 53 is secured by giving its permissions to only authorized users.
Mapped with various AWS services: It can map domain names to Amazon EC2 instances, S3 buckets, and other AWS resources.
53 traffic flow helps to manage traffic globally via various routing types. All these routing types can be easily combined with DNS Failover to enable various low-latency, fault-tolerant architectures.
How does this happen exactly?
- A user opens a web browser and searches for www.mysite.com. This creates a DNS request for
www.mysite.com
- The DNS request is routed to a DNS resolver, usually managed by the Internet Service Provider (ISP).
- The ISP DNS resolver forwards the DNS request to a DNS root name server as the first stop.
- The DNS resolver then forwards the request to a top-level domain (TLD) nameserver corresponding to the
.com
domain. One of the several hundreds or thousands of the name servers will respond with the Route 53 name servers associated with thewww.mysite.com
domain. The DNS resolver then caches the name servers for future use. - Out of the returned Route 53 name servers, the DNS resolver will forward the request to one of them.
- The Route 53 name server will then look for a match or a
www.mysite.com
record in the hosted zone and retrieve the value. The value can be the Alias of a CloudFront distribution if it is a case of simple routing, a healthy nameserver, or sometimes a record corresponding to geolocation routing conditions. - The DNS resolver then finds the route to the DNS record or CloudFront IP that the user can use to access
www.mysite.com
and returns this value to the web browser. - Your web browser then sends a request to the IP address of the CloudFront distribution containing the website.
- The CloudFront distribution will then serve the web page based on its content delivery settings from the cache or the origin server to your web browser.
-
www.mysite.com
is then displayed on your web browser.
How Route 53 is priced
- 1. DNS zones The first 25 hosted zones charge is $0.50 per hosted DNS zone/month and then $0.10 for additional zones.
- Policy records
For every DNS name (such as
"www.mysite.com"
), the charge is $50 per Standard query, then $0.4 per million queries for the first billion queries/month, and then it charges $0.2 per million queries/month. - Latency-based routing queries The charge is $0.6 per million queries for the first billion queries/month. After that, it charges $0.3 per million queries/month.
- Geo-based queries It charges $0.7 per million queries for the first billion queries/month. After that, it charges $0.35 per million queries/month.
- Health checks There is no charge for the first 50 AWS endpoints. After that, it charges $0.5 / endpoint/month.
- Domain registration For domains across different TLDs, AWS charges as per a price sheet.
Things to watch out for
Route 53 does not support DNSSEC: DNSSEC or Domain Name System Security Extensions is used by the Internet Engineering Task Force as a suite of extension specifications. It effectively secures the data exchanged in DNS in Internet Protocol networks.
Route 53 does not provide forwarding or conditional forwarding options for domains used in an on-premise network.
Because Route 53 is combined with other AWS services, it may become a single point of failure. This results in a significant problem for AWS Route 53 disaster recovery and other relevant issues.
Limited Route 53 DNS Load Balancing as Route 53 load balancing only provides basic load balancing capabilities because it lacks advanced policy support and enterprise-class features.
Route 53 can be pretty expensive for businesses using non-AWS endpoints. Users can also experience slight latency with Route 53 when queries are forwarded to external servers after contacting Amazon infrastructure.
Working with Route 53
Migrating your domain to Route 53
Option 1: Leave your domain name with your current registrar.
If you want to leverage Route 53 routing features but don't want to move your domain name, you need to give your registrar the new name server addresses you'll get from the Route 53 records upon creating a hosted zone. Once you have updated the NS records in your current DNS, Route 53 will ensure the routing of all new domain requests through its name servers, but this propagation can take some time, so be patient.
Option 2: Move your domain name to Route 53
When you decide to transfer your domain to Route 53, 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 after creating Hosted Zones. Depending on your settings, changes usually take up to a day to reflect.
Route 53 hosted zone creation
With Route 53, you must create a Route 53 hosted zone. There are two types of hosted zones:
Public hosted zones are the most frequently used and specify how you want to route traffic on the Internet. Visit working with public hosted zones for more info.
Private hosted zones specify how you want to route traffic in an Amazon VPC (Virtual Private Cloud). Visit working with private hosted zones for more info.
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.
You can then enter the domain name, which becomes the name of the hosted zone, and select the type as a public hosted zone.
How to create a Route 53 private hosted zone
Creating a private zone starts in the same place; however, when you select private hosted zone, a new dialogue appears where you can choose the VPC or VPCs you want to route traffic to when someone enters the domain URL.
To configure Amazon Route 53 to route traffic to the S3 bucket
i.e., host a static site, we’ll do the following;
- Get a domain name from a provider like GoDaddy or namecheap.com
- Create a hosted zone in Route 53
- Host a static website in an S3 bucket in the root domain
- Create a subdomain bucket for redirect
- Configure Route 53 to point to the S3 bucket.
Getting a registered domain name.
There are numerous domain name registrars available including Route 53. You can register a domain on Route 53 or use other providers available. I went with GoDaddy.com.
Create a Route 53 hosted zone
On the Route 53 console, click on Hosted Zones in the left sidebar menu. You should see a window similar to this. I already have a hosted zone but you might not have any.
Click on create a hosted zone and you will see the options below
Type the domain name similar to the one you registered above. Mine is named emmory.online . You can add a description then click on create hosted zone to create it.
It may take a few seconds for the zone to be created. Once it is created, you should see a similar window.
Since your zone is empty, you should see two records only. The NS and SOA record types. (I have selected them in the illustration). We will need the NS record.
Click on the NS record check box and a window should appear on the right side. Copy all the values under the Value section.
You will then update these values (all 4) in the nameserver section of your domain name provider where your domain is registered. I registered wth GoDaddy.com. Login on your Godaddy account > Select your profile > My products and Services > DNS > Nameservers and click use custom Nameservers then paste all the four you took from Route 53. When done, you should see something similar to this. Yours may look different but the premise holds.
You have now updated your domain to use Route 53 nameservers. Traffic and requests will use AWS provided nameservers.
Create a static hosting for the root domain in S3 bucket
You probably figured out that you need website files by now to have a website. You can get templates or create a static website from scratch by yourself. Either way, review the files you will need for your static website.
Create the root domain S3bucket
Create a bucket with your exact domain name. I named mine emmory.online since that’s the domain name.
- Search for S3 in the AWS console. In the S3 console, click on Create bucket and add your domain name under the bucket name.
- Disable Block all public access and check the I acknowledge... box. This will enable public access for the bucket contents. Then click on Create bucket.
- The next step is to upload all your website files to the bucket (your-domain-name). To upload files, click Upload from the S3 bucket menu and select all the files and click on upload.
If you’d prefer a much shorter way than drag and drop. You can use theAWS cli
from your terminal. Change your directory with cd /yourwebsite files directory
and then type the following command
aws s3 cp . s3://<domain-name>
Attach a bucket policy to your bucket.
Earlier on, public access was enabled to the bucket. This is not always the recommended way and to fix it, you need to attach a bucket policy that controls access to your bucket and its contents.
From the bucket window, go to** permissions** then scroll down and find the bucket policy. Click on Edit and paste the following inside the bucket policy editor.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1405592139000",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::<domain-name>/*",
]
}
]
}
Make sure to replace the with your bucket name. Click on Save changes.
Enable static website hosting.
On the S3 bucket console, go to the properties tab then scroll to the bottom to find Static website hosting and click on Edit.
Choose Enable **and specify the index.html file inside the **Document part and click on Save changes. You should see a Bucket website endpoint. If you click on the link, you should see your website.
We’ll need another bucket for website redirect.
Create another bucket but add _www. _as the name of the bucket. Simply create the bucket and leave all the default setting on.
Enable static hosting on the website as well. Except this time, choose Redirect requests for an object as the Hosting type. Enter your domain name as the Host name without the www. part then choose http as the protocol and click save changes.
The endpoint for this bucket should redirect you to your domain name when you click on it. You might get a This site can’t be reached page but that’s is purely intentional.
Next. Configuring Route 53 to point to the S3 bucket endpoint.
Create a record.
Go to the hosted zone you created earlier in step one and click on create record. Only the NS
andSOA
record should be currently visible.
For Record 1
- Leave Record name empty and enable Alias
- For Route traffic to, choose Alias to S3 website endpoint from the dropdown.
- For Choose Region, choose the region where your S3 bucket is created.
- Under the Enter S3 endpoint, your bucket endpoint with a domain name should appear. If for some reason it doesn’t, copy your Website endpoint from here based on the region you create your bucket in.
- You can turn off Evaluate target health. I did.
- Click on Add another record at the bottom and repeat the same steps as before. Except, the record name as www.
- Click Create records. You should get a similar window.
et voilà! that’s it.
You may also add an AWS ACM certificate to your website if it has the Not secure tag. The certificate is absolutely free.
You can now verify that your website is running as expected by going to your domain name. It might take a while for this to reflect so some things you might try including reducing the TTL for the records. Check out my website at emmory.online. I know, it needs a fixer upper.
Top comments (0)