Route 53, ACM & CloudFront

In one line

Route 53 turns your domain into the right endpoint with health-checked routing; ACM provides free, auto-renewing TLS certificates; CloudFront caches and serves content from edge locations near users while shielding your origins.

0/4 · 0%

Think of it like this

Route 53 is the phone directory telling callers which branch to dial (and skipping branches that are closed). CloudFront is a chain of local convenience stores stocking your most popular products, so customers don't travel to the central warehouse for every purchase.

Key ideas

01
ROUTE 53 hosts DNS zones. ALIAS records point a name (including the zone apex, example.com) at AWS resources — ALBs, CloudFront, S3 websites — for free and follow their IP changes. ROUTING POLICIES: simple, weighted (canaries, migrations), latency-based (nearest region), failover (primary/secondary with HEALTH CHECKS), and geolocation.
02
ACM issues public TLS certificates free, validated by a DNS record, and renews them automatically as long as the validation record stays in place. Certificates for CloudFront must be created in us-east-1; for an ALB, in the ALB's own region.
03
CLOUDFRONT caches responses at hundreds of edge locations. Configure CACHE BEHAVIOURS per path (/static/* cached for a year with hashed filenames, /api/* not cached or briefly), CACHE POLICIES that decide which headers/cookies/query strings form the cache key (fewer = better hit ratio), and INVALIDATIONS when you must purge content.
04
Security at the edge: use ORIGIN ACCESS CONTROL so the S3 bucket is private and only CloudFront can read it; enforce HTTPS; attach AWS WAF (managed rule sets for common exploits, rate limiting per IP) and benefit from AWS Shield Standard's automatic DDoS protection.
05
Also: CloudFront Functions and Lambda@Edge for lightweight request/response logic at the edge (redirects, header manipulation, A/B routing); TTLs and Cache-Control headers from your origin decide how long content stays cached.

Code & diagrams

acm-route53.shbash

# Certificate for CloudFront — must be in us-east-1
aws acm request-certificate --region us-east-1 \
  --domain-name example.com --subject-alternative-names '*.example.com' \
  --validation-method DNS
# Create the CNAME validation record it returns in Route 53; ACM then auto-renews.

# Alias the apex to a CloudFront distribution
aws route53 change-resource-record-sets --hosted-zone-id Z123 --change-batch '{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "example.com", "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z2FDTNDATAQYW2",
        "DNSName": "d111111abcdef8.cloudfront.net",
        "EvaluateTargetHealth": false
      }
    }
  }]
}'

# Deploy new static assets, then purge the HTML entry point only
aws s3 sync ./dist s3://acme-web --delete
aws cloudfront create-invalidation --distribution-id E123 --paths /index.html

EdgeArchitecturediagram

Rendering diagram…

Explain it without notes

Why can't you use a CNAME at the zone apex, and what does Route 53 offer instead?

Your static site's JS files are named app.js and users keep getting old versions after deploys. What's the fix?

Practice

Design DNS for an API running in two regions where users should hit the nearest healthy region.

Your S3 website bucket is public so CloudFront can read it. How do you lock it down?

Trade-offs

↔
Long cache TTLs deliver the best speed and origin offload but make mistakes stick around until they expire or are invalidated; short TTLs keep content fresh at the cost of more origin traffic. Hashed asset filenames get you both for static content.

Done when you can

I use alias records and know Route 53's routing policies.
I issue ACM certificates in the right region and let them auto-renew.
I serve S3 content privately through CloudFront with OAC.
I design cache behaviours and invalidate only what's necessary.