CloudFront Functions vs Lambda@Edge
~8 min read
Two ways to run custom code at the edge — lightweight and fast versus full-featured and heavier.
CloudFront Functions run lightweight JavaScript directly on CloudFront's edge locations with sub-millisecond execution time, extremely high scale, and very low cost — designed for simple, fast operations like URL rewrites/redirects, header manipulation, or basic access control checks (e.g. validating a signed cookie format) at either the viewer request or viewer response stage.
Lambda@Edge runs full Node.js or Python Lambda functions, but only at a subset of CloudFront's edge locations (regional edge caches, fewer and more geographically spread than the full edge network), with higher latency and cost than CloudFront Functions, but far more capability: longer execution time, more memory, network calls to other services, and the ability to run at all four CloudFront trigger points (viewer request, origin request, origin response, viewer response) — including modifying which origin a request is routed to, which CloudFront Functions cannot do.
The decision is mostly about capability versus cost/latency: use CloudFront Functions for simple, high-volume operations (redirect http to https, normalize a URL, check a header format); reach for Lambda@Edge only when you genuinely need its extra capability, such as dynamically selecting an origin based on request content, calling an external API, or complex response body transformation.
💬 Deep Dive with AI
Key points
- •CloudFront Functions: JavaScript only, sub-millisecond, full edge network, simple operations (redirects, header/URL manipulation)
- •Lambda@Edge: full Node.js/Python, more capable but higher latency/cost, runs at fewer regional edge locations
- •Only Lambda@Edge can modify origin selection or make external network calls
- •Default to CloudFront Functions unless you specifically need Lambda@Edge's extra capability