AWS CloudFront: Global CDN Delivering Content From 450+ Edge Locations Worldwide

A user in Tokyo requesting a webpage hosted on a server in us-east-1 (Northern Virginia) has a round-trip time of approximately 175–200ms for each uncached request. That adds up: a page that makes 30 requests has a minimum latency of 5–6 seconds just in network overhead, before any processing time. For a static image served from S3 in Virginia to that user in Tokyo, the content has to travel roughly 10,000 kilometres across the Pacific.

CloudFront solves this by caching content at edge locations close to users. AWS operates over 450 edge locations and regional edge caches worldwide. When that Tokyo user requests the same image, CloudFront serves it from an edge location inside Tokyo, typically within 10–20ms. The image only makes the long journey to the origin once; every subsequent request for the same content is served locally.

Origins, Distributions, and Cache Behaviours

Understanding CloudFront requires knowing three concepts: the origin (where the original content lives), the distribution (the CloudFront configuration that defines how to handle requests), and cache behaviours (rules that map URL path patterns to specific caching and routing settings).

Origins can be:

S3 buckets (for static assets, websites, downloads)
Application Load Balancers or EC2 instances (for dynamic content)
API Gateway (for APIs)
Any publicly accessible HTTP endpoint, including non-AWS servers

Distributions are CloudFront configurations tied to a domain name (e.g., d1234567890.cloudfront.net, or a custom domain like assets.example.com). Each distribution has one or more origins and one or more cache behaviours.

Cache behaviours are path-pattern matching rules. A single distribution can serve both cached static assets and uncached API responses:

CloudFront Distribution Cache Behaviour Configuration
------------------------------------------------------
Distribution: assets.example.com

Path Pattern: /api/*
  Origin: Application Load Balancer (api.example.com)
  Cache: TTL = 0 (no caching, pass-through)
  Forward: All headers, cookies, query strings

Path Pattern: /images/*
  Origin: S3 bucket (my-images-bucket)
  Cache: TTL = 86400 (24 hours)
  Forward: No headers or cookies (maximise cache hit rate)

Path Pattern: /static/*
  Origin: S3 bucket (my-static-bucket)
  Cache: TTL = 2592000 (30 days)
  Compress: Gzip/Brotli enabled

Default (*):
  Origin: Application Load Balancer
  Cache: TTL = 3600 (1 hour)

Cache TTL and Invalidation

Cache TTL (Time to Live) determines how long CloudFront stores an object at edge locations before checking the origin for a new version. A high TTL means fewer origin requests and faster responses, but stale content if the origin updates the file.

Two mechanisms handle content freshness:

Versioned filenames: Instead of app.js, deploy app.v2.1.4.js. The CDN caches the old filename indefinitely, and the new version is immediately available because it has a new cache key. This is the most reliable approach for static assets with long TTLs.

Cache invalidation: The CloudFront API accepts invalidation requests specifying paths to purge (/images/logo.png or /static/*). CloudFront propagates the invalidation to all edge locations within about 60 seconds. First 1,000 invalidation paths per month are free; beyond that, $0.005 per path. For high-frequency content updates, versioned filenames are significantly cheaper.

Signed URLs and Signed Cookies

CloudFront supports restricting access to content so that only authorised users can retrieve objects. Two mechanisms exist:

Signed URLs: A time-limited URL that includes a cryptographic signature. Users with the signed URL can download the specific object until the URL expires. Useful for per-file temporary access — a purchase confirmation download link, a one-time export file.

Signed Cookies: A set of cookies that grant access to multiple files matching a wildcard pattern. A user who authenticates to a streaming platform receives signed cookies valid for their session; every video segment request is authorised by those cookies. The URL does not change with each segment — the authorisation is in the cookie.

Both mechanisms require a CloudFront key pair. The application server generates the signature using a private key; CloudFront validates it using the corresponding public key (configured in the distribution as a Trusted Key Group).

Lambda@Edge: Compute at the Edge

Lambda@Edge executes Lambda functions at CloudFront edge locations, enabling request and response manipulation close to users without the round trip back to the origin. There are four event triggers:

Viewer Request: Triggered when CloudFront receives a request. Can modify request headers, normalise cache keys, or reject requests.
Origin Request: Triggered before forwarding to the origin (only on cache misses). Can add authentication headers, rewrite URLs, or route to different origins.
Origin Response: Triggered after receiving response from origin. Can modify response headers, add security headers.
Viewer Response: Triggered before delivering response to user. Can add custom headers or modify responses.

A common Lambda@Edge pattern: URL rewriting for a single-page application. When the SPA is deployed to S3 and served through CloudFront, requests for paths like /dashboard or /settings need to be rewritten to return index.html (which loads the SPA, which then handles routing). A Viewer Request function can detect that the requested path has no file extension and rewrite it to /index.html before CloudFront checks the cache.

Lambda@Edge Request Flow
--------------------------
User request for /dashboard
        |
        v
[Viewer Request Lambda]
  - Check if path has no extension
  - Rewrite to /index.html
        |
        v
[CloudFront Cache Check]
  - /index.html found in cache? --> serve directly
  - Not found? --> forward to origin
        |
        v
[Origin Request Lambda]  (on cache miss)
  - Add Authorization header from CloudFront
        |
        v
[S3 Origin]
  - Return index.html
        |
        v
[Origin Response Lambda]
  - Add Cache-Control: max-age=3600
  - Add Security headers
        |
        v
[Viewer Response Lambda]
  - Add CORS headers
        |
        v
User receives index.html (SPA loads, handles /dashboard routing)

Origin Shield

Origin Shield is an additional caching layer between CloudFront edge locations and your origin. When enabled, all cache misses from all edge locations route through a single Origin Shield region before reaching the origin. This collapses many parallel origin requests (from edge locations in different cities all missing cache simultaneously) into a single request to the origin.

For origins with limited capacity or expensive egress, Origin Shield materially reduces origin load. AWS charges per gigabyte processed through Origin Shield, but the reduction in origin costs and load often more than compensates.

Real-Time Logs and Metrics

CloudFront supports two logging mechanisms. Standard access logs are delivered to S3 as compressed text files within minutes of requests — useful for periodic analysis but not real-time visibility. Real-time logs stream to Kinesis Data Streams within seconds, enabling live traffic analysis, anomaly detection, and integration with SIEM systems.

CloudFront metrics are available in CloudWatch with 1-minute granularity (enabled via additional metrics) or the default 1-minute granularity for cache hit rates, request counts, error rates, and bandwidth. CloudFront also integrates with AWS WAF, enabling request filtering based on IP reputation, rate limiting, bot detection, and custom rule matching — all evaluated at the edge before traffic reaches the origin.