DNS and CDN: Route 53, CloudFront, and ACM at the edge
Route 53 + CloudFront + ACM are the edge of the request path. ALIAS at the apex, the right routing policy and TTL, an OAC-locked origin, and a us-east-1 cert turn four moving parts into one fast, fail-over-ready front door.
A team cuts over to a new load balancer on a Friday. The old DNS record had a 24-hour TTL set years ago and never revisited. They flip the record at 10am, watch their own laptops resolve to the new endpoint, and call it done. Then support tickets trickle in all weekend: a slice of users still hitting the dead balancer, resolvers around the world holding the old answer for the full day the TTL promised them. Worse, the apex example.com had been faked into a CNAME with a registrar hack, so half the failover plan was illegal DNS that some resolvers silently dropped. The fix was unglamorous and structural: an ALIAS record at the apex, a 60-second TTL on anything that might move, and a health-checked failover record so the next cutover drains itself. DNS is not configuration you set once — it is the slowest cache in your whole system, and it caches your mistakes.
Route 53: authoritative DNS, ALIAS, and routing policies
Before you pick a routing policy or set a TTL, you need to understand the one record type AWS invented specifically for the zone apex — and why the standard alternative is illegal there.
Route 53 is AWS’s managed authoritative DNS — it answers “what IP is example.com?” for domains whose hosted zone you control. A hosted zone is the container for a domain’s records; it can be public (resolvable on the internet) or private (resolvable only inside associated VPCs, for internal service discovery). Inside it you write the usual record types: A (name to IPv4), AAAA (name to IPv6), CNAME (name to another name), MX, TXT, and so on.
The catch every team hits: you cannot put a CNAME at the zone apex. The apex is the bare domain example.com itself, and the DNS spec forbids a CNAME coexisting with the SOA/NS records that must live there. So you cannot CNAME the apex to a CloudFront or ALB hostname — only a subdomain like www.example.com can be a CNAME. Route 53’s answer is the ALIAS record, an AWS-specific extension. An ALIAS at the apex maps example.com directly to an AWS resource — a CloudFront distribution, an ALB/NLB, an S3 static-website bucket, API Gateway, App Runner — and Route 53 resolves it to the resource’s current IPs at query time. Three things make ALIAS strictly better than a CNAME here: it is legal at the apex, AWS does not charge for ALIAS queries to AWS resources (CNAME queries are billed), and it tracks the target’s IP changes automatically so you never hand-edit an IP.
; Zone apex - ALIAS, not CNAME (a CNAME here is illegal)
example.com. A ALIAS d111abcdef8.cloudfront.net. ; no TTL - uses target's
; Subdomain - a CNAME is fine here
www.example.com. CNAME example.com. ; 300
; Health-checked failover pair (active / passive)
api.example.com. A ALIAS primary-alb.elb.amazonaws.com. ; Failover=PRIMARY + health check
api.example.com. A ALIAS dr-alb.elb.amazonaws.com. ; Failover=SECONDARY
; A record you may need to move - keep TTL low
edge.example.com. A 203.0.113.10 ; 60A routing policy decides which answer Route 53 returns when several records share a name. Simple returns one fixed answer. Weighted splits traffic by integer weights — the canary lever: send 95/5 to a new version, then dial up. Latency-based routes each user to the AWS Region with the lowest measured latency from their resolver. Geolocation routes by the user’s continent/country (compliance, localized content). Failover pairs a primary and secondary record with a health check: when the primary’s health check fails, Route 53 stops returning it and serves the secondary — this is what makes the cutover above drain itself. Multivalue answer returns up to eight healthy records at random, a poor-man’s load balancer with health-aware records. (Route 53 also has geoproximity and IP-based policies.)
▸Why this works
TTL is the whole DNS tradeoff in one number. A resolver caches your answer for TTL seconds and will not ask again until it expires — so a high TTL (say 86400, a day) means fewer queries and lower Route 53 cost, but a failover or cutover takes up to a full day to reach everyone. A low TTL (60s) makes failover and migrations nearly instant but multiplies query volume. The senior move: keep a low TTL on anything that might move or fail over, and drop the TTL days before a planned migration so caches are already short when you flip. For ALIAS-to-AWS-resource records you don’t set TTL at all — Route 53 uses the resource’s default and tracks its IPs for you.
CloudFront and ACM: the cache and the cert
Ask yourself: what does your origin see when 50,000 concurrent users request the same static asset? Without a CDN, every request crosses the Atlantic to your EC2 box. That is the problem CloudFront solves — and OAC is what prevents users from bypassing the CDN to reach the origin directly.
CloudFront is AWS’s global CDN. It runs a fleet of edge locations (points of presence) worldwide; a viewer’s request lands at the nearest edge, which serves from cache if it can and only reaches back to your origin (S3, an ALB, any HTTP server) on a miss. That cuts both latency (bytes come from an edge near the user) and origin load (the edge absorbs the repeat traffic). A distribution has one or more behaviors that map path patterns to origins and cache settings — for example /* to your app origin and /static/* to an S3 origin with a long cache. What CloudFront caches and for how long is governed by the cache key plus TTLs: the origin’s Cache-Control/Expires headers set per-object freshness, bounded by the behavior’s min/default/max TTL. To purge stale content before it expires you issue an invalidation on a path; the first 1,000 invalidation paths per month are free and beyond that they are billed (pricing is region/usage-dependent — see the CloudFront pricing page). You can also run code at the edge: CloudFront Functions for lightweight header/URL rewrites and Lambda@Edge for heavier per-request logic.
To stop people bypassing the CDN and hitting your bucket directly, lock the origin with Origin Access Control (OAC). The S3 bucket stays fully private (public access blocked); its bucket policy grants s3:GetObject to the CloudFront service principal cloudfront.amazonaws.com, scoped by an AWS:SourceArn condition to your specific distribution. Now the only path to the objects is through that distribution — direct s3.amazonaws.com URLs return 403. OAC is the current mechanism and supports all Regions, SSE-KMS, and PUT/DELETE; the legacy Origin Access Identity (OAI) is kept only for migration.
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowCloudFrontOAC",
"Effect": "Allow",
"Principal": { "Service": "cloudfront.amazonaws.com" },
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-private-site/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF2GHIJK"
}
}
}]
}ACM (AWS Certificate Manager) issues free public TLS certificates and auto-renews them, and integrates directly with CloudFront and ALB so you never touch a private key. One hard rule trips everyone: a certificate used for HTTPS between viewers and CloudFront must live in the us-east-1 (N. Virginia) Region, regardless of where your origin runs — CloudFront is a global service and only reads viewer certs from there. (An ACM cert for an ALB lives in the ALB’s own Region.) Put it together and the canonical static-site front door is: Route 53 ALIAS apex to CloudFront, CloudFront terminating TLS with a us-east-1 ACM cert and reaching a private S3 origin via OAC.
| Routing policy | Returns | Health checks? | Reach for it when |
|---|---|---|---|
| Simple | One fixed answer | No | A single resource, no variation |
| Weighted | Answer chosen by integer weight | Optional | Canary / gradual rollout (95/5) |
| Latency-based | Lowest-latency Region for the user | Optional | Multi-Region active-active, speed |
| Geolocation | Answer by user’s country/continent | Optional | Compliance, localized content |
| Failover | Primary, else secondary | Required on primary | Active-passive DR cutover |
| Multivalue | Up to 8 healthy records, random | Per record | Cheap health-aware spread |
You run identical app stacks in us-east-1 and eu-west-1, each behind its own ALB, and you want every user to reach the Region that is fastest for them - while a Region that goes unhealthy stops receiving traffic. Pick the Route 53 routing policy.
You need the bare domain example.com to point at a CloudFront distribution. Which record do you create?
Your CloudFront distribution serves a private S3 bucket via OAC, but people report they can still download objects by hitting the s3.amazonaws.com URL directly. What's wrong?
- 01Why can't you CNAME the apex to CloudFront, what do you use instead, and what three advantages does it give?
- 02Describe the OAC-locked static-site front door end to end, including the TTL and ACM-region gotchas.
The edge of the request path is three managed services working together. Route 53 is authoritative DNS: a hosted zone (public or private) holds your records, and the rule everyone learns the hard way is that a CNAME is illegal at the zone apex, so you use the AWS-specific ALIAS record to point the bare domain at a CloudFront distribution, ALB, or S3 bucket — ALIAS is free for AWS targets, tracks their IPs, and is legal at the apex. A routing policy chooses the answer: simple for one resource, weighted for canaries, latency-based for the nearest Region, geolocation for compliance, failover with health checks for active-passive DR, multivalue for a health-aware spread; and TTL is the dial between fast failover (low) and fewer queries (high), so keep it low on anything that moves. CloudFront caches content at edge points of presence in front of your origin, cutting latency and origin load; behaviors map paths to origins, the cache key plus min/default/max TTL govern freshness, invalidations purge early, and OAC locks a private S3 origin so only your distribution can read it. ACM issues free auto-renewing TLS certs, but the one for CloudFront must live in us-east-1. The senior instinct is to treat DNS as the slowest cache you own — set the apex ALIAS, the right policy, a low TTL, an OAC-locked origin, and a us-east-1 cert, and the front door stays fast and fails over on its own. Now when you plan a cutover, your first move is dropping the TTL days in advance so the cache drains before you flip the record.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.