CloudFront: How CDN Caching and Edge Logic Actually Work

What CloudFront actually does

CloudFront is a CDN — a global network of edge locations that cache content close to users. When a user in Tokyo requests your site hosted in us-east-1, without a CDN the request travels ~7,000 miles. With a CloudFront edge location in Tokyo, it travels tens of miles to the edge, which serves cached content or fetches from origin once and caches the response.

The performance improvement is primarily about reducing round-trip time. A single HTTPS request requires multiple round-trips (DNS, TCP, TLS, HTTP). Reducing the geographic distance cuts each round-trip from 150ms to 10ms. For a page that requires 4 sequential requests, that is 560ms saved before you touch a single byte of HTML.

Cache behaviors and what determines cache hits

A cache behavior specifies how CloudFront caches a URL pattern. The most important settings:

Cache key: what makes two requests "the same request" for caching purposes. By default, only the URL path. If your responses vary by Accept-Language header, add that header to the cache key — otherwise all languages get the same cached response.

TTL: how long CloudFront holds a cached response before checking origin for a fresh copy. CloudFront honors Cache-Control: max-age=X from your origin. You set a minimum and maximum TTL in the behavior to constrain what origins can request.

Forwarding: which headers, cookies, and query strings are forwarded to origin. Do not forward everything — it defeats caching (each unique combination becomes a separate cache entry). Forward only what your origin needs to generate the response.

URL: /api/user?id=42&lang=en
Cache key (wrong): /api/user?id=42&lang=en
→ Caches a separate response for every user and language combination
→ Effectively no caching

Cache key (right for static assets): /static/logo.png
→ One cache entry per file, shared by all users

Origin Access Control for S3

If your CloudFront distribution serves content from an S3 bucket, you need to prevent users from bypassing CloudFront and accessing S3 directly. The modern way is Origin Access Control (OAC).

With OAC:

1. CloudFront signs requests to S3 using SigV4.
2. Your S3 bucket policy allows s3:GetObject only from your CloudFront distribution's ARN.
3. The bucket is private — direct S3 URLs return 403.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/DISTRIBUTION_ID"
        }
      }
    }
  ]
}

OAC replaces the older Origin Access Identity (OAI) which used a special CloudFront IAM principal rather than signing requests.

Lambda@Edge vs CloudFront Functions

Both allow you to run code at CloudFront edge locations. They differ in when they run and what they can do.

CloudFront Functions: lightweight JavaScript running at the edge in microseconds. Good for: URL rewrites, header manipulation, simple auth checks. Cannot make network requests or access external services. Maximum execution time: 1ms.

// CloudFront Function: rewrite /blog → /blog/index.html
function handler(event) {
    var request = event.request;
    if (request.uri.endsWith('/blog')) {
        request.uri = '/blog/index.html';
    }
    return request;
}

Lambda@Edge: full Lambda running in the nearest regional edge location. Can make HTTP calls, access DynamoDB, read from S3. Maximum execution time: 5 seconds (origin request/response), 1 second (viewer request/response). ~10x more expensive than CloudFront Functions.

WAF integration

CloudFront integrates with AWS WAF to inspect and block requests at the edge before they reach your origin. WAF rules run on the CloudFront edge, so blocked requests never consume origin resources.

Common patterns:

• Rate limiting: block IPs sending more than N requests per 5 minutes
• Geographic blocking: drop requests from specific countries
• SQL injection / XSS rules: AWS Managed Rules group blocks common attack patterns
• Bot control: distinguish scrapers, crawlers, and automation from legitimate traffic

resource "aws_wafv2_web_acl" "cloudfront" {
  name  = "cloudfront-acl"
  scope = "CLOUDFRONT"  # must be us-east-1 for CloudFront
  # ...
}

resource "aws_cloudfront_distribution" "main" {
  web_acl_id = aws_wafv2_web_acl.cloudfront.arn
  # ...
}

WAF for CloudFront must be created in us-east-1 regardless of where your origin is — CloudFront's control plane is in us-east-1.

user → dev.example.com → dev.internal.example.com (CNAME) → CloudFront → origin