CloudFront Cache — Why Deploys Never Reach Users

Every second of load time costs you users. Amazon's own research found that a 100ms delay reduces sales by 1%. If your app is hosted in a single AWS region — say us-east-1 — every user outside the US East Coast is experiencing that penalty multiplied.

CloudFront and Route 53 solve two distinct problems. CloudFront is a CDN — it caches content at over 450 edge locations so users never have to reach all the way back to your origin. Route 53 is DNS — it translates domain names to IP addresses, but goes far beyond basic DNS with latency-based, geolocation, and failover routing.

This article covers the three rules that make CDN+Route53 work in production: versioned filenames over invalidation, alias records over CNAMEs, and always attaching health checks to failover records. Miss a rule and your users see stale content or your failover never triggers.

CloudFront + Route 53 Integration — The Global Delivery Stack

CloudFront and Route 53 solve different problems. CloudFront is a CDN — it caches content at edge locations and serves users from the nearest edge. Route 53 is DNS — it translates domain names to IP addresses, but AWS's version goes far beyond basic DNS with latency-based, geolocation, weighted, and failover routing.

Together, they form the global delivery stack: Route 53 directs the user's DNS query to the closest CloudFront edge (latency-based routing). The user's browser then connects to that CloudFront edge. CloudFront serves the content from its cache if available; otherwise, it fetches from the origin (S3, EC2, ALB, or custom HTTP server).

Why this matters: A SaaS company hosted only in us-east-1 with no CloudFront saw 2.5s load times in Australia. After adding CloudFront with a simple cache-all policy, load times dropped to 400ms. That's not theoretical — it's the kind of improvement that directly impacts revenue.

The real value isn't just speed. It's resilience. When your origin goes down in us-east-1, CloudFront can still serve stale content from its cache for hours. That's the difference between a 5-minute outage and a non-event. Route 53's health checks then detect the failure and reroute new requests to a replica in another region.

#!/bin/bash
# io.thecodeforge/cloudfront_invalidation.sh
# Create CloudFront invalidation for a distribution

DISTRIBUTION_ID="E1ABC123XYZ"

# Invalidate entire distribution (use carefully in production)
echo "Creating invalidation for distribution: ${DISTRIBUTION_ID}"
aws cloudfront create-invalidation \
  --distribution-id "${DISTRIBUTION_ID}" \
  --paths '/*'

# Invalidate specific files or directories
aws cloudfront create-invalidation \
  --distribution-id "${DISTRIBUTION_ID}" \
  --paths '/index.html' '/static/css/*' '/static/js/app.js'

# Check cache hit ratio from CloudWatch
aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront \
  --metric-name CacheHitRate \
  --statistics Average \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --dimensions Name=DistributionId,Value="${DISTRIBUTION_ID}"

echo "Invalidation created. Use 'aws cloudfront get-invalidation --id <ID>' to track progress."

Route 53 Routing Policies: Latency, Geolocation, and Failover

Route 53 offers several routing policies that go far beyond simple DNS resolution.

Latency-based routing: Route 53 measures round-trip time between the user's resolver and each AWS region where you have an endpoint. It returns the IP of the region with the lowest latency. Ideal for active-active setups where you want automatic performance optimisation.

Geolocation routing: Routes users based on their geographic origin (continent, country, or state). Useful for compliance (GDPR privacy notice for EU users) or content localization (different pricing per country). Note: geolocation uses requestor's IP, not DNS resolver location.

Weighted routing: Distributes traffic across multiple endpoints based on assigned weights. Great for canary deployments (1% traffic to new version) or A/B testing.

Failover routing: Works with Route 53 health checks. If the primary endpoint fails health check, Route 53 returns the secondary endpoint's IP. Ensure health check intervals are short enough for your desired RTO.

Production nuance: DNS caching at ISPs can override Route 53 decisions. Set TTL low (60s) for latency and failover records to respond quickly to network changes.

