AWS Route 53 — DNS, Routing Policies, and Health Checks

What is Route 53?

Route 53 is AWS’s managed DNS (Domain Name System) service. DNS is the system that translates human-readable domain names like myapp.com into IP addresses that computers can connect to. Route 53 is called Route 53 because port 53 is the standard port for DNS traffic.

Beyond basic DNS, Route 53 adds health checking, traffic routing policies, and private DNS inside VPCs. It is a global service — it has no region, and it is one of the most highly available services AWS offers, with a 100% uptime SLA.

---

Core Concepts

Hosted Zones

A hosted zone is a container for DNS records for a specific domain. It is the equivalent of a traditional DNS zone file. There are two types:

Type	Purpose
Public hosted zone	Resolves DNS queries from the public internet
Private hosted zone	Resolves DNS queries only from within specified VPCs

When you create a hosted zone for myapp.com, Route 53 gives you 4 nameservers. You point your domain registrar (GoDaddy, Namecheap, etc.) to these nameservers, and Route 53 takes over DNS resolution for that domain.

Screen Route 53 → Hosted Zones → select a hosted zone. Show the list of DNS records inside it — the NS and SOA records that are created automatically.

# List hosted zones
aws route53 list-hosted-zones --output table

# Get records in a hosted zone
aws route53 list-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --output table

---

DNS Record Types

Record	Purpose	Example
A	Maps domain → IPv4 address	myapp.com → 1.2.3.4
AAAA	Maps domain → IPv6 address	myapp.com → 2001:db8::1
CNAME	Maps domain → another domain name	www.myapp.com → myapp.com
Alias	AWS-specific — maps to AWS resources	myapp.com → alb.amazonaws.com
MX	Mail server records	myapp.com → mail.myapp.com
TXT	Text data — used for SPF, DKIM, domain verification	myapp.com → "v=spf1 ..."
NS	Nameserver records — delegating a zone	Auto-created by Route 53
SOA	Start of authority — zone metadata	Auto-created by Route 53
SRV	Service location (used by some apps)	_sip._tcp.myapp.com
PTR	Reverse DNS — IP → domain name	4.3.2.1.in-addr.arpa → myapp.com

CNAME vs Alias — Key Difference

A CNAME cannot be used on the root domain (the zone apex). You cannot create myapp.com CNAME something.amazonaws.com — DNS rules forbid it.

An Alias record is an AWS Route 53 extension that solves this. It can point the root domain directly to an AWS resource (ALB, CloudFront, S3, another Route 53 record). Alias records are also free — Route 53 does not charge for queries against them.

Use CNAME for:   www.myapp.com → myapp.com  (subdomain to domain)
Use Alias for:   myapp.com → alb-123.eu-west-1.elb.amazonaws.com  (root domain)

---

Creating Records

SCREENSHOT: Route 53 → Hosted Zones → select zone → Create Record. Show the record creation form with record name, type dropdown (A/CNAME/Alias), routing policy, and TTL fields.

Simple A record

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "myapp.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{"Value": "1.2.3.4"}]
      }
    }]
  }'

Alias record pointing to an ALB

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "myapp.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z32O12XQLNTSW2",
          "DNSName": "my-alb-123456.eu-west-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }]
  }'

TTL (Time to Live): how long DNS resolvers cache the answer before asking again. Lower TTL (60s) → changes propagate faster, more DNS queries (higher cost). Higher TTL (86400s) → less DNS traffic, but changes take longer to propagate. Before doing a migration, lower the TTL to 60 seconds first so you can cut over quickly.

---

Routing Policies

Route 53 has 7 routing policies. They determine how Route 53 responds when multiple records exist for the same name.

1. Simple

One record, one answer. No health checking, no traffic splitting. Used for a single resource like a single EC2 instance.

myapp.com → 1.2.3.4

2. Weighted

Split traffic across multiple resources by percentage. Use for blue/green deployments, canary releases, or A/B testing.

myapp.com → 1.2.3.4  (weight 80 → 80% of traffic)
myapp.com → 5.6.7.8  (weight 20 → 20% of traffic)

SCREENSHOT: Route 53 → Create Record → Routing Policy set to Weighted. Show two records for the same name with different weights (e.g. 80 and 20) and different IP addresses.

3. Latency-Based

Route users to the AWS region with the lowest network latency from their location. AWS measures latency from the user’s DNS resolver to each region.

myapp.com → eu-west-1 ALB   (for users in Europe)
myapp.com → us-east-1 ALB   (for users in the US)
myapp.com → ap-east-1 ALB   (for users in Asia)

4. Failover

Active-passive setup. Route 53 checks health of the primary endpoint. If it fails, all traffic moves to the secondary (standby) endpoint automatically.

myapp.com → Primary:   prod-alb.eu-west-1.com   (health checked)
myapp.com → Secondary: dr-alb.us-east-1.com     (only used on primary failure)

SCREENSHOT: Route 53 → Create Record → Routing Policy set to Failover. Show the Primary record with a health check associated and the Secondary record as a fallback.

