Content Delivery Networks

A Content Delivery Network (CDN) distributes content to edge locations geographically closer to users, reducing latency and offloading origin servers. When a user in Tokyo requests content from a US-based origin, a CDN caches that content at a Tokyo edge location. Subsequent requests from the same region are served from the edge without crossing the Pacific Ocean, reducing response times from hundreds of milliseconds to under 50ms.

Amazon CloudFront is AWS's CDN service. It operates over 400 edge locations worldwide. When you create a distribution, you specify an origin (where the canonical version of your content lives). CloudFront caches content at edge locations based on cache behaviors you configure. The flow is: user request hits the nearest edge location, CloudFront checks its cache, serves the content if cached (cache hit), or forwards the request to the origin (cache miss), caches the response, and returns it to the user.

Origins can be S3 buckets (for static assets like images, CSS, JavaScript), Application Load Balancers (for dynamic content), or any HTTP server (custom origins). S3 origins benefit from the OAI (Origin Access Identity) or OAC (Origin Access Control) to keep buckets private while allowing CloudFront access. ALB origins enable caching dynamic content at the edge, reducing load on backend servers. Custom origins support any publicly accessible HTTP endpoint.

Cache behaviors define how CloudFront handles requests for specific URL patterns (e.g., /images/, /api/). Each behavior specifies the origin, allowed HTTP methods, cache policy, viewer protocol policy (HTTP only, HTTPS only, redirect HTTP to HTTPS), and TTL settings. Default behaviors apply to all requests not matching specific path patterns. You can create multiple behaviors to handle static and dynamic content differently within the same distribution.

TTL (Time To Live) settings control how long content stays cached. Default TTL is 86400 seconds (24 hours). Minimum TTL overrides the origin's Cache-Control header minimum. Maximum TTL caps caching even if the origin specifies longer. You can set TTL to 0 to disable caching entirely for dynamic content that must always hit the origin. Cache policies decouple TTL from headers, cookies, and query strings, giving fine-grained control over cache keys.

Lambda@Edge extends AWS Lambda functions to CloudFront edge locations, enabling custom logic execution at CDN boundaries. Functions trigger on four CloudFront events: viewer request (before checking cache), origin request (before forwarding to origin), viewer response (after receiving from cache or origin), and origin response (after receiving from origin). This placement enables use cases that reduce origin load and improve response times.

Common Lambda@Edge use cases include request manipulation (rewriting URLs, adding headers, redirecting based on device type), authentication (validating JWT tokens at the edge before requests reach your origin), A/B testing (routing users to different origin paths based on cookies), and image transformation (resizing images on-the-fly at the edge). Lambda@Edge functions must be in us-east-1 and deploy to all edge locations automatically. They have a 5-second timeout for viewer-facing events and 30 seconds for origin-facing events.

CloudFront Functions are lightweight JavaScript functions for high-frequency, simple transformations. They run at viewer-facing events only and execute in under 1ms. Use cases include header manipulation, URL rewrites, and simple authentication checks. CloudFront Functions are cheaper than Lambda@Edge (fraction of the cost) and scale to millions of requests per second. They are ideal when you need simple logic without the overhead of Lambda.

The key difference is capability and execution point: Lambda@Edge supports Node.js and Python, runs at both viewer and origin events, and can access the origin. CloudFront Functions support only JavaScript, run at viewer events only, and are read-only (no network access). Choose CloudFront Functions for header injection, URL normalization, and simple validation. Choose Lambda@Edge for authentication, dynamic content generation, and complex request routing.

Price classes control which edge locations CloudFront uses. Price Class All uses all edge locations (highest cost, lowest latency globally). Price Class 100 uses only North America and Europe. Price Class 200 adds Asia, Middle East, and Africa. Price Class 225 adds South America. Geographic restrictions (restrict list or allow list) prevent content from being served from specific countries, useful for licensing compliance or regulatory requirements. These restrictions use the CloudFront geolocation database and apply at the edge before caching.