Another nuance: latency-based routing works at the resolver level, not the end user. If a user's corporate DNS resolver is in Virginia but the user is in Europe, they get routed based on Virginia's latency. That's why geolocation can be more predictable for compliance use cases.

{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.yourapp.com.",
        "Type": "A",
        "SetIdentifier": "primary-us-east-1",
        "Failover": "PRIMARY",
        "AliasTarget": {
          "HostedZoneId": "Z2FDTNDATAQYW2",
          "DNSName": "d123.cloudfront.net.",
          "EvaluateTargetHealth": true
        }
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.yourapp.com.",
        "Type": "A",
        "SetIdentifier": "secondary-eu-west-1",
        "Failover": "SECONDARY",
        "AliasTarget": {
          "HostedZoneId": "Z2FDTNDATAQYW2",
          "DNSName": "d456.cloudfront.net.",
          "EvaluateTargetHealth": true
        }
      }
    }
  ]
}

Custom Domain Setup: SSL Certificates, Regions, and Aliases

To serve your app via CloudFront with a custom domain, you need three pieces that must match exactly.

SSL/TLS certificate must be in ACM (AWS Certificate Manager) in the us-east-1 region — even if your origin is elsewhere. CloudFront operates globally but validates certificates from us-east-1 only. The certificate must include all alternate domain names you plan to use (e.g., example.com and www.example.com).

CloudFront distribution must have the custom domain listed in Alternate Domain Names (CNAMEs). This tells CloudFront which domain names to accept traffic for and which certificate to use.

Route 53 alias record pointing to the CloudFront distribution's DNS name (e.g., d123.cloudfront.net). Alias records are free, work at the zone apex, and support health evaluation.

The trap that catches everyone: ACM certificate in eu-west-1 (where your EC2 is) works for ALB but fails for CloudFront. The error message is cryptic: 'The specified SSL certificate doesn't exist, isn't in us-east-1, or doesn't match the alternate domain names'. Always request CloudFront certificates in us-east-1.

Also: if you change the CloudFront distribution (e.g., add a new origin), edge locations can take 10-20 minutes to propagate the configuration. Plan a maintenance window for changes that affect routing.

#!/bin/bash
# Step 1: Request certificate in us-east-1 (NOT your origin region)
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names www.example.com \
  --validation-method DNS \
  --region us-east-1

# Step 2: Create CloudFront distribution with custom domain
aws cloudfront create-distribution \
  --origin-domain-name myapp.s3.amazonaws.com \
  --default-root-object index.html \
  --aliases 'www.example.com,example.com' \
  --viewer-certificate "{\"ACMCertificateArn\":\"arn:aws:acm:us-east-1:123456789:certificate/abc-123\",\"SSLSupportMethod\":\"sni-only\",\"MinimumProtocolVersion\":\"TLSv1.2_2021\"}" \
  --default-cache-behavior '{"TargetOriginId":"myapp","ViewerProtocolPolicy":"redirect-to-https","Compress":true}'

# Step 3: Create Route 53 alias record
# Use the distribution domain name from the create-distribution output
# dXXX.cloudfront.net
aws route53 change-resource-record-sets --hosted-zone-id Z123456 --change-batch file://alias.json

Security: Origin Access Control, WAF, and Signed URLs

CloudFront provides several security layers beyond basic TLS.

Origin Access Control (OAC) — restricts access to your S3 origin so that only CloudFront can fetch objects. OAC replaces the older Origin Access Identity (OAI) and is strongly preferred for new distributions. You attach an OAC to the distribution's origin and update the bucket policy to allow requests signed by that OAC. OAC supports server-side encryption with KMS; OAI does not.

AWS WAF integration — associate a Web ACL with your CloudFront distribution to block malicious traffic (SQL injection, XSS, IP reputation lists, rate limiting) before it reaches your origin. WAF rules are applied at the edge, reducing origin load. WAF costs scale with request volume, so use rate-based rules to limit costs.

