Amazon Route 53 Explained: DNS, Hosted Zones, Records, Routing Policies, and Health Checks

Amazon Route 53 is AWS service for DNS. DNS means Domain Name System, and its main work is simple: it converts human friendly domain names into machine friendly IP addresses. Meaning when we type www.google.com, computers do not directly understand that name. DNS helps convert that hostname into an IP address like 172.217.18.36, and then the browser can connect to the correct server. This is why DNS is called the backbone of the internet, because almost every website request starts from DNS.

Before understanding Route 53 deeply, we need to understand a few DNS words. A domain registrar is the company where we buy or register a domain name, like Amazon Route 53, GoDaddy, and others. DNS records are entries like A, AAAA, CNAME, and NS that tell DNS what to return when someone asks for a domain. A zone file is the file or container that stores DNS records. A name server is the server that resolves DNS queries, and it can be authoritative or non-authoritative. Authoritative means it has the final trusted answer for that domain.

In a URL like http://api.www.example.com, there are multiple parts. http is the protocol. .com is the top level domain, also called TLD. example.com is the second level domain. api.www.example.com is a fully qualified domain name, also called FQDN. DNS follows this hierarchy from root, then TLD, then domain, then subdomain.

How DNS Works

When we open example.com in a browser, the browser first asks a local DNS server. This local DNS server is usually managed by the company network or assigned by the ISP. If the local DNS server does not already know the answer, it asks the root DNS server. The root server does not usually return the final IP address, but it tells which TLD server handles .com.

Then the local DNS server asks the .com TLD DNS server. The TLD server tells which name servers are responsible for example.com. After that, the local DNS server asks the authoritative name server for example.com, and that server returns the IP address, for example 9.10.11.12. Then the browser can send the actual web request to the web server at that IP.

DNS also uses TTL, which means Time To Live. TTL decides how long DNS resolvers can cache the answer. If TTL is high, the DNS answer stays cached for a long time. If TTL is low, changes can be picked up faster, but DNS servers will receive more queries.

What Is Amazon Route 53?

Amazon Route 53 is a highly available, scalable, fully managed, authoritative DNS service from AWS. It is authoritative because we, as the domain owner, can update DNS records inside Route 53. Route 53 can also work as a domain registrar, meaning we can buy and manage domain names from it. It can also perform health checks for resources, so DNS can respond differently when an endpoint becomes unhealthy.

One important exam point is that Route 53 is the only AWS service that provides a 100% availability SLA. The name Route 53 comes from DNS port 53, because traditional DNS works on port 53.

Route 53 Records

Route 53 records define how traffic should be resolved for a domain or subdomain. A record normally contains the domain or subdomain name, record type, value, routing policy, and TTL. For example, the name can be example.com, the type can be A, the value can be 12.34.56.78, the routing policy can be simple routing, and TTL controls how long DNS resolvers cache the record.

The most important record types to know are A, AAAA, CNAME, and NS. An A record maps a hostname to an IPv4 address. An AAAA record maps a hostname to an IPv6 address. A CNAME record maps one hostname to another hostname. An NS record stores the name servers for a hosted zone and helps control how DNS traffic is resolved for the domain.

There are also advanced record types like CAA, DS, MX, NAPTR, PTR, SOA, TXT, SPF, and SRV. For the exam, the basic records are more important, but it is still good to know that Route 53 supports many DNS record types.

Hosted Zones

A hosted zone is a container for DNS records. It defines how traffic should be routed for a domain and its subdomains. There are two main types: public hosted zones and private hosted zones.

A public hosted zone is used for public internet domain names. For example, application1.mypublicdomain.com can point to a public AWS resource like an Application Load Balancer, CloudFront distribution, S3 static website, or EC2 public IP. Anyone on the internet can query public DNS records.

A private hosted zone is used inside one or more VPCs. For example, api.example.internal can point to a private IP like 10.0.0.10, and db.example.internal can point to another private IP like 10.0.0.35. These names are only useful inside the connected VPCs, not on the public internet. Route 53 hosted zones cost money per hosted zone per month, and the slide mentions $0.50 per month per hosted zone.

TTL in Route 53

TTL decides how long the DNS resolver caches a DNS answer. Suppose myapp.example.com has an A record pointing to 12.34.56.78 with a TTL. When a client asks Route 53 for this domain, Route 53 returns the IP and TTL. The DNS resolver then caches that answer for the TTL duration. During that time, it may not ask Route 53 again for the same record.

High TTL, like 24 hours, means less traffic to Route 53 and fewer DNS queries, but it also means records can stay outdated for longer after you change them. Low TTL, like 60 seconds, means more DNS queries and possibly more cost, but records become outdated for less time and changes are easier to apply quickly. Except for Alias records, TTL is mandatory for each DNS record.

CNAME vs Alias

