Amazon Route 53

5 min read index source

Amazon Route 53

Managed DNS plus health checking and traffic routing. “Route 53” = port 53 (DNS) + the idea of routing. For a backend role, the interview points are routing policies, alias records, and health-check-driven failover.

Hosted zones

A hosted zone is a container for the DNS records of a domain.

Public hosted zone Private hosted zone
Resolvable from the internet only within associated VPCs
Use for your public domain internal service discovery (db.internal.mycompany.com)

You can have both for the same domain — “split-horizon DNS”: api.example.com resolves to a public ALB from the internet, and to a private ALB from inside the VPC.

Record types

The ones that matter:

  • A / AAAA — name → IPv4 / IPv6 address.
  • CNAME — name → another name. Cannot be set on the zone apex (the root example.com).
  • Alias — Route 53-specific; name → an AWS resource (ALB, CloudFront, S3 website, API Gateway, another Route 53 record). Works at the apex, and it’s free to query.
  • MX, TXT, NS, SOA, SRV, CAA — mail, verification, delegation, etc.

Alias vs CNAME — the classic question

CNAME Alias
Apex domain (example.com) not allowed allowed
Points to any hostname AWS resources (+ other Route 53 records)
Query cost charged free
Resolution extra DNS lookup hop resolved within Route 53

Use Alias for AWS resources — it works at the apex, it’s free, and it’s faster (no extra hop). Use CNAME only for non-AWS targets on non-apex names.

Routing policies

This is the main interview content — Route 53 isn’t just name→IP, it’s a traffic router.

Policy Behavior
Simple one record, one or more values; returns them (client picks)
Weighted split traffic by assigned weights — 90/10 for canary releases, gradual migrations
Latency-based route to the AWS region with the lowest latency for that client
Failover primary + secondary; health check on the primary; if it fails, return the secondary (active-passive DR)
Geolocation route by the user’s location — compliance (“EU users to EU”), localized content
Geoproximity route by geographic distance between user and resource, with an adjustable “bias” to expand/shrink a region’s pull
Multivalue answer return up to 8 healthy records at random — a poor man’s load balancer with health checking, at the DNS layer

Common uses:

  • Weighted — blue/green and canary at the DNS level; shift 5% → 50% → 100% of traffic.
  • Latency-based — multi-region active-active; each user hits their nearest region.
  • Failover — active-passive DR; primary region’s health check fails → DNS flips to the standby.
  • Geolocation — data residency, “users in Germany must hit the Frankfurt deployment.”

Health checks

Route 53 health checks monitor an endpoint (HTTP/HTTPS/TCP) or the state of a CloudWatch alarm, or the status of other health checks (calculated health checks).

They drive routing:

  • Failover routing — primary record is associated with a health check; if unhealthy, Route 53 serves the secondary.
  • Multivalue / weighted — unhealthy records are dropped from the responses.

Health checks live outside any one region (they’re checked from multiple AWS locations), so they can detect a whole-region failure and flip DNS to a healthy region — the foundation of DNS-level DR.

Primary (us-east-1 ALB)  ← health check
       │ healthy → serve this
       │ unhealthy → serve secondary
Secondary (us-west-2 ALB)

Caveat: DNS TTL governs how fast clients pick up the change. A 60s TTL means up to a minute of clients still hitting the dead endpoint after the health check flips. Lower TTLs = faster failover, more DNS queries. Some resolvers and clients ignore low TTLs anyway — DNS failover is “fast-ish,” not instant.

DNSSEC

Signs your DNS records so resolvers can verify they weren’t tampered with in transit (defends against DNS spoofing / cache poisoning). Route 53 supports DNSSEC signing for public hosted zones. Adds operational complexity (key management); enable it when you have a compliance or security requirement for it, not by default.

Route 53 Resolver

For hybrid DNS — connecting AWS DNS to on-prem DNS:

  • Inbound endpoints — let on-prem servers resolve names in your private hosted zones.
  • Outbound endpoints — let resources in your VPC resolve names in your on-prem DNS.

Relevant when you’re integrating a VPC with a corporate network; not something a pure-cloud backend touches often.

Common gotchas

  • CNAME at the apex — not allowed by the DNS spec; use an Alias record instead.
  • DNS TTL vs failover speed — failover is only as fast as the TTL lets clients re-resolve; and some clients cache beyond TTL. DNS failover isn’t instant.
  • Health check on the wrong thing — health-checking / instead of a real /healthz that exercises dependencies can keep “healthy” while the app is actually broken.
  • Forgetting to associate the health check with the record — a health check that isn’t attached to a failover record does nothing for routing.
  • Geolocation gaps — if no rule matches a user’s location and there’s no default record, they get no answer; always set a default.
  • Private hosted zone not associated with the VPC — records won’t resolve from instances; you must associate the zone with each VPC.

Interview angle

  • “Alias vs CNAME?” — Alias is Route 53-specific, points to AWS resources, works at the zone apex, and is free to query. CNAME can’t be used at the apex, points to any hostname, and is charged. Use Alias for AWS resources.
  • “How would you do a canary release at the DNS level?” — weighted routing policy: two records, shift weights 95/5 → 50/50 → 0/100 as you gain confidence. Combine with health checks so an unhealthy target drops out.
  • “How does Route 53 do regional failover?” — failover routing policy: primary record tied to a health check, secondary as the fallback. Health checks run from outside any single region, so a whole-region outage flips DNS to the standby. Failover speed is bounded by the DNS TTL.
  • “Latency-based vs geolocation routing?” — latency-based routes to the region that’s lowest-latency for the client (performance). Geolocation routes by the client’s physical location (compliance, data residency, localized content). They answer different questions.
  • “What’s the limitation of DNS-based failover?” — it’s only as fast as clients re-resolve, governed by TTL — and some clients/resolvers cache past the TTL. It’s “fast-ish” DR, not instant; for instant failover you need something at the connection layer (e.g., a load balancer with health-checked targets).
  • “Public vs private hosted zone?” — public is internet-resolvable (your real domain); private resolves only within associated VPCs (internal service names). Split-horizon DNS uses both for the same name — public callers get the public endpoint, in-VPC callers get the private one.