Signed URLs and Signed Cookies — for premium content, generate time-limited URLs that CloudFront verifies using a private key. Signed URLs are per-file; Signed Cookies apply to a set of files. Generate short expiration (minutes to hours) and combine with IP restrictions for defense in depth.

Field-Level Encryption — encrypts sensitive data (credit card numbers, PII) before sending to the origin, so even the origin cannot read the raw data. The origin receives only the encrypted value.

Real risk: If you use OAI instead of OAC, you cannot use AWS KMS to encrypt objects at rest in S3. Always choose OAC for new distributions.

#!/bin/bash
# Create Origin Access Control (OAC) for S3 origin
# OAC replaces legacy Origin Access Identity (OAI)

# Step 1: Create OAC
OAC_ID=$(aws cloudfront create-origin-access-control \
  --origin-access-control-config "{
    \"Name\": \"MyAppOAC\",
    \"Description\": \"OAC for myapp S3 bucket\",
    \"SigningProtocol\": \"sigv4\",
    \"SigningBehavior\": \"always\",
    \"OriginAccessControlOriginType\": \"s3\"
  }" \
  --query 'OriginAccessControl.Id' \
  --output text)

echo "Created OAC: ${OAC_ID}"

# Step 2: Update bucket policy to allow only CloudFront with this OAC
# The policy condition checks for 'aws:SourceArn' matching your distribution
cat > bucket-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::myapp-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1ABC123XYZ"
        }
      }
    }
  ]
}
EOF

echo "Apply bucket policy: aws s3api put-bucket-policy --bucket myapp-bucket --policy file://bucket-policy.json"

# Step 3: Attach OAC to distribution origin
# aws cloudfront update-distribution --id E1ABC123XYZ --distribution-config file://dist-config.json

Production Performance: Cache Hit Ratio, Origin Shield, and Cost Optimisation

CloudFront's effectiveness is measured by cache hit ratio — percentage of requests served from edge cache rather than origin. Target >90% for static assets. Low hit ratio means your cache key is too specific (forwarding unique headers or query strings) or TTL is too short.

Origin Shield — an additional caching layer in a single region that sits between edges and origin. It aggregates requests from all edges, reducing connections to your origin. Enable it for origins that are not already behind a CDN and for high-traffic workloads. Origin Shield can dramatically reduce origin load during traffic spikes.

Regional Edge Caches — automatically enabled for all distributions (as of 2024+). They sit between edge locations and origin, caching content not requested frequently enough to stay in edge caches. No extra cost.

Cost optimisation: CloudFront charges per request and per GB transferred. Use compression (gzip/brotli) to reduce bytes. Brotli compresses text 20-25% better than gzip. Set appropriate TTLs to avoid frequent origin fetches. Use cost allocation tags to track spend per distribution.

Monitoring: CloudWatch metrics include Requests, BytesDownloaded, TotalErrorRate, and CacheHitRate. Set alarms for error rate >1% and cache hit rate <80%. Monitor OriginLatency for signs of origin overload.

Pricing nuance: CloudFront has free tier (1TB transfer/month), but costs can spike if you serve large files (video) or have high request rates (many small files). For small files, per-request cost dominates; consider combining files into archives or using HTTP/2 multiplexing.

#!/bin/bash
DISTRIBUTION_ID="E1ABC123XYZ"

echo "=== CloudFront Performance Metrics ==="

# Cache hit ratio (last hour)
aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront \
  --metric-name CacheHitRate \
  --statistics Average \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --dimensions Name=DistributionId,Value="${DISTRIBUTION_ID}"

# Error rate
aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront \
  --metric-name TotalErrorRate \
  --statistics Average \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --dimensions Name=DistributionId,Value="${DISTRIBUTION_ID}"

# Origin latency (p95)
aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront \
  --metric-name OriginLatency \
  --statistics p95 \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --dimensions Name=DistributionId,Value="${DISTRIBUTION_ID}"

echo "=== Cache Hit Ratio Target: >90% for static content ==="
echo "=== Error Rate Target: <1% ==="