AWS resources like Load Balancers and CloudFront distributions expose AWS hostnames. For example, a load balancer may have a DNS name like lb1-1234.us-east-2.elb.amazonaws.com, but we usually want users to access something like myapp.mydomain.com.

A CNAME record points one hostname to another hostname. For example, app.mydomain.com can point to another domain name. But CNAME records can only be used for non-root domains. Meaning you can create a CNAME for www.example.com, but you cannot create a CNAME for the root domain example.com, also called the zone apex.

Alias records are Route 53 specific. An Alias record points a hostname to an AWS resource, like an Elastic Load Balancer, CloudFront distribution, API Gateway, Elastic Beanstalk environment, S3 website, VPC Interface Endpoint, Global Accelerator, or another Route 53 record in the same hosted zone. Alias records work for both root domains and subdomains, so you can use them for example.com and also for app.example.com.

Alias records are free of charge, support native health check behavior, and automatically recognize changes in the AWS resource IP addresses. This is important because AWS resources like load balancers can change IP addresses behind the scenes. Alias records are always created as type A or AAAA records for AWS resources, and we cannot set TTL manually for Alias records. Also, we cannot create an Alias record for an EC2 DNS name directly.

Route 53 Routing Policies

Routing policies define how Route 53 responds to DNS queries. The word routing can be confusing here. Route 53 does not route actual application traffic like a load balancer. DNS only answers queries. After DNS gives the answer, the client connects to that target.

Route 53 supports multiple routing policies: simple, weighted, failover, latency-based, geolocation, geoproximity, IP-based routing, and multi-value answer. Each one solves a different problem.

Simple Routing Policy

Simple routing is normally used when we want to route traffic to a single resource. For example, foo.example.com can point to one IP address like 11.22.33.44. Simple routing can also return multiple values in the same record. If multiple values are returned, the client chooses one of them randomly.

When Alias is enabled with simple routing, we can specify only one AWS resource. Simple routing also cannot be associated with health checks. So simple routing is good for basic DNS records, but not for advanced failover behavior.

Weighted Routing Policy

Weighted routing lets us control what percentage of DNS responses go to each resource. We assign a relative weight to each record. The records must have the same name and type. The weights do not need to add up to 100, because Route 53 calculates traffic based on each record weight compared to the total weight.

For example, if one record has weight 70, another has weight 20, and another has weight 10, then Route 53 will approximately send 70 percent, 20 percent, and 10 percent of responses to those resources. This is useful for load balancing between regions or testing a new application version. Weighted records can be associated with health checks.

If we assign a weight of 0 to a record, Route 53 stops sending traffic to that resource. But if all records have weight 0, then Route 53 returns all records equally.

Latency-Based Routing Policy

Latency-based routing sends users to the resource that gives the lowest latency from their location. This is useful when user performance is the priority. The latency is based on traffic between users and AWS regions, not only geographic distance. For example, users in Germany may still be routed to the US if the US region gives the lowest latency at that time.

Latency-based routing can be associated with health checks. This gives it failover capability, because Route 53 can avoid unhealthy resources and return a healthier low-latency endpoint.

Route 53 Health Checks

Route 53 health checks are used for automated DNS failover. There are three main types. The first type monitors an endpoint, like an application, server, load balancer, or public AWS resource. The second type monitors other health checks, which is called calculated health checks. The third type monitors CloudWatch Alarms, which gives full control and is useful for private resources or custom metrics.

Health checks are integrated with CloudWatch metrics. One important point is that HTTP health checks are only for public resources, because Route 53 health checkers are outside your VPC.

When Route 53 monitors an endpoint, around 15 global health checkers check the endpoint. The default healthy or unhealthy threshold is 3. The default interval is 30 seconds, but we can set it to 10 seconds for a higher cost. Supported protocols are HTTP, HTTPS, and TCP.

If more than 18 percent of health checkers report the endpoint as healthy, Route 53 considers the endpoint healthy. Otherwise, it considers it unhealthy. We can also choose which locations Route 53 uses for health checks. For HTTP and HTTPS checks, the endpoint must return a 2xx or 3xx status code. Health checks can also pass or fail based on text found in the first 5120 bytes of the response.

Because health checkers come from outside, the router or firewall must allow incoming requests from Route 53 health checker IP ranges. AWS publishes these IP ranges in https://ip-ranges.amazonaws.com/ip-ranges.json.

Calculated Health Checks

Calculated health checks combine the result of multiple child health checks into one parent health check. We can use OR, AND, or NOT logic. A calculated health check can monitor up to 256 child health checks. We can also define how many child checks must pass for the parent check to be considered healthy.

This is useful during maintenance. For example, if we want to perform maintenance without causing all DNS health checks to fail, we can design the parent health check logic in a way that still keeps the system healthy when some child checks are intentionally unavailable.

Health Checks for Private Hosted Zones

Route 53 health checkers are outside the VPC, so they cannot directly access private endpoints inside private subnets or private on-premises networks. If we need health check behavior for private resources, the common approach is to create a CloudWatch metric, create a CloudWatch Alarm from that metric, and then create a Route 53 health check that checks the CloudWatch Alarm.

