Route 53 Basics Every DevOps Engineer Should Know

DNS is the one system everyone uses and nobody wants to own. Until something breaks — a cert won't issue, a migration won't go live, traffic lands on a dead server — and suddenly it's your job.

I've moved enough domains to know the mechanics cold. Here's the DNS I actually use in production, stripped of the parts that don't come up.

Records you'll touch weekly

A/AAAA — name to IPv4/IPv6 address. Still what most hard-coded setups expect.

CNAME — name to another name. Cannot sit at the zone apex (the naked domain) — that limitation drives half the weird tricks in modern DNS. www can be a CNAME; example.com classically cannot.

Alias — Route 53's own extension: points a name at AWS resources (ALB, CloudFront, S3 website, another zone record) and can sit at the apex. Alias records resolve to the target's IPs without a separate lookup and don't charge for queries that hit AWS targets. For anything fronting an ALB or CloudFront, Alias is the right answer.

TXT — arbitrary text, which means: domain verification, SPF/DKIM for email, and the ads.txt-style verifications every SaaS tool asks for eventually.

MX — mail routing. Get the priority order wrong and email silently goes nowhere for a week.

TTL is a decision, not a default

Time To Live says how long resolvers cache an answer. AWS default is often 300 seconds; many providers ship 3600 or 86400.

The lesson I learned the hard way during a migration: lower the TTL a day before the cutover, not during it. If TTL is 3600 and you flip the record at 2 PM, half the world is still walking to the old IP for up to an hour — while you're staring at a browser that happens to have the new answer.

My cutover ritual:

T-24h: drop TTL to 60s on the record you're about to change.
T-0: change the record.
T+24h: raise TTL back — everyone who matters has the new answer, and you stop paying for the high lookup rate.

Health checks and the routing policies

Route 53 can route based on more than "one answer." The ones worth knowing:

Simple — one record, one answer (or round-robin among values). Boring and fine for a single stable target.

Weighted — split traffic by proportion. Useful for canary percentages or gradual migration: 90% old, 10% new, watch, then 50/50, then flip.

Latency-based — answer with the region that gives the user the lowest latency. Requires resources in multiple regions.

Failover — primary record plus a secondary, with a health check on the primary. Health check fails → Route 53 answers with the secondary. This is how you point apex traffic at a static "we're down, here's the status page" bucket when the app dies.

Health checks themselves can be HTTP(S) endpoints, TCP, or calculated (aggregating other checks to avoid flapping). They run from multiple global locations — a single AZ blip won't trigger failover if the ALB still answers, which is exactly the behavior you want.

Things that bite during cutovers

The DNS is fine, the propagation isn't. Before assuming DNS is broken: dig +trace yourdomain.com and query a couple of public resolvers directly (dig @1.1.1.1). If they disagree with your authoritative answer, it's cache — wait out the TTL you forgot to lower.
HTTPS comes after DNS. Certificates validate against the new name only after DNS resolves correctly. If Let's Encrypt or ACM can't see your record yet, the cert fails even though the site works for you. Order: DNS right → wait for propagation → then certificate.
CNAME at apex fights your mail. MX and CNAME can't coexist at the same name. Apex Alias records avoid this headache entirely.
NS record changes are the nuclear option. Moving a domain to different nameservers propagates on the parent registry's slow clock — up to 48 hours. Changing records inside the correct zone is minutes. Know which one you're actually doing.

Write it down while it's calm

Every domain we own now has a one-page note: registrar, zone provider, critical records, TTL strategy, who owns the account, and the break-glass path. It takes ten minutes to write during a quiet Friday and saves an hour of archaeology during the next migration.

DNS rewards people who are boring on purpose. Lower the TTL first, change the record second, raise the TTL last — in that order, every time.