aws-lambda-edge.html

AWS Lambda@Edge

AWS Lambda functions running on CloudFront. Full Node, slow cold starts, AWS-locked.

VISIT AWS LAMBDA@EDGE

Quick facts

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

What it is

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.

Best for

  • 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

When not to pick it

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

My take

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.

Links

Compare AWS Lambda@Edge side-by-side

AWS Lambda@Edge vs Cloudflare Workers → AWS Lambda@Edge vs AWS CloudFront Functions →

Similar tools you should also consider

AWS CloudFront Functions

Sub-millisecond JS at CloudFront edge. Lighter than Lambda@Edge, narrower scope.

Read the take →

Cloudflare Workers

V8 isolates on 300+ PoPs. Sub-millisecond cold starts, lowest cost at scale, the edge default.

Read the take →

If AWS Lambda@Edge is your pick — the next conversation is short

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.