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 google.com instead of 142.250.195.46. Before understanding Route 53, these fundamentals must be solid.
Core Vocabulary
| Term | What it means |
|---|---|
| Domain | Human-readable name — google.com, tejascloud.in
|
| IP Address | Machine address — 54.21.11.90 — 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:
.com→ commercial ·.org→ organizations ·.net→ network ·.in→ India ·.uk→ United Kingdom ·.edu→ education ·.gov→ 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
tejascloud.comin browserStep 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
.comdomains?" → returns address of the.comTLD serverStep 5 — TLD DNS Server (.com): "Who manages
tejascloud.com?" → reads the NS record → returns Route 53 name server addressesStep 6 — Authoritative DNS Server (Route 53): "What's the IP for
tejascloud.com?" → checks the Hosted Zone → finds the A Record → returns54.21.11.90Step 7 — Recursive Resolver caches the result for the TTL duration → returns IP to the browser
Step 8 — Browser connects to
54.21.11.90→ 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 tejascloud.com?", 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 tejascloud.com — 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).
Route 53
│
├── Hosted Zone: tejascloud.com (bookshelf)
│ ├── A Record: tejascloud.com → 54.21.11.90
│ ├── CNAME: www → tejascloud.com
│ ├── MX Record: mail server
│ └── TXT Record: verification
Public Hosted Zone
Answers DNS queries coming from the public internet. Anyone anywhere can query it. This is what makes
tejascloud.comaccessible 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 (payment.internal, db.internal), 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
payment-service.internal → 10.200.1.45. 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: Z1234567890ABC). Used in automation tools to target the exact Hosted Zone when creating or updating DNS records.
In Terraform:
zone_id = "Z1234567890ABC"→ tells Terraform which Hosted Zone to add the record to.In AWS CLI:
aws route53 change-resource-record-sets --hosted-zone-id Z1234567890ABC ...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 | tejascloud.com → 54.21.11.90 |
| AAAA | Domain → IPv6 address | tejascloud.com → 2001:db8::1 |
| CNAME | Domain → Another domain | www.tejascloud.com → tejascloud.com |
| MX | Mail server for the domain | tejascloud.com → mail.google.com |
| TXT | Verification, SPF, DKIM, DMARC | "v=spf1 include:amazon.com ~all" |
| 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) | 54.21.11.90 → tejascloud.com |
Real-world example — hosting a website on EC2:
EC2 Public IP:
54.21.11.90
You create an A Record in the Hosted Zone:tejascloud.com → 54.21.11.90
User typestejascloud.com→ Route 53 checks the Hosted Zone → finds the A Record → returns54.21.11.90→ browser connects to your EC2
CNAME Limitations
CNAME cannot be used on a root domain (apex domain). You cannot create a CNAME for tejascloud.com itself — only for subdomains like www.tejascloud.com. 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.,
ns-1234.awsdns-23.com). 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
my-alb-123456789.ap-south-1.elb.amazonaws.com. And you wanttejascloud.com(the root domain) to point to it. A CNAME can't be used on a root domain. An Alias record can. AWS resolves the Alias internally to the ALB's current IP, always fresh — you never manage IPs.
Key difference from CNAME:
| CNAME | Alias | |
|---|---|---|
| Works on root domain? | ❌ No | ✅ Yes |
| Points to | Any domain | Only supported AWS resources |
| Health check support | No | Yes (Route 53 can health check Alias targets) |
| DNS query charges | Normal query charges | Free when pointing to AWS resources |
| Returns to client | Another domain (CNAME chain) | Actual IP directly |
🎯 Cert and interview tip: "How do you point your root domain
example.comto an ALB?" → Use an Alias record (not a CNAME — CNAMEs can't be on root domains). Alias is AWS-specific and resolves directly to the resource's current IPs.
Landing Zone — Brief Context
You'll hear this term in enterprise AWS contexts. A Landing Zone is a secure, pre-built AWS foundation for an entire organization — not a single account but a structured multi-account setup.
It's built using AWS Control Tower and includes: AWS Organizations (for multiple accounts), Organizational Units (OUs), IAM Identity Center (SSO), CloudTrail for audit logging, security guardrails, centralized networking, and standardized logging.
The goal: before any workload is deployed, the organization has a secure, governed, scalable starting point. Route 53 is part of this — centralized DNS for the entire organization's accounts.
This is more relevant at the architecture and governance level than day-to-day engineering — worth knowing the term and what it represents.
Route 53 Routing Policies — All 8
A Routing Policy decides which DNS answer Route 53 returns when a client queries for a domain. Route 53 supports 8 policies, each solving a different problem.
1. Simple Routing
Returns one or a few IP addresses without any logic — basic DNS. No health checks, no traffic splitting, no awareness of location or latency.
Use for: a single resource (one EC2, one ALB) with no need for intelligent routing.
Example: tejascloud.com → ALB DNS name — every user everywhere gets the same answer.
2. Weighted Routing
Splits traffic across multiple resources according to specified weights. Route 53 sends a percentage of DNS responses to each endpoint based on the weight assigned.
Example:
Weight 90 → Production ALB (version 1.0)
Weight 10 → Staging ALB (version 2.0)
Result: 90% of users hit the old version, 10% hit the new one — canary deployment.
Use for: A/B testing, canary deployments, gradually shifting traffic to a new version.
Weight calculation: Route 53 uses the ratio — if you have weights 90 and 10, it returns the first record to 90/(90+10) = 90% of queries.
3. Latency-Based Routing
Routes users to the AWS Region that provides the lowest network latency for them, based on AWS's measured latency data between the user's location and AWS Regions.
Example:
A user in India → Route 53 measures latency to Mumbai (ap-south-1) vs N. Virginia (us-east-1) → returns Mumbai record because it's closest.
Use for: any application with users in multiple geographic locations where latency matters.
🎯 Important distinction: Latency routing is based on actual measured network latency — not geographic distance. A user in Sri Lanka might have lower latency to Singapore than to Mumbai depending on network paths. Route 53 uses real data, not map distance.
4. Failover Routing
Routes traffic to a Primary resource normally. If the primary fails a health check, Route 53 automatically returns the Secondary (backup) record instead.
Example:
Primary → Production ALB in ap-south-1 (health checked)
Secondary → Backup static S3 website showing "maintenance page"
If Primary health check fails → Route 53 returns Secondary automatically
Use for: disaster recovery, high availability with a fallback endpoint.
Requires health checks on the primary record — Route 53 needs to know when to failover.
5. Geolocation Routing
Routes traffic based on the geographic location of the user — specifically their country or continent as determined by their IP address.
Example:
Requests from India → Mumbai ALB
Requests from United States → N. Virginia ALB
Requests from EU countries → Frankfurt ALB
Default → Global ALB (for any location not explicitly mapped)
Use for: serving localized content (language, pricing, regulations), data residency compliance (EU users must stay in EU), regional product catalogs.
Always configure a Default record — without it, users from unmapped locations will get no DNS response.
🎯 Geolocation vs Latency — the key difference: Geolocation routes based on where the user is located (country/continent). Latency routes based on which region responds fastest (actual network performance). A UK user might have lower latency to US East than EU-West due to network paths — Geolocation always sends them to the EU record regardless. Latency would send them to wherever is actually faster.
6. Geoproximity Routing
Routes traffic based on geographic distance between the user and the resource, with an optional bias that expands or shrinks the effective area of a region.
The key feature is bias — a positive bias makes a region "bigger" (attracts more users from surrounding areas), a negative bias makes it "smaller."
Example:
Mumbai region with bias +50 → expands Mumbai's effective reach → attracts users from South Asia, Middle East, East Africa
Singapore region with no bias → normal reach
Use for: fine-grained geographic traffic control beyond simple country/continent boundaries, gradually shifting traffic from one region to another by adjusting biases.
Requires Route 53 Traffic Flow to configure — it's the only policy that uses the visual traffic flow editor.
🎯 Geolocation vs Geoproximity: Geolocation is rigid — "India → Mumbai, USA → Virginia." Geoproximity is flexible — "route based on distance, but adjust the effective range of each region using bias." Use Geoproximity when you need to fine-tune exactly which geographic area each endpoint serves.
7. IP-Based Routing
Routes traffic based on the source IP address (CIDR range) of the DNS query, not the geographic location.
Example:
Your corporate network uses IPs in the range
203.0.113.0/24→ you want all employees on that network routed to a private internal version of the app
Everyone else → public version
Use for: routing corporate network users differently from public internet users, routing specific ISP blocks to specific endpoints, network-specific traffic management.
Difference from Geolocation: Geolocation infers location from IP geography. IP-Based routing uses exact CIDR ranges you define — much more precise for specific known IP ranges.
8. Multivalue Answer Routing
Returns up to 8 healthy records in response to a DNS query. Clients (browsers, load balancers) can pick any one and retry with another if it fails.
Example:
tejascloud.comhas 5 EC2 instances each with their own health check
Route 53 returns up to 8 healthy IPs → client picks one → if it fails, client retries with another
Use for: basic DNS-level load distribution without a dedicated load balancer, improving availability by giving clients multiple options.
Not a replacement for ALB: Multivalue answer is client-side load distribution via DNS. ALB provides sophisticated server-side load balancing with health checks, connection draining, SSL termination, and more. Multivalue is a lightweight fallback — not a production load balancing strategy on its own.
Route 53 Routing Policies — Comparison Table
| Policy | Routes based on | Health check support | Use for |
|---|---|---|---|
| Simple | Nothing — just returns the record | Optional | Single resource, basic DNS |
| Weighted | Percentage split | Yes | A/B testing, canary deployments |
| Latency | Measured network latency | Yes | Global apps, latency-sensitive |
| Failover | Primary/Secondary health | Yes (required) | DR, high availability |
| Geolocation | User's country/continent | Yes | Localization, compliance |
| Geoproximity | Geographic distance + bias | Yes | Fine-grained geographic control |
| IP-Based | User's source IP CIDR | Yes | Known IP range routing |
| Multivalue | None — returns multiple healthy IPs | Yes | Basic DNS-level distribution |
Route 53 Traffic Policies
A Traffic Policy is an advanced Route 53 feature that lets you build complex routing configurations visually — combining multiple routing policies, health checks, and endpoints into one reusable policy.
For example: Use Latency routing at the top level to send users to their nearest region, then within each region use Weighted routing to split between a canary (10%) and production (90%) endpoint. This nested, multi-level routing is what Traffic Policies enable.
Traffic Policies are version-controlled — you can create a new version without affecting the live configuration, then apply it when ready. Useful for large organizations with complex, global routing needs.
Route 53 Resolvers
Route 53 Resolver is the DNS resolver built into every AWS VPC. By default, it answers DNS queries from EC2 instances for:
- Public domains (via the internet)
- Private Hosted Zones associated with the VPC
- AWS service endpoints
The Resolver is available at the VPC's base IP + 2 address (e.g., if your VPC CIDR is 10.200.0.0/16, the resolver is at 10.200.0.2).
The challenge in hybrid environments:
When you have both an AWS VPC and an on-premises network connected via VPN or Direct Connect, two separate DNS worlds exist:
- AWS Route 53 knows about AWS resources (
payment.internal, RDS endpoints) - On-premises DNS knows about on-premises resources (
server.company.local,printer.office.local)
Neither side can resolve the other's names by default. Resolver Endpoints bridge this gap.
Inbound vs Outbound Resolver Endpoints
Inbound Resolver Endpoint
Allows DNS queries coming from outside AWS (on-premises network) to enter the VPC and be resolved by Route 53.
Flow:
On-premises server needs to resolve
app.internal(an AWS Private Hosted Zone record) → On-premises DNS server forwards the query to the Inbound Endpoint IP → Inbound Endpoint accepts it → forwards to Route 53 Resolver → Route 53 checks Private Hosted Zone → returns10.200.1.45→ on-premises server connects to the private AWS resource
Key point: The Inbound Endpoint gives on-premises networks a target IP they can send DNS queries to — an ENI inside your VPC that acts as the entry door for external DNS queries.
Outbound Resolver Endpoint
Allows DNS queries originating inside the VPC to leave AWS and reach an on-premises DNS server.
Flow:
EC2 instance needs to resolve
server.company.local(managed by on-premises DNS) → EC2 queries Route 53 Resolver → Resolver checks Forwarding Rules → matches*.company.local→ Outbound Endpoint forwards the query to the on-premises DNS server IP → on-premises DNS returns the IP → Resolver returns it to EC2
Key point: The Outbound Endpoint is the exit door for DNS queries that need to leave AWS and reach on-premises DNS servers. It's always paired with Forwarding Rules that define which domain names should be forwarded (and to which on-premises DNS server IP).
Route 53 Forwarders
A Forwarding Rule (Resolver Rule) is what tells Route 53 Resolver which DNS queries to forward through the Outbound Endpoint instead of resolving locally.
Forwarding Rule:
*.company.local → forward to 192.168.10.10 (on-premises DNS server IP) via the Outbound EndpointAny VPC query for a
.company.localdomain → Route 53 Resolver sees the rule → forwards to the on-premises DNS server through the Outbound Endpoint → gets the answer → returns to the EC2 instance
Types of Resolver Rules:
| Rule Type | What it does |
|---|---|
| Forwarding Rule | Forward matching DNS queries to a specified IP (usually on-premises DNS) |
| System Rule | Auto-created by AWS — handles Private Hosted Zones and AWS-internal domains |
| Recursive Rule | Default — queries not matching any rule are resolved normally via internet DNS |
Sharing Resolver Rules: Rules can be shared across multiple VPCs using AWS Resource Access Manager (RAM) — so a single set of forwarding rules can be applied to an entire organization's VPCs centrally.
Split-Horizon DNS
One domain, two different DNS answers depending on who's asking — without the client ever knowing.
The concept:
app.company.com— the same domain name returns different answers based on where the DNS query originates.Query from inside the AWS VPC → Private Hosted Zone answers → returns
10.0.1.50(private IP, internal traffic stays inside the network)Query from the public internet → Public Hosted Zone answers → returns
54.20.30.40(public IP, routed through the internet)
How it works in Route 53:
Create a Private Hosted Zone for
app.company.comassociated with your VPC → add an A record pointing to the private IP.
Create a Public Hosted Zone forapp.company.com→ add an A record pointing to the public IP.When an EC2 instance inside the VPC queries
app.company.com→ Route 53 Resolver checks the Private Hosted Zone first → returns the private IP.When an internet user queries
app.company.com→ hits the public DNS infrastructure → Public Hosted Zone answers → returns the public IP.
Why Private Hosted Zone wins for VPC queries:
The Private Hosted Zone always overrides the Public Hosted Zone for queries originating inside the associated VPC. This is by design — internal traffic should stay internal, even if a public record also exists for the same domain.
Why this pattern is valuable:
- Internal users access the application over the private network — lower latency, no egress costs, more secure
- External users still reach the same application via its public endpoint
- The application doesn't need to change — the DNS layer handles the routing transparently
🎯 Interview definition: Split-Horizon DNS = same domain name + different DNS answer based on where the query originates. Public zone for internet users, Private zone for VPC users, private zone always wins for internal queries.
⚡ Quick Revision
DNS Resolution Flow
Browser Cache → OS Cache → Recursive Resolver → Root DNS → TLD DNS → Authoritative DNS (Route 53) → IP → Browser connects
Route 53 Basics
- Authoritative DNS service for AWS-managed domains
- Port 53 = standard DNS port
- Does: Domain Registration + DNS Routing + Health Checking
Hosted Zones
- Public Hosted Zone: internet-facing DNS, answers from anywhere
- Private Hosted Zone: VPC-only DNS, invisible to internet, overrides public for VPC queries
- One Hosted Zone per domain, contains all DNS records for that domain
Record Types
- A → IPv4, AAAA → IPv6, CNAME → another domain (not root), MX → mail, TXT → verification/email security, NS → name servers (auto-created, never delete), SOA → zone metadata (auto-created, never delete), PTR → reverse DNS
Alias Record
- AWS-specific, works on root domain (CNAME can't), points to ALB/CloudFront/S3/API GW, free DNS queries for AWS resource targets
Routing Policies
| Policy | Routes based on |
|---|---|
| Simple | Nothing — just returns record |
| Weighted | Percentage split |
| Latency | Measured network latency (not distance) |
| Failover | Primary/Secondary health status |
| Geolocation | User's country/continent |
| Geoproximity | Distance + adjustable bias |
| IP-Based | Source IP CIDR range |
| Multivalue | Returns multiple healthy IPs |
Resolvers
- Inbound Endpoint: on-premises → AWS (resolve AWS Private Hosted Zone records from outside)
- Outbound Endpoint: AWS → on-premises (resolve on-premises domain names from VPC)
- Forwarding Rules: define which domains get forwarded through Outbound Endpoint
Split-Horizon DNS
- Same domain, different answer based on query origin
- Private Hosted Zone (VPC queries) → private IP
- Public Hosted Zone (internet queries) → public IP
- Private always wins for VPC-originated queries
💼 Interview Questions
Q1: Walk through the complete DNS resolution flow.
User types domain in browser → browser cache miss → OS cache miss → Recursive Resolver checked → if cache miss, Resolver queries Root DNS Server ("who manages .com?") → Root returns TLD server address → Recursive Resolver queries TLD server (.com) → TLD returns Route 53 name servers from the NS record → Resolver queries Route 53 (authoritative) → Route 53 checks the Hosted Zone → returns the A record (IP) → Resolver caches the result for the TTL duration → browser receives IP → TCP/TLS handshake → HTTP request → website loads.
Q2: What is the difference between a Public and Private Hosted Zone?
A Public Hosted Zone answers DNS queries from the public internet — it's how your domain is reachable by anyone. A Private Hosted Zone answers queries only from within associated AWS VPCs — it's invisible to the internet and used for internal service discovery. When a query originates from inside the VPC, the Private Hosted Zone always overrides the Public one for the same domain.
Q3: Why can't you use a CNAME for a root domain and what do you use instead?
CNAME is a DNS standard limitation — it cannot be placed on the apex (root) domain like example.com, only on subdomains like www.example.com. For pointing a root domain to an AWS resource (ALB, CloudFront, S3), Route 53 provides Alias records — an AWS-specific extension that works on root domains, supports health checks, and doesn't charge for DNS queries to AWS targets.
Q4: What is Split-Horizon DNS and how is it implemented in Route 53?
Split-Horizon DNS returns different DNS answers for the same domain depending on where the query originates. In Route 53, you create a Private Hosted Zone associated with your VPC (returns private IP for internal users) and a Public Hosted Zone (returns public IP for internet users) for the same domain. VPC queries always resolve via the Private Hosted Zone — the Private Hosted Zone overrides the Public for any query originating inside the associated VPC.
Q5: What is the difference between Route 53 Inbound and Outbound Resolver Endpoints?
An Inbound Endpoint allows DNS queries coming from outside AWS (typically an on-premises network) to enter the VPC and be resolved by Route 53 — so on-premises servers can resolve Private Hosted Zone names. An Outbound Endpoint allows DNS queries originating inside the VPC to leave AWS and reach an on-premises DNS server — so EC2 instances can resolve on-premises domain names. Outbound Endpoints work with Forwarding Rules that specify which domain patterns to forward and to which DNS server IP.
Q6: What is the difference between Geolocation and Latency-Based routing?
Geolocation routing directs traffic based on the user's geographic location (country or continent) — a UK user always goes to the EU endpoint regardless of which is actually faster. Latency-based routing directs traffic based on measured network latency — the user goes to whichever AWS Region responds fastest for them. A UK user might have lower latency to US East than EU West depending on network conditions — Latency routing would send them there; Geolocation would not.
Q7: What is Failover routing and when would you use it?
Failover routing designates one record as Primary and another as Secondary. Route 53 monitors the Primary endpoint via health checks. As long as the primary is healthy, all traffic goes there. If the health check fails, Route 53 automatically returns the Secondary record. Used for disaster recovery setups — for example, Primary is a production ALB, Secondary is an S3 static page showing a maintenance message.
Q8: What is the difference between Weighted and Multivalue routing?
Weighted routing sends specific percentages of traffic to specific endpoints — controlled, intentional splits like 90% to production and 10% to canary. Multivalue routing returns up to 8 healthy IP addresses in response to a query, and the client picks one — it's DNS-level distribution with health filtering, not traffic splitting by percentage. Weighted is for deliberate traffic control; Multivalue is for basic resilience by giving clients multiple options.
🔬 Practice Tasks
Hosted Zone lab: Register or transfer a domain to Route 53 (or use an existing one). Create a Public Hosted Zone. Add an A record pointing to an EC2 public IP. Verify DNS resolution works from your browser. Change the IP and observe how long TTL takes to propagate.
Private Hosted Zone: Create a Private Hosted Zone for
internal.localassociated with your VPC. Add an A recordpayment.internal.local → 10.200.1.45. SSH into an EC2 in the VPC and runnslookup payment.internal.local— verify it resolves to the private IP.Split-Horizon: Create both a Public and Private Hosted Zone for the same domain. Add different A records in each. From within the VPC, verify the Private Hosted Zone answer. From your home internet, verify the Public Hosted Zone answer. Confirm they're different.
Weighted routing for canary deployment: Create two A records for the same domain with weights 90 and 10 pointing to different resources. Query the domain repeatedly and track which endpoint is returned — verify approximately 10% of responses point to the new resource.
Failover routing: Create a Primary record pointing to a running EC2 with a health check. Create a Secondary record pointing to a different endpoint. Manually stop the primary EC2. Watch the health check fail in Route 53. Verify that queries now return the Secondary record.
Resolver Endpoints (conceptual exercise): Draw the complete flow for: (a) an on-premises server resolving
app.internal(an AWS Private Hosted Zone), and (b) an EC2 instance resolvingserver.company.local(an on-premises domain). For each, identify which endpoint (Inbound or Outbound) is used and in which direction the DNS query travels.
AWS Session 15 — Amazon Route 53 | Cloud + DevOps learning journey — Systems Engineer → Cloud/DevOps Engineer
Top comments (0)