5. Geolocation

Route based on the geographic location of the user’s DNS query. More precise than latency — you can target by continent, country, or US state. Useful for content localisation, regional regulations, or blocking regions.

myapp.com → eu-west-1   (for queries from Europe)
myapp.com → me-south-1  (for queries from the Middle East)
myapp.com → us-east-1   (default — for all other locations)

6. Geoproximity (Traffic Flow only)

Like geolocation but you can shift traffic toward a resource using a bias value. A positive bias expands the geographic region served by a resource. A negative bias shrinks it. Only available through Route 53 Traffic Flow (a visual policy editor).

7. Multi-Value Answer

Returns up to 8 healthy records at random. Each record has a health check. Unhealthy records are not returned. This is not a load balancer — DNS clients pick one record to use. Use as a simple availability improvement when you have multiple endpoints.

---

Health Checks

Route 53 health checks continuously monitor the health of your endpoints. They are used by Failover, Weighted, Latency, and Geolocation policies to avoid routing to unhealthy resources.

Types of health checks

Type	What it monitors
HTTP / HTTPS / TCP	An endpoint (IP or domain name)
Other health checks	The status of other Route 53 health checks (calculated check)
CloudWatch alarm	The state of a CloudWatch alarm

Creating a health check

📸 SCREENSHOT: Route 53 → Health Checks → Create Health Check. Show the endpoint configuration with Protocol (HTTPS), IP address or domain, port, path (e.g. /health), and the Advanced configuration for failure threshold.

aws route53 create-health-check \
  --caller-reference "$(date +%s)" \
  --health-check-config '{
    "Type": "HTTPS",
    "ResourcePath": "/health",
    "FullyQualifiedDomainName": "myapp.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

Key settings:

• Request interval: 30 seconds (standard) or 10 seconds (fast — costs more)
• Failure threshold: how many consecutive failures before marking unhealthy (default: 3)
• String matching: check if the response body contains a specific string

Private endpoint health checks

Route 53 health checkers are on the public internet. They cannot reach private resources inside a VPC. For private resources, create a CloudWatch alarm that monitors the endpoint, then create a health check that monitors the alarm state.

---

Private Hosted Zones

A private hosted zone resolves DNS only within one or more VPCs. Use it to give your internal services friendly names without exposing them publicly.

Internal service names:
  db.internal       → 10.0.21.10  (RDS in private subnet)
  api.internal      → 10.0.11.20  (app server)
  cache.internal    → 10.0.21.30  (ElastiCache)

SCREENSHOT: Route 53 → Hosted Zones → Create Hosted Zone. Show the “Private hosted zone” type selected, and the VPC section below where you associate the VPC.

# Create a private hosted zone
aws route53 create-hosted-zone \
  --name internal.myapp.com \
  --caller-reference "$(date +%s)" \
  --hosted-zone-config '{"PrivateZone": true, "Comment": "Internal DNS"}' \
  --vpc '{"VPCRegion": "eu-west-1", "VPCId": "vpc-0abc123"}'

You must enable DNS resolution and DNS hostnames on the VPC for private hosted zones to work.

---

Route 53 Resolver

Route 53 Resolver handles DNS resolution for hybrid networks — DNS queries between your VPC and on-premises data centres.

Resolver Endpoints

Endpoint Type	Direction	Use Case
Inbound Resolver Endpoint	On-premises → AWS	On-prem servers resolve AWS private DNS names
Outbound Resolver Endpoint	AWS → On-premises	EC2 instances resolve on-prem DNS names

Resolver Rules

Outbound endpoints use forwarding rules to send specific DNS queries to specific DNS servers.

Rule: forward *.corp.internal → 192.168.1.10 (on-prem DNS)
Rule: forward *.aws.internal  → local Route 53 resolver

SCREENSHOT: Route 53 → Resolver → Endpoints → Create Endpoint. Show the inbound endpoint setup with VPC selection, security group, and the IP addresses assigned in each AZ.

---

Quick Reference

# List hosted zones
aws route53 list-hosted-zones --output table

# List records in a zone
aws route53 list-resource-record-sets --hosted-zone-id ZONEID

# Check health check status
aws route53 get-health-check-status --health-check-id HEALTHCHECKID

# Test DNS resolution
dig myapp.com
dig myapp.com @8.8.8.8           # query using Google DNS
nslookup myapp.com
host myapp.com

# Check from inside a VPC (for private zones)
dig db.internal @169.254.169.253  # query the VPC's built-in DNS resolver

Routing Policy	Use Case
Simple	Single resource
Weighted	Blue/green, canary, A/B
Latency	Multi-region, route to fastest
Failover	Active-passive DR
Geolocation	Regional content, compliance
Geoproximity	Shift traffic with bias
Multi-Value	Multiple healthy IPs

You can find me online at:

• GitHub: Mhdomer
• LinkedIn: mhd3omar
• Tryhackme: nonlouy