Route 53 & DNS Routing
AWS's DNS service — translating domain names to IP addresses, and routing traffic intelligently based on latency, health, or geography.
Want a visual for this topic?
Generate a diagram tailored to Route 53 & DNS Routing — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain how DNS resolution works and where Route 53 fits in
- •Distinguish A, CNAME, and Alias records and when to use each
- •Choose the right routing policy for a given traffic-distribution need
- •Explain how Route 53 health checks enable automatic failover
What is it?
Amazon Route 53 is AWS's DNS (Domain Name System) web service — it translates human-readable domain names like api.example.com into the IP addresses computers use to connect to each other, and it can also register domain names and manage routing traffic across multiple endpoints based on rules you define.
Why it exists
Every service on the internet is ultimately reached by IP address, but IP addresses are hard to remember and can change (a server gets replaced, a load balancer's IP rotates). DNS exists to give services stable, memorable names that get resolved to the current correct IP address at request time. Route 53 exists specifically because AWS resources' IPs can change (Auto Scaling launches new instances, load balancers use rotating IPs) — you need a DNS layer tightly integrated with AWS to always point at the right place.
Problem it solves
It solves the name-to-address translation problem (so users type example.com, not an IP), the endpoint-change problem (Alias records automatically track a changing AWS resource's address with no manual updates), the traffic-distribution problem (routing policies let you send users to the closest, healthiest, or a weighted split of endpoints), and the failover problem (health checks can automatically redirect traffic away from an unhealthy endpoint).
Intuition
DNS is like a phone book: you look up a name (example.com) and get back a phone number (an IP address) to actually call. Route 53 is a phone book that AWS keeps automatically up to date for you — if your load balancer's number changes, an Alias record means callers automatically get the new number without you having to update the phone book by hand.
Analogy
A company directory that not only tells you a department's extension (a DNS record), but can automatically route your call to whichever branch office is closest to you (latency-based routing), or to a backup office if the primary one isn't answering (health-check-based failover) — all without the caller needing to know any of that routing logic themselves.
Technical explanation
An A record maps a name directly to an IPv4 address. A CNAME record maps a name to another name (an alias for a hostname), but critically cannot be used at a zone's root/apex (e.g. example.com itself) per DNS spec, and always incurs an extra resolution lookup. Route 53's Alias record is an AWS-specific extension that looks like an A record to clients but internally maps to an AWS resource (a Load Balancer, CloudFront distribution, S3 website endpoint) and automatically tracks that resource's current IP with no TTL management needed on your part — and unlike CNAME, Alias records CAN be used at the zone apex, which is why they're strongly preferred for pointing a bare domain at an AWS resource.
Architecture
A typical setup: the root domain (example.com) uses an Alias record pointing at a CloudFront distribution or Application Load Balancer; a subdomain (api.example.com) uses another Alias record pointing at a different ALB; routing policies layer on top — e.g. Latency-based routing across two ALBs in different Regions, each attached to a Route 53 health check, so if one Region's ALB fails its health check, Route 53 automatically stops routing traffic there.
Workflow
- Register or transfer your domain (or use an existing one with Route 53 as the DNS provider). 2) Create a Hosted Zone for the domain. 3) Add records: Alias records for anything pointing at an AWS resource, standard A/CNAME/MX/TXT records for everything else. 4) Choose a routing policy matching your need — Simple for a single endpoint, Weighted for gradual rollouts, Latency-based for global multi-Region apps, Failover for active-passive DR. 5) Attach health checks to critical endpoints so Route 53 can route around failures automatically.
Example
A global SaaS app runs identical stacks in us-east-1 and eu-west-1. Route 53 uses latency-based routing for app.example.com, with a health check on each Region's load balancer: European users get routed to the eu-west-1 endpoint (lower latency) by default, but if that Region's health check starts failing, Route 53 automatically routes European users to us-east-1 instead within the health check's detection window — no manual DNS change needed during the incident.
Real-world usage
Route 53's 100% SLA and deep integration with other AWS services (auto-tracking ALB/CloudFront/S3 endpoints via Alias records) makes it the default DNS choice for AWS-hosted applications; latency-based and geolocation routing policies are commonly used by global consumer apps and CDN-fronted sites to route users to their nearest healthy Region automatically.
Trade-offs
DNS-level failover (Route 53 health checks + routing policies) is simpler to set up across multiple Regions or completely separate infrastructure stacks, but is inherently slower than load-balancer-level failover because of DNS caching — a load balancer within one Region can react in seconds, while a DNS failover might take minutes depending on TTL and resolver caching behavior. For cross-Region resilience, DNS-level failover is usually still the right tool since a load balancer can't span Regions; the tradeoff is accepting that propagation delay as the cost of that broader reach.
Visual explanation
Picture a user's browser asking 'what's the IP for api.example.com?' The request travels: browser → recursive resolver (often the ISP's) → root DNS servers → .com TLD servers → Route 53 (the authoritative name server for example.com) → Route 53 returns the IP (or, for an Alias record, resolves internally to an AWS resource's current IP) → the answer is cached (per the record's TTL) and returned to the browser, which then connects directly to that IP.
Advantages
- —
Alias records track AWS resource IP changes automatically, with no TTL management and no extra cost for the lookup
- —
Multiple routing policies (weighted, latency, geolocation, failover, multi-value) cover most real traffic-distribution needs without extra infrastructure
- —
Health checks enable automated failover without a separate monitoring/failover system
- —
Deep, native integration with ELB, CloudFront, S3, and other AWS resources
Disadvantages
- —
DNS-based failover is not instant — clients and intermediate resolvers cache responses per the record's TTL, so failover takes at least that long to propagate, unlike a load balancer's near-instant health-check response
- —
Complex routing policy combinations (e.g. weighted + latency + failover all layered) can become hard to reason about and debug
- —
DNS changes for records NOT using Alias require careful TTL planning — a high TTL set before a planned migration can leave stale entries cached for a long time
- —
Domain registration and hosted zone costs, while low, add up across many domains/subdomains at scale
Common mistakes
- —
Using a CNAME record at the zone apex (e.g. trying to point example.com itself via CNAME) — this violates the DNS spec; an Alias record must be used instead for AWS resources at the apex
- —
Setting a very high TTL on a record right before a planned cutover or migration, causing stale DNS to be cached by clients and resolvers for far longer than intended
- —
Assuming Route 53 failover is as fast as a load balancer's health check — not accounting for DNS caching delay in a disaster recovery runbook's RTO calculation
- —
Not attaching a health check to a failover routing policy's primary record — without one, Route 53 has no signal to know when to fail over
- —
Forgetting that Alias records are AWS-specific and only work for supported AWS resource types — not a general-purpose CNAME replacement for arbitrary external hostnames
In the AWS Console
- 1
AWS Console → Route 53 → Hosted zones → Create hosted zone
Enter your domain name and choose 'Public hosted zone' for an internet-facing domain.
After creation, Route 53 gives you a set of NS (name server) records — these must be configured at your domain registrar (even if that registrar isn't AWS) for Route 53 to actually control the domain's DNS.
- 2
Hosted zones → [your zone] → Create record
For a record pointing at an AWS resource (ALB, CloudFront, S3 website), toggle 'Alias' to Yes and select the resource from the dropdown instead of typing an IP or hostname manually.
Alias records have no visible TTL setting in the console because AWS manages resolution internally — this is expected, not a missing feature.
- 3
Route 53 → Health checks → Create health check
Point the health check at your endpoint (an IP, domain, or associated with a specific record), set the protocol/path and failure threshold.
Health checks incur a small monthly cost per check and, for HTTPS checks, require the endpoint to be reachable from Route 53's global health-checker network, not just your VPC.
- 4
Hosted zones → [your zone] → Create record → Routing policy
Choose Latency-based, Weighted, Failover, Geolocation, or Multi-value as appropriate, and create one record per endpoint with the same name but a distinct Region/weight/health-check association.
All records participating in one routing policy set must share the same record name and type — Route 53 uses that shared name to group them into one policy.
🎤 Interview questions
What's the difference between a CNAME record and a Route 53 Alias record? (Listen for: CNAME can't be used at the zone apex and adds an extra DNS lookup; Alias can be used at the apex, is AWS-specific, tracks the target resource's IP automatically, and has no extra lookup cost.)
Why is DNS-based failover slower than load-balancer health-check failover? (Listen for: DNS responses are cached by resolvers and clients per the record's TTL; propagation takes at least that long, unlike a load balancer's near-real-time routing decision.)
How would you route users to the AWS Region closest to them, with automatic failover if that Region goes down? (Listen for: latency-based routing policy with a health check attached to each Region's endpoint, so Route 53 stops routing to an unhealthy Region automatically.)
What's the difference between Weighted and Failover routing policies, and when would you use each? (Listen for: Weighted splits traffic by percentage, useful for gradual rollouts/canary testing; Failover is active-passive, sending all traffic to primary unless its health check fails.)
A record was just changed but some users still see the old value — why? (Listen for: DNS caching per the previous TTL at resolvers/clients; the old value remains cached until that TTL expires, regardless of when the record was actually updated.)