AWS Route 53 Hands-On Labs

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

1. Created a Public Hosted Zone: route53-lab.example
2. Route 53 automatically created the NS and SOA records.
3. Created an A record: www.route53-lab.example → EC2 public IP, TTL 60 seconds, Routing Simple.
4. Used Route 53 → Test record and confirmed No Error, with the response resolving to the EC2 public IP.
5. 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

1. Created a Private Hosted Zone: internal.local
2. Associated it with the VPC containing the EC2 instance.
3. Created payment.internal.local → 10.200.1.45.
4. 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:

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