AWS Lambda@Edge

• CategoryServerless function
• LanguageNode.js / Python
• PricingPaid
• LicenseProprietary
• Created2017
• GitHub starsclosed
• Cold startslow
• PoPs~600
• Node-compatYes

Lambda@Edge runs Lambda functions on CloudFront PoPs in response to viewer / origin events. Full Node (or Python) runtime, real cold starts (50-200ms), tight CloudFront integration. Used heavily in AWS-locked organisations for header rewriting, A/B routing, image optimisation at edge.

• AWS-locked organisations with existing CloudFront deployments
• Header rewriting, redirects, A/B routing tied to CloudFront events
• Apps requiring full Node compatibility at the edge

Skip Lambda@Edge for cold-start-sensitive workloads, Cloudflare Workers is meaningfully faster. Skip outside AWS; the integration is the value.

Lambda@Edge is fine for AWS-locked teams but the cold start cost is real. New non-AWS projects almost always pick Cloudflare Workers instead.

Lambda@Edge is Lambda, which means an execution environment has to exist before your handler runs, and roughly fifty to two hundred milliseconds is the realistic expectation when one does not. At the edge that happens more often than in a single region, because traffic to any individual point of presence is thinner than traffic to a busy region, so environments go cold sooner and more of your requests pay the penalty. The usual regional answer, provisioned concurrency, is not available here. What you can do is keep the deployment bundle small, avoid pulling heavy SDK modules at module scope, and push anything that is only a header or URL rewrite down into CloudFront Functions, which has no environment to create at all. Set expectations with stakeholders early. Against Cloudflare Workers, where isolates are pre-warmed and the concept largely disappears, this is the defining architectural difference between the two.

Lambda@Edge functions are created in us-east-1 and replicated outward, so a change is not instant and a rollback carries the same delay. You associate a numbered function version with a CloudFront behaviour and a specific event, viewer request, origin request, origin response, or viewer response, and those four trigger points have different rules about body access and execution limits. Logs land in the region nearest whichever point of presence served the request, which makes debugging a scavenger hunt until you centralise them. Budget for slower iteration than any V8 platform gives you, and for a change-management process rather than a push. What you get back is real Node or Python, the whole npm registry, and IAM-scoped access to the rest of your AWS account. For teams already living in that account, that trade is often worth the latency and the friction.

• Official homepage →

The 30-min call is where your edge runtime choice becomes a real architecture, an integration plan with your data layer + auth + build pipeline, and a price range you can take to your stakeholders.