This gives more control because the private resource can be monitored from inside the VPC or by another system, and Route 53 only needs to read the alarm state.

Failover Routing Policy

Failover routing is active-passive routing. We have a primary resource and a secondary disaster recovery resource. Route 53 normally returns the primary record. If the primary health check fails, Route 53 returns the secondary record.

For failover routing, a health check is mandatory for the primary resource. This is useful when we need disaster recovery. For example, the primary EC2 instance or load balancer can serve users normally, and the secondary resource can take over when the primary becomes unhealthy.

Geolocation Routing Policy

Geolocation routing is based on the user location. It is different from latency-based routing. Latency-based routing cares about network latency, but geolocation routing cares about where the user is located.

We can specify location by continent, country, or US state. If there are overlapping records, Route 53 chooses the most precise location. For example, a US state rule is more specific than a country rule, and a country rule is more specific than a continent rule. We should also create a default record, because some users may not match any configured location.

Common use cases are website localization, restricting content distribution, and regional load balancing. Geolocation records can also be associated with health checks.

Geoproximity Routing Policy

Geoproximity routing routes traffic based on the geographic location of users and resources. It can use AWS resources by AWS region, or non-AWS resources by latitude and longitude. The special thing about geoproximity routing is bias.

Bias lets us shift more or less traffic to a resource by changing the size of the geographic region around it. A positive bias from 1 to 99 expands the region, so more traffic goes to that resource. A negative bias from -1 to -99 shrinks the region, so less traffic goes to that resource.

For example, if us-east-1 and us-west-1 both have bias 0, traffic is split based on normal geographic proximity. But if us-east-1 gets a bias of 50, then its geographic area becomes larger, so more users are routed to us-east-1. To use geoproximity routing, we must use the Route 53 Traffic Flow feature.

IP-Based Routing Policy

IP-based routing uses the client IP address to decide which endpoint should be returned. We provide CIDR blocks for clients and map them to endpoints or locations. For example, 203.0.113.0/24 can map to location-1, and 200.5.4.0/24 can map to location-2.

Then Route 53 records can return different values for the same domain based on those locations. A user with IP 203.0.113.56 may get endpoint 1.2.3.4, while a user with IP 200.5.4.100 may get endpoint 5.6.7.8. This is useful to optimize performance, reduce network cost, or route users from a particular ISP to a specific endpoint.

Multi-Value Routing Policy

Multi-value routing is used when we want Route 53 to return multiple resources for one DNS query. It can be associated with health checks, so Route 53 returns only healthy values. For each multi-value query, Route 53 can return up to 8 healthy records.

This looks a little like load balancing, but it is not a replacement for an Elastic Load Balancer. Multi-value routing only returns multiple DNS answers. The client still decides which one to use, and it does not provide the same advanced traffic management features as an ELB.

Domain Registrar vs DNS Service

A domain registrar is where we buy or register the domain name. For example, we can buy example.com from GoDaddy or Amazon Registrar. Usually, the registrar also gives DNS features, so we can manage records from the same place.

But the domain registrar and DNS service do not have to be the same. We can buy a domain from GoDaddy and still use Amazon Route 53 as the DNS service. In that case, GoDaddy remains the registrar, but Route 53 manages the DNS records.

To use a third-party registrar with Route 53, we first create a hosted zone in Route 53. Route 53 gives us name servers for that hosted zone. Then we go to the third-party registrar website and update the domain NS records to use Route 53 name servers. After that, DNS queries for the domain are handled by Route 53.

So the key point is: Domain Registrar is not equal to DNS Service. Every domain registrar usually provides some DNS features, but we can use a different DNS service provider when needed.

Quick Exam Notes

• DNS converts hostnames into IP addresses.
• Route 53 is authoritative DNS, a domain registrar, and supports health checks.
• Route 53 has a 100% availability SLA.
• A records map to IPv4, AAAA records map to IPv6, CNAME maps hostname to hostname, and NS defines name servers.
• Public hosted zones are for internet DNS, private hosted zones are for VPC internal DNS.
• High TTL means fewer queries but slower updates. Low TTL means faster updates but more DNS queries.
• CNAME cannot be used at the zone apex, but Alias can.
• Alias records point to AWS resources, work for root domains, are free, and do not allow manual TTL.
• Simple routing cannot use health checks.
• Weighted routing is useful for percentage-based traffic distribution.
• Latency routing is based on lowest latency to AWS regions.
• Geolocation routing is based on user location.
• Geoproximity routing uses location plus bias and requires Route 53 Traffic Flow.
• IP-based routing uses client CIDR mappings.
• Multi-value routing returns up to 8 healthy records but is not a replacement for ELB.
• For private resources, use CloudWatch Alarm based health checks because Route 53 health checkers cannot directly access private endpoints.