AWS CloudFront: Global CDN & Edge Delivery

Q: What's the difference between CloudFront and S3?

S3 stores your files; CloudFront caches and delivers them globally from edge locations near users. S3 alone serves from one region (slower for distant users, and you pay S3 request/egress costs on every hit); CloudFront in front caches at the edge, cutting latency and offloading S3. The standard static-site setup is S3 (private, via OAC) + CloudFront.

Q: CloudFront Functions or Lambda@Edge?

CloudFront Functions for lightweight, ultra-high-volume viewer-request/response manipulation (URL rewrites, header injection, simple redirects/auth) — sub-millisecond and very cheap. Lambda@Edge for heavier logic or when you need origin-facing triggers (auth token validation, dynamic origin selection, A/B testing). Start with Functions; reach for Lambda@Edge when Functions can't do it.

Q: How do I keep users from bypassing CloudFront?

For S3 origins, use Origin Access Control (OAC) — the bucket is private and only CloudFront's signed requests can read it. For custom origins (ALB/EC2), restrict inbound to CloudFront's published IP ranges or require a secret header that only CloudFront sends. Otherwise attackers hit your origin directly, skipping WAF, Shield, and caching.

AWS CloudFront

Amazon CloudFront is AWS's content delivery network — a global fleet of edge locations that cache your content close to users, cutting latency and offloading traffic from your origin. A user requesting your site or API hits the nearest CloudFront edge; if the content is cached there, it's served in milliseconds without ever touching your S3 bucket or EC2/load balancer origin. It's the standard way to accelerate and protect anything AWS-hosted.

Beyond caching, CloudFront is AWS's security edge and edge-compute platform: it terminates TLS, integrates with AWS WAF and Shield for DDoS protection, and runs code at the edge (CloudFront Functions, Lambda@Edge) for request manipulation, auth, and personalization. Everything on the general CDN page applies here — this is the AWS-native implementation with deep AWS integration.

TL;DR

CloudFront caches content at global edge locations; requests hit the nearest edge, and cache hits are served without reaching your origin (S3, ALB, or any HTTP server).
You define origins (where content comes from) and cache behaviors (path patterns → caching/routing rules).
Caching is controlled by cache policies and origin Cache-Control headers — the same CDN caching semantics (TTLs, cache keys, invalidation).
It's also AWS's security edge: free TLS certs (ACM), AWS WAF integration, and Shield DDoS protection.
Edge compute: CloudFront Functions (lightweight, sub-ms, for header/URL manipulation) and Lambda@Edge (heavier, full Lambda at the edge) run logic close to users.
Deep AWS integration (S3 origins with OAC, ALB origins, ACM, WAF, Route 53) makes it the default CDN for AWS-hosted content.

Core Concepts

How It Works

A distribution is your CloudFront configuration: it ties one or more origins to cache behaviors. The x-cache: Hit/Miss from cloudfront response header tells you which path a request took — the first thing to check when debugging caching.

Origins and Cache Behaviors

