Part of my AWS learning journey — transitioning from Systems Engineer to Cloud/DevOps.
Route 53 is where networking meets the internet — how domain names reach your applications, how traffic gets distributed intelligently, and how AWS and on-premises networks resolve each other's names. 📋 Topics Covered # Topic Type 1 DNS Pre-Requisites — How DNS Works Concept 2 Complete DNS Resolution Flow Concept + Interview 3 What is Route 53 Concept 4 Hosted Zones — Public vs Private Concept + Lab 5 Hosted Zone ID Concept + DevOps 6 DNS Record Types and Use Cases Concept + Cert 7 NS and SOA Records — Auto-Created, Never Delete Concept + Interview 8 Alias Record — AWS-Specific Concept + Cert 9 Landing Zone — Brief Context Concept 10 Route 53 Routing Policies — All 8 Concept + Cert 11 Route 53 Traffic Policies Concept + DevOps 12 Route 53 Resolvers Concept + Interview 13 Inbound vs Outbound Resolver Endpoints Concept + Interview 14 Route 53 Forwarders Concept + Interview 15 Split-Horizon DNS Concept + Interview 16 Interview Questions Interview 17 Practice Tasks Practice DNS Pre-Requisites — How DNS Works DNS is the reason you type instead of .
Before understanding Route 53, these fundamentals must be solid.
Core Vocabulary Term What it means Domain Human-readable name — , IP Address Machine address — — what computers actually use DNS The translation system — converts domain names → IP addresses TLD Top-Level Domain — the last part after the final dot TTL Time To Live — how long a DNS response is cached before re-querying Recursive Resolver Finds the answer for the client by querying other DNS servers, caches the result Authoritative DNS Server Stores the official DNS records for a domain — returns the definitive answer Common TLDs: → commercial · → organizations · → network · → India · → United Kingdom · → education · → government The Complete DNS Resolution Flow This is the full journey a DNS query takes — from the moment you type a URL to the moment your browser connects to a web server.
User types in browser Step 1 — Browser Cache: Does my browser already know this IP from a recent visit? → Cache Miss → continue Step 2 — OS Cache: Does the operating system's DNS cache have it? → Cache Miss → continue Step 3 — Recursive Resolver (your ISP or 8.8.8.8): Does the resolver's cache have it? → Cache Miss → it begins querying on your behalf Step 4 — Root DNS Server: "Who manages domains?" → returns address of the TLD server Step 5 — TLD DNS Server (.com): "Who manages ?" → reads the NS record → returns Route 53 name server addresses Step 6 — Authoritative DNS Server (Route 53): "What's the IP for ?" → checks the Hosted Zone → finds the A Record → returns Step 7 — Recursive Resolver caches the result for the TTL duration → returns IP to the browser Step 8 — Browser connects to → TCP Handshake → TLS Handshake (for HTTPS) → HTTP Request → Web Server → Website loads Why TTL matters: If your A record has TTL = 300 seconds, every DNS resolver in the world caches your IP for 5 minutes.
If you change your server's IP, some users will still reach the old IP for up to 5 minutes.
Before planned migrations, lower the TTL to 60 seconds a day in advance so the change propagates faster.
What is Route 53 Amazon Route 53 is AWS's fully managed, highly available, and scalable DNS service.
It serves as the Authoritative DNS Server for your domains — when the TLD server (.com) asks "who manages ?", it's Route 53 name servers that answer.
The name "Route 53" comes from port 53 — the standard port DNS uses.
Route 53 does three things: Domain Registration — buy and manage domain names directly through AWS DNS Routing — host DNS records and route traffic to the correct resources Health Checking — monitor endpoints and route traffic away from unhealthy ones Hosted Zones — Public vs Private A Hosted Zone is the container for all DNS records belonging to one domain.
It's Route 53's way of organizing and storing the DNS configuration for — all the A records, CNAME records, MX records, and so on live inside the Hosted Zone for that domain.
The library analogy: Route 53 is the library.
A Hosted Zone is one bookshelf — dedicated to a single domain.
The DNS records (A, CNAME, MX, TXT) are the individual books on that shelf.
When someone asks "what's the IP for tejascloud.com?" — the librarian (Route 53) goes to the right bookshelf (Hosted Zone) and finds the right book (A record).
Public Hosted Zone Answers DNS queries coming from the public internet.
Anyone anywhere can query it.
This is what makes accessible to the world.
Used for: public websites, customer-facing APIs, any domain that should be reachable from the internet.
Private Hosted Zone Answers DNS queries only from within associated AWS VPCs.
Invisible to the public internet.
Used for internal service discovery and private naming.
Used for: internal microservices (, ), RDS endpoints with friendly names, any resource that should only be accessible within the VPC. 🎯 Interview scenario: "How do you give your internal services readable DNS names inside a VPC?" → Create a Private Hosted Zone associated with your VPC.
Add A records like .
EC2 instances in the VPC resolve the name automatically.
The internet can't see it at all.
Hosted Zone ID Every Hosted Zone has a unique ID (format: ).
Used in automation tools to target the exact Hosted Zone when creating or updating DNS records.
In Terraform: → tells Terraform which Hosted Zone to add the record to.
In AWS CLI: In CloudFormation: referenced when creating Route 53 resources programmatically.
It's not a concept you interact with in the console much — it matters most in infrastructure-as-code pipelines.
DNS Record Types and Use Cases A DNS Record is an entry inside a Hosted Zone that tells DNS how to resolve or handle a domain name.
Record Type Purpose Example A Domain → IPv4 address AAAA Domain → IPv6 address CNAME Domain → Another domain MX Mail server for the domain TXT Verification, SPF, DKIM, DMARC NS Which name servers manage the domain Auto-created by Route 53 SOA DNS zone metadata Auto-created by Route 53 PTR IP → Domain (reverse DNS) Real-world example — hosting a website on EC2: EC2 Public IP: You create an A Record in the Hosted Zone: User types → Route 53 checks the Hosted Zone → finds the A Record → returns → browser connects to your EC2 CNAME Limitations CNAME cannot be used on a root domain (apex domain).
You cannot create a CNAME for itself — only for subdomains like .
This is a DNS standard limitation, not just Route
53.
For pointing the root domain to an AWS resource, use an Alias Record instead.
NS and SOA Records — Auto-Created, Never Delete NS Record (Name Server): Automatically created when you create a Hosted Zone.
Contains the four Route 53 name servers responsible for your domain (e.g., ).
During DNS resolution, the TLD server (.com) uses the NS record to know which Route 53 name servers manage your domain and where to send queries.
Never delete the NS record.
Deleting it would break DNS resolution for your entire domain — the TLD servers would have nowhere to point queries.
SOA Record (Start of Authority): Also automatically created.
Stores DNS zone metadata — primary name server, serial number (increments on every zone change), refresh and retry intervals, expire time, and default TTL.
Never delete or modify the SOA record unless you know exactly why.
It's used internally by DNS infrastructure to manage zone transfers and cache behavior.
Alias Record — AWS-Specific The Alias Record is Route 53's solution to two problems: the CNAME root domain limitation and the need to point domains to AWS resources that don't have fixed IP addresses.
What Alias records can point to: Application Load Balancers (ALB) CloudFront distributions S3 static websites API Gateway endpoints Elastic Beanstalk environments Another Route 53 record in the same Hosted Zone Why you need Alias instead of CNAME for AWS resources: An ALB doesn't have a fixed IP — it has a DNS name like .
And you want (