This practical set covered the core Route 53 DNS and routing concepts through progressively more realistic scenarios.
For the concepts behind these practicals, see the Route 53 session: AWS Route 53 — DNS Fundamentals, Hosted Zones, Routing Policies & Resolvers
Practical 1 — Public Hosted Zone + A Record
Objective
Understand a public hosted zone, create an A record, point it to an EC2 public IP, and understand TTL behavior.
What We Did
- Created a Public Hosted Zone:
route53-lab.example - Route 53 automatically created the
NSandSOArecords. - Created an A record:
www.route53-lab.example → EC2 public IP, TTL60seconds, RoutingSimple. - Used Route 53 → Test record and confirmed
No Error, with the response resolving to the EC2 public IP. - Changed the A record's value and tested again to confirm the update took effect.
Result
The Route 53 record was successfully created and tested.
Important Learning
TTL controls how long a DNS resolver may cache an answer — it does not mean Route 53 itself takes that amount of time to update. Because no real domain was owned or delegated, actual public-browser resolution and real-world TTL propagation could not be tested.
Cleanup
Deleted the custom A record first, then deleted the hosted zone.
Practical 2 — Private Hosted Zone
Objective
Create internal DNS that resolves within an associated VPC.
What We Did
- Created a Private Hosted Zone:
internal.local - Associated it with the VPC containing the EC2 instance.
- Created
payment.internal.local → 10.200.1.45. - SSH'd into the EC2 and ran:
nslookup payment.internal.local
Verified the response:
Server: 172.31.0.2
Address: 172.31.0.2#53
Name: payment.internal.local
Address: 10.200.1.45
Result
Private DNS resolution worked successfully — 172.31.0.2 is the VPC DNS resolver, and it correctly returned 10.200.1.45 as the answer for the record, using the Private Hosted Zone.
Cleanup
Deleted the custom A record and then deleted the private hosted zone.
Practical 3 — Split-Horizon DNS
Objective
Understand how Public and Private Hosted Zones with the same domain can provide different DNS answers.
What We Built
Created both a Public and a Private Hosted Zone using the same domain, split.local — the Private Hosted Zone was associated with the EC2's VPC.
-
Public
www.split.local→13.127.147.3 -
Private
www.split.local→172.31.12.251
Test
From the EC2 inside the VPC:
nslookup www.split.local
Name: www.split.local
Address: 172.31.12.251
The private answer won for the query originating inside the associated VPC. The private A record was then removed and the query repeated — the result was NXDOMAIN, not a fallback to the public zone. This confirmed the private hosted zone continued to take precedence for VPC-originated queries; it simply doesn't have a fallback path to the public zone.
Result
Split-horizon behavior was demonstrated successfully.
Inside the associated VPC → the Private Hosted Zone answers. From public DNS → the Public Hosted Zone answers.
The public side wasn't independently verified from outside the VPC, since the test domain wasn't a real delegated domain.
Cleanup
Deleted the custom records and both hosted zones.
Practical 4 — Weighted Routing / Canary Deployment
Objective
Understand weighted DNS routing and how it can support canary-style releases.
What We Built
Created a Public Hosted Zone (canary-lab.example) with two A records sharing the same name, app.canary-lab.example, both with TTL 60 and Routing Weighted:
| Record | Value | Weight | Record ID |
|---|---|---|---|
| Stable | 13.127.147.3 |
90 | stable |
| Canary | 1.2.3.4 |
10 | canary |
Test
Used Route 53 → Test record repeatedly. 13.127.147.3 came back most of the time, while 1.2.3.4 appeared much less frequently — roughly consistent with the 90/10 split, though not an exact 1-in-10 guarantee on any given batch of queries.
Result
Weighted routing behavior was demonstrated. In production, this pattern supports gradual rollout:
90% old version / 10% new version → monitor → 70/30 → 50/50 → 10/90 → 0/100
Important Distinction
Route 53 weighted routing chooses the endpoint returned in the DNS response — it is not an application-layer proxy and doesn't replace an ALB.
Cleanup
Deleted the weighted records and hosted zone.
Practical 5 — Failover Routing + Health Check
Objective
Configure a primary/secondary DNS failover setup and verify that Route 53 serves the secondary endpoint when the primary becomes unhealthy.
What We Built
Two EC2 instances (Primary and Secondary), each returning a distinct response body (PRIMARY SERVER / SECONDARY SERVER) so the active endpoint could be identified from the response alone.
A Route 53 health check (primary-ec2-health) was created: HTTP, port 80, path /, 30-second interval, failure threshold 3.
A Public Hosted Zone (failover-lab.example) was created with app.failover-lab.example configured as:
-
Primary — A record, Failover = PRIMARY, →
13.127.147.3, health check attached, TTL 60 -
Secondary — A record, Failover = SECONDARY, →
65.0.61.115, TTL 60
Test
With the primary stopped/unhealthy, the Route 53 Test Record result changed to 65.0.61.115, demonstrating the failover path:
Primary unhealthy → Route 53 → Secondary
Result
The primary-to-secondary failover behavior was successfully demonstrated.
Troubleshooting Observation
When the Primary EC2 was started again, the Route 53 health check continued to show Unhealthy, with health-checker details reporting Connection timed out from multiple health-checker locations. Recovery from Secondary back to Primary was therefore not successfully verified in this lab — the issue was connectivity to the public HTTP endpoint, not the failover record configuration itself, which had already demonstrated the secondary path correctly.
Important Learning
Failover routing depends on endpoint health, not merely whether an EC2 instance is powered on. Health-check detection combined with DNS caching/TTL also means client-visible failover isn't necessarily instantaneous.
Cleanup
Deleted the primary/secondary failover records, the hosted zone, the Route 53 health check, and the Secondary EC2. The original EC2 used for other labs was retained.
Practical 6 — Resolver Endpoints (Conceptual)
This practical was kept conceptual rather than deploying Route 53 Resolver endpoints.
Scenario A — On-Premises → AWS Private Hosted Zone
An on-premises server needs to resolve app.internal, where the name exists in an AWS Private Hosted Zone:
On-premises server → on-prem DNS → AWS Resolver Inbound Endpoint → VPC DNS / Private Hosted Zone → AWS private resource
The Inbound Resolver Endpoint receives DNS queries from outside the VPC.
Scenario B — EC2 → On-Premises DNS
An EC2 instance needs to resolve server.company.local, where the authoritative DNS server exists on-premises:
EC2 → VPC DNS → AWS Resolver Outbound Endpoint → network connection to on-premises DNS → on-prem DNS server → DNS response
Key Distinction
Inbound endpoint → DNS queries coming into AWS/VPC from external networks.
Outbound endpoint → DNS queries going out from AWS/VPC to external DNS servers.
Route 53 Core Mental Model
Simple routing: one record → one/simple answer.
Weighted routing: same name, multiple records, weighted distribution — useful for canary releases, gradual migration, and traffic splitting.
Failover routing: primary + health check → healthy routes to Primary, unhealthy routes to Secondary — useful for high availability and disaster recovery.
Private Hosted Zone: VPC → Private Hosted Zone → internal DNS names — useful for internal services, private application endpoints, and service discovery patterns.
Split-Horizon DNS: the same domain name resolves differently depending on whether the query comes from the public view or the private VPC view — useful whenever the same hostname needs to answer differently based on where the requester is.
Core interview mental model:
Public Hosted Zone → Internet-facing DNS
Private Hosted Zone → VPC/internal DNS
Weighted → distribute DNS answers
Failover → choose Primary while healthy, Secondary when unhealthy
Inbound Resolver → queries into AWS
Outbound Resolver → queries from AWS to external DNS
Top comments (0)