Origins — where CloudFront fetches content: an S3 bucket (for static assets), an Application Load Balancer or EC2 (for dynamic content), or any custom HTTP origin. One distribution can have multiple origins.
Cache behaviors — path-pattern rules (/images/*, /api/*, default) that map requests to an origin and a set of caching/security settings. This lets one distribution serve static assets from S3 with long caching and proxy /api/* to an ALB with no caching.

Caching Control

CloudFront caching follows the standard CDN model: cache policies (and the origin's Cache-Control headers) set TTLs and define the cache key (which parts of the request — query strings, headers, cookies — distinguish cached objects). The usual recipes apply:

Fingerprinted static assets → long TTL, immutable (deploys change the filename, so no invalidation needed).
Dynamic/API responses → short or no TTL.
Invalidation for non-versioned content that changed — but avoid "invalidate everything" (it hammers the origin and costs money); prefer versioned URLs.

The cache-key discipline is critical: too broad and you cache personalized responses across users (a data leak); too narrow (keying on every query param) and hit ratio collapses. See the CDN page for the full treatment.

Security at the Edge

CloudFront is AWS's security front door:

TLS: free certificates via ACM, TLS termination at the edge, HTTP→HTTPS redirect.
AWS WAF: attach web-application-firewall rules (block SQL injection patterns, bad bots, rate-limit abusive IPs) at the edge — see API Security.
Shield: automatic DDoS protection (Standard is free; Advanced adds more), absorbing volumetric attacks at the network's scale.
Origin protection: with S3 Origin Access Control (OAC), the bucket is private and only CloudFront can read it — users can't bypass the CDN to hit the origin directly. The same principle (restrict origin ingress to CloudFront) applies to custom origins.

Edge Compute

Run code at the edge for logic that shouldn't require an origin round-trip:

CloudFront Functions handle the high-volume, simple manipulations (rewrite a path, add security headers, do a cheap auth check) extremely cheaply; Lambda@Edge handles heavier per-request logic. This is the same edge-compute idea as Cloudflare Workers, AWS-flavored.

Common Mistakes

Caching Personalized Content Publicly

A cache behavior that caches responses containing user-specific data (without keying on the auth cookie/header) serves one user's page to another — the classic CDN personalization leak. Keep authenticated/personalized responses uncached, or key the cache carefully. Never Cache-Control: public on user-specific content.

Leaving the Origin Publicly Accessible

If users can reach your S3 bucket or ALB origin directly (bypassing CloudFront), the CDN's WAF, Shield, and caching become optional. Use Origin Access Control to make S3 buckets CloudFront-only, and restrict custom origins to CloudFront's IP ranges (or a secret header). An exposed origin defeats the security edge.

Long TTLs on Unversioned Assets

max-age of a year on /app.js (no content hash) means users run stale JavaScript after a deploy, and you're stuck invalidating. Long TTLs are safe only with fingerprinted filenames that change when content changes. See CDN.

Over-Invalidating

Invalidating /* on every deploy destroys your cache hit ratio and incurs invalidation costs (only the first N per month are free). Design URLs so you rarely invalidate (versioned assets), and invalidate specific paths when you must.

Ignoring the Real Client IP

Behind CloudFront, your origin sees CloudFront's IP unless you read the forwarded headers (CloudFront-Viewer-Address, X-Forwarded-For). Logs, geo-logic, and rate limiting at the origin need the real client IP — configure the origin (or Nginx) to trust the forwarded header.

FAQ

What's the difference between CloudFront and S3?

S3 stores your files; CloudFront caches and delivers them globally from edge locations near users. S3 alone serves from one region (slower for distant users, and you pay S3 request/egress costs on every hit); CloudFront in front caches at the edge, cutting latency and offloading S3. The standard static-site setup is S3 (private, via OAC) + CloudFront.

Does CloudFront help dynamic/API content, not just static files?

Yes, in two ways. It can cache cacheable API responses (public data) at the edge, and even for uncacheable dynamic content it accelerates delivery — TLS terminates near the user and CloudFront maintains optimized connections back to your origin, reducing latency. Plus WAF/Shield protect dynamic origins. It's not only for static assets.

How is CloudFront's security different from just using HTTPS?

CloudFront bundles the whole edge security stack: free TLS (ACM), AWS WAF (application-layer filtering — block injection, bots, abuse), Shield (DDoS absorption at network scale), and origin protection (OAC keeps S3 private). It's a security perimeter, not just encryption — often the primary defense layer for AWS-hosted apps.

CloudFront Functions or Lambda@Edge?

CloudFront Functions for lightweight, ultra-high-volume viewer-request/response manipulation (URL rewrites, header injection, simple redirects/auth) — sub-millisecond and very cheap. Lambda@Edge for heavier logic or when you need origin-facing triggers (auth token validation, dynamic origin selection, A/B testing). Start with Functions; reach for Lambda@Edge when Functions can't do it.

How do I keep users from bypassing CloudFront?

For S3 origins, use Origin Access Control (OAC) — the bucket is private and only CloudFront's signed requests can read it. For custom origins (ALB/EC2), restrict inbound to CloudFront's published IP ranges or require a secret header that only CloudFront sends. Otherwise attackers hit your origin directly, skipping WAF, Shield, and caching.