Route 53, CloudFront, DNS, and TLS

Route 53, CloudFront, DNS, and TLS are the front door of many AWS workloads. Route 53 answers name lookups, CloudFront terminates viewer connections at edge locations, DNS record choices decide where clients are sent, and TLS certificates prove that the endpoint is allowed to serve the requested hostname. The outcome is concrete: a user types www.example.com, receives a valid DNS answer, opens an encrypted HTTPS connection, and reaches the correct origin through a path you can diagnose.

This lesson connects the networking section of the AWS Cloud Engineering course to the services users actually touch first. VPCs, subnets, load balancers, and compute can be perfectly configured, but a stale DNS record, wrong certificate Region, or mismatched CloudFront alternate domain name can still make the application unreachable.

How the Pieces Work Together

DNS is a distributed lookup system. A browser asks a recursive resolver for a name. The resolver follows delegation from the root zone to the top-level domain and then to the authoritative name servers for the domain. In Route 53, a public hosted zone contains authoritative records such as A, AAAA, CNAME, NS, SOA, MX, and TXT. Each record has a time to live, or TTL, which tells resolvers how long they may cache the answer.

Route 53 alias records are AWS-specific DNS records that point at selected AWS resources, including CloudFront distributions, Application Load Balancers, API Gateway custom domains, and S3 website endpoints. An alias can live at the zone apex, such as example.com, where a normal CNAME is not allowed. Alias records do not charge per query in the same way as ordinary records when they target supported AWS resources, and Route 53 evaluates them to the current target addresses.

CloudFront is a content delivery network and reverse proxy. A distribution has viewer settings, one or more origins, cache behaviors, cache policies, origin request policies, response headers policies, and optional functions or Lambda@Edge associations. The viewer connection is the browser-to-CloudFront side. The origin connection is the CloudFront-to-your-application side. These two sides can have different TLS policies, headers, ports, and caching rules.

TLS binds a hostname to a certificate. For CloudFront viewer certificates, AWS Certificate Manager certificates must be issued in us-east-1, because CloudFront is a global service whose viewer certificate control plane uses that Region. The certificate must cover every alternate domain name configured on the distribution, either directly, such as www.example.com, or with a valid wildcard, such as *.example.com. CloudFront uses SNI during the TLS handshake so it can present the certificate matching the hostname requested by the client.

Configuration Anatomy

A minimal public setup has four decisions. First, the domain is delegated to the hosted zone name servers. Second, an ACM public certificate validates domain control, usually by adding CNAME validation records in Route 53. Third, the CloudFront distribution lists the hostname in Aliases and attaches the issued certificate. Fourth, Route 53 publishes an alias A record, often with an alias AAAA record too, pointing the hostname at the CloudFront distribution.

Layer Important field Why it matters
Route 53 hosted zone NS records Parent-domain delegation must point to these authoritative servers.
DNS record Name, Type, TTL, target Controls which clients resolve, how, and how long stale answers may persist.
ACM certificate Subject alternative names Every CloudFront alias needs certificate coverage.
CloudFront behavior Path pattern, cache policy, origin request policy Determines caching, forwarding, and which origin handles each request.
CloudFront origin Domain name, protocol policy, origin host header Controls how edge locations reach the application.

Example 1: Read DNS Resolution

Start with a read-only DNS check. This example asks a resolver for www.example.com and shows the answer chain. The expected behavior is not a specific IP address, because CDN addresses change, but the answer should include either an alias-resolved address for A or a canonical CloudFront name when querying CNAME for a non-apex hostname.

set -euo pipefail
DOMAIN=www.example.com

dig +short "$DOMAIN" A
dig +short "$DOMAIN" AAAA
dig +trace "$DOMAIN" A

If the first command returns addresses, clients can find IPv4 targets. If the second returns addresses, IPv6 clients can use them. The trace output shows whether delegation reaches the authoritative name servers. When the trace stops before the hosted zone, the problem is usually registrar delegation rather than CloudFront.

Example 2: Route 53 Alias to CloudFront

A Route 53 alias record maps the friendly hostname to the distribution without hard-coding edge IP addresses. In the AWS CLI, CloudFront aliases use the CloudFront hosted zone identifier and the distribution domain name. The following command is a shape example: it parses as Bash, but the placeholder values must be replaced before use.

set -euo pipefail
HOSTED_ZONE_ID=Z1234567890EXAMPLE
RECORD_NAME=www.example.com
DISTRIBUTION_DOMAIN=d111111abcdef8.cloudfront.net
CLOUDFRONT_ZONE_ID=Z2FDTNDATAQYW2

aws route53 change-resource-record-sets \
  --hosted-zone-id "$HOSTED_ZONE_ID" \
  --change-batch "{\"Changes\":[{\"Action\":\"UPSERT\",\"ResourceRecordSet\":{\"Name\":\"$RECORD_NAME\",\"Type\":\"A\",\"AliasTarget\":{\"HostedZoneId\":\"$CLOUDFRONT_ZONE_ID\",\"DNSName\":\"$DISTRIBUTION_DOMAIN\",\"EvaluateTargetHealth\":false}}}]}"

The deterministic output from a successful request includes a change identifier and status, initially often PENDING. Route 53 then propagates the authoritative change. Recursive resolvers may still serve older cached records until their previous TTL expires.

Example 3: Verify TLS and CloudFront Behavior

DNS success does not prove HTTPS success. This example checks the certificate subject information, the HTTP status, and common CloudFront headers. A correct deployment returns a certificate valid for the hostname, an HTTP response from the expected application, and headers such as x-cache that show whether the response was a cache hit or miss.

set -euo pipefail
DOMAIN=www.example.com

openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:443" </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

curl -I "https://$DOMAIN/"

