AWS CloudFront Functions

• CategoryCDN-attached function
• LanguageJS (subset)
• PricingPaid
• LicenseProprietary
• Created2021
• GitHub starsclosed
• Cold startinstant
• PoPs~600
• Node-compatNo

CloudFront Functions runs lightweight JavaScript at CloudFront PoPs in sub-millisecond time. Restricted runtime, no full V8, smaller API surface than Workers. Used for header manipulation, URL rewriting, simple auth checks. Cheaper than Lambda@Edge, narrower scope.

• AWS-locked teams needing fast header / URL manipulation at edge
• Cost-sensitive AWS edge workloads (cheaper than Lambda@Edge)
• Simple viewer-request transformations

Skip CloudFront Functions for anything beyond simple transformations, the runtime is restricted. For serious edge logic, Lambda@Edge or Cloudflare Workers.

Niche but useful inside AWS. Outside that ecosystem, Cloudflare Workers covers the same use cases with a richer runtime.

CloudFront Functions is not V8 with restrictions applied. It is a purpose-built JavaScript engine with a small API surface, running on every CloudFront point of presence with no execution environment to create and therefore no cold start line on your latency chart. The restrictions are absolute rather than tunable: no outbound network calls, no filesystem, no access to request or response bodies, no npm. What you can do is inspect and rewrite headers, URIs, cookies, and query strings, issue a redirect, and perform a cheap signature or token check. That is the complete list. The hard boundary is a feature rather than an oversight, because it makes it impossible for anyone on your team to put slow work in front of every request. The moment you find yourself wanting to call an API from inside one of these, you have outgrown the tool and Lambda@Edge is the next step up.

Inside AWS the split is clean and worth writing into your own standards document: CloudFront Functions on viewer request and viewer response for cheap transforms, Lambda@Edge on origin triggers or anywhere real compute is required. Per-invocation cost is a fraction of Lambda@Edge, so pushing every eligible transform down is a straightforward saving on a high-traffic property, and there is no cold start to reason about. Outside AWS the comparison is far less flattering. Cloudflare Workers does everything CloudFront Functions does and then keeps going, with real fetch, storage bindings, and a full V8 runtime at comparable latency, on a network you can sign up for in minutes. So the correct framing is narrow: this is a good tool once CloudFront is already your delivery layer, and irrelevant to the platform decision itself.

• 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.