07 — Route 53: DNS Plus Traffic Steering in One Service

"Just DNS, the thing that points a name at an IP" made Route 53 sound boring — and I was missing the half that isn't boring. The shape that landed: Route 53 is a managed DNS service whose records live in hosted zones, and whose real power is a set of routing policies that turn the DNS answer into a traffic-steering decision, with health checks that fail over without me touching anything [1]. The "53" is the port DNS speaks. Once I saw routing policies and health checks as the part that's more than DNS, the service stopped being boring.

Hosted zones: the container for records

A hosted zone is a container for the DNS records of one domain — example.com, say [2]. When I create one, Route 53 assigns it a set of name servers and an SOA record; I then point my registrar at those name servers so Route 53 becomes authoritative for the domain.

Inside a hosted zone I create records, each mapping a name and type to a value:

• A — name to IPv4 address.
• AAAA — name to IPv6 address.
• CNAME — name to another name (an alias).
• MX — mail exchange.
• TXT — arbitrary text (used for verification, SPF, DKIM).

The non-obvious AWS-specific record type is the Alias record: it points at an AWS resource (a load balancer, a CloudFront distribution, an S3 bucket website) and Route 53 tracks the resource's changing IPs internally, for free. For anything that resolves to an AWS resource, Alias beats CNAME.

Routing policies: the traffic-steering layer

This is the part that's more than DNS. A routing policy decides which answer Route 53 returns when there are multiple candidates, and the choice reshapes the traffic [3]:

• Simple — one answer. The default; for a single resource.
• Weighted — split traffic by percentage across multiple resources. "10% to the new version, 90% to the old." Canary releases without a load balancer.
• Latency — return the answer with the lowest network latency to the caller. Spins up the same app in multiple regions and lets DNS send each user to the closest one.
• Failover — active/passive. Serve the primary; if its health check fails, serve the backup. DNS-level disaster recovery.
• Geolocation — answer based on where the user is. "EU users get the EU endpoint" for data residency.
• Geoproximity — answer based on where my resources are, with optional bias to shift traffic between regions.
• Multivalue answer — return up to eight healthy records, randomly ordered. A poor-person's load balancer at the DNS layer.

The shift in my head: DNS is no longer "one name, one IP." With the right policy, the same name returns different answers to different callers, or changes its answer when something breaks.

Health checks: the failover engine

Health checks are how Route 53 knows a resource is down [4]. I point a health check at an endpoint (an HTTP URL, a TCP port, another health check, or a CloudWatch alarm); Route 53 polls it from globally distributed locations at an interval I choose. If it fails, the health check goes "unhealthy," and any failover or multivalue record associated with it stops returning that endpoint.

The pattern this enables is DNS-level failover: I stand up my app in two regions, create two records under the same name (primary + secondary) with a failover routing policy, attach a health check to the primary, and Route 53 serves the primary while it's healthy and automatically flips to the secondary when it isn't. No load balancer, no manual DNS edit. The trade-off worth remembering: DNS answers are cached (by resolvers and by clients) according to the record's TTL, so failover is not instant — a low TTL (60s) makes failover faster but increases query volume and cost.

The whole failover loop is DNS + health check + TTL, and the only moving part I own is wiring them together.

How I use this

Route 53 is the front door of almost every AWS-hosted app I run. My standing setup: a hosted zone per domain, an Alias record from the apex (example.com) straight to the load balancer (which CNAME cannot do for a zone apex — Alias can), and a TTL low enough to make any future change bearable (60–300s). Weighted routing is my cheapest canary-deploy tool — I shift 5% of DNS answers to a new stack and watch the metrics before going further. Failover across regions is the disaster-recovery pattern I document but hope never to need, and I keep the TTL short on those records so the flip actually reaches users in minutes rather than hours. DNS is rarely the exciting part, but getting it right is what makes the rest of the stack reachable.

References

[1] Amazon Web Services, "What is Amazon Route 53," 2024. [Online]. Available: https://aws.amazon.com/route53/

[2] Amazon Web Services, "Working with hosted zones," Route 53 Developer Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html

[3] Amazon Web Services, "Choosing a routing policy," Route 53 Developer Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html

[4] Amazon Web Services, "Route 53 health checks," Route 53 Developer Guide, 2024. [Online]. Available: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html