Expected certificate output includes a not-before and not-after validity window and an issuer from a trusted certificate authority. The curl headers may include x-cache: Miss from cloudfront on a first request and Hit from cloudfront after the object is cached. Dynamic applications may intentionally remain misses if the cache policy disables caching or forwards request-specific headers.

Design Choices and Trade-offs

Choose low TTLs when you expect migration or incident response, because resolver caches will refresh sooner. Choose higher TTLs for stable records to reduce lookup load and improve client-side resilience during brief authoritative DNS issues. TTL is not a traffic switch with instant effect; it is a cache instruction that applies after existing cached answers expire.

Use CloudFront in front of public HTTP workloads when global latency, TLS centralization, DDoS absorption, static asset caching, response header control, or edge routing matters. Direct Application Load Balancer DNS names are simpler for internal tools or Region-bound services where edge caching adds little. CloudFront adds configuration surfaces: cache keys, invalidations, origin headers, signed URLs, custom error responses, and WAF integration.

Decide carefully which request values become part of the cache key. If you include every cookie, query string, and header, cache hit ratio can collapse. If you include too few, one user’s personalized response can be served to another user. Static files usually need a small cache key and long object TTLs with versioned filenames. APIs often need no caching or very narrow caching with explicit headers.

Failure Modes and Troubleshooting

Symptom: DNS returns no answer. The usual causes are missing records, wrong hosted zone, or registrar delegation to different name servers. Diagnose with dig +trace, inspect the hosted zone NS records, and compare them with the parent domain’s delegation. Correct by updating registrar name servers or creating the record in the authoritative hosted zone.

Symptom: the browser reports a certificate name mismatch. CloudFront may not have the hostname in its alternate domain names, or the attached ACM certificate may not cover it. Check the distribution aliases, certificate subject alternative names, and certificate Region. Correct by requesting or attaching a certificate in us-east-1 that covers the hostname, then deploy the distribution change.

Symptom: CloudFront returns 403. Possible causes include an S3 origin without Origin Access Control, a WAF block, a behavior that forwards to the wrong origin, or an origin rejecting the Host header. Check CloudFront standard logs or real-time logs, WAF sampled requests, and the origin access logs. Correct the origin permission, behavior path pattern, WAF rule, or origin request policy.

Symptom: updates are invisible after deployment. The object may be cached at CloudFront, in a browser, or in an intermediate proxy. Inspect cache-control, etag, age, and x-cache headers. Correct by using versioned asset names for normal releases or CloudFront invalidations for urgent replacement.

Security, Performance, and Reliability

For security, redirect HTTP to HTTPS at CloudFront, use modern TLS policies, restrict origin access so clients cannot bypass CloudFront, and attach AWS WAF when request filtering is required. Keep DNS change permissions narrow; the ability to alter hosted zone records can redirect production traffic.

For performance, cache static assets with long lifetimes and immutable versioned names. Compress text responses, allow HTTP/2 or HTTP/3 where suitable, and avoid forwarding unnecessary headers or cookies. For reliability, use health checks and failover records only when the failure signal matches user impact. A health check against a shallow endpoint can route traffic away from a healthy service or keep traffic on a broken one.

Hands-on Lab

Prerequisites: an AWS account, AWS CLI credentials with scoped permissions for Route 53, ACM, and CloudFront, a domain delegated to Route 53, and a simple HTTPS origin such as an Application Load Balancer or S3 static website fronted through secure origin access. Use a non-production subdomain such as lab.example.com.

  1. Request an ACM public certificate in us-east-1 for the lab hostname and choose DNS validation.
  2. Create the validation records in the Route 53 hosted zone and wait until ACM marks the certificate issued.
  3. Create a CloudFront distribution with the origin domain, add the lab hostname as an alternate domain name, attach the issued certificate, and set viewer protocol policy to redirect HTTP to HTTPS.
  4. Create Route 53 alias A and, if desired, alias AAAA records from the lab hostname to the CloudFront distribution.
  5. Verify DNS with dig +short lab.example.com A, verify TLS with openssl s_client -servername lab.example.com -connect lab.example.com:443, and verify HTTP behavior with curl -I https://lab.example.com/.
  6. Change a static object at the origin, request it twice, and compare x-cache and age headers. If needed, create an invalidation for that path and verify that the next request fetches the new object.

Cleanup: delete the Route 53 lab alias records, disable and delete the CloudFront distribution when it finishes deploying the disabled state, remove validation records that are no longer needed, and delete the lab certificate if no distribution uses it. Roll back by restoring the previous Route 53 record set from change history or infrastructure-as-code state.

Assessment Exercises

  1. A team creates a CloudFront distribution for app.example.com, but HTTPS shows a certificate for *.cloudfront.net. Explain the likely missing configuration and how to verify it.
  2. You are moving www.example.com from an ALB alias to CloudFront tomorrow. What TTL and rollout sequence would reduce user-visible risk, and what would still not be instant?
  3. An API behind CloudFront sometimes returns one user’s dashboard to another user. Which cache policy and origin request policy settings would you inspect first, and why?
  4. dig +trace reaches name servers that are not listed in your Route 53 hosted zone. Where is the fault, and what record change in Route 53 will not fix it?
  5. A static CSS file remains old after a deployment. Compare using a CloudFront invalidation with using versioned filenames for every release.

Summary

Route 53 supplies authoritative DNS records, CloudFront provides the global HTTPS edge, DNS TTL controls resolver caching, and TLS certificates prove hostname ownership during connection setup. Reliable AWS publishing comes from aligning all four layers: delegate the domain correctly, validate and attach the right certificate, configure CloudFront aliases and cache behavior deliberately, and point DNS records at the distribution with records you can test and roll back.