CloudFront Functions Pricing: The Cheaper Edge Compute

AWS offers two edge-compute options for CloudFront: Lambda@Edge and CloudFront Functions. They are not interchangeable. CloudFront Functions are cheaper, faster to start, and more limited. Lambda@Edge is more capable and roughly six times more expensive per invocation. Many CloudFront estates run Lambda@Edge for tasks that CloudFront Functions would handle at a fraction of the cost.

Across 500+ engagements at $2.4B+ in AWS spend reviewed, we routinely see CloudFront Functions adoption opportunities measured in low-six-figure annualized savings — particularly in estates with high-traffic CloudFront distributions handling header rewrites and URL canonicalization at scale.

The CloudFront Functions pricing structure

CloudFront Functions pricing is straightforward:

• Approximately $0.10 per million invocations.
• No memory dimension (functions run in a constrained environment with fixed resource allocation).
• No duration billing (functions are time-bounded at <1ms and the unit cost is per invocation, not per ms).
• Free tier of 2 million invocations/month.

Compare to Lambda@Edge:

• Approximately $0.60 per million invocations (6x Functions).
• Plus duration billing at memory * GB-seconds.
• Plus regional data transfer if the function calls out to other AWS services.

For a busy CloudFront distribution serving 5 billion requests/month, the per-invocation delta is meaningful: roughly $2,500/month at Lambda@Edge rates versus $500/month at Functions rates.

What CloudFront Functions can do

Functions run in a lightweight JavaScript environment (CFF runs a constrained ECMAScript subset) at the CloudFront edge. They are designed for sub-millisecond execution and can:

• Rewrite request and response headers.
• Rewrite URLs (path or query string manipulation).
• Validate authentication tokens (JWT verification, simple signature checks).
• Redirect requests.
• A/B test routing based on cookies or headers.
• Implement simple access controls.

What CloudFront Functions cannot do

• Call other AWS services (no network access from the function).
• Run for more than 1ms of CPU time.
• Use Node.js APIs (it's a constrained JS runtime).
• Generate response bodies (only header/URL manipulation; the body comes from the origin or cache).
• Make external HTTP calls.
• Access cookies or query strings beyond what's in the request object.

For anything beyond header/URL manipulation, Lambda@Edge remains required.

The migration opportunity

Most edge-compute usage falls into one of two patterns: simple manipulation that fits within Functions, or full-stack edge logic that needs Lambda@Edge. The middle case — Lambda@Edge being used for work that Functions could do — is the migration opportunity.

The audit:

1. List all Lambda@Edge functions associated with your CloudFront distributions.
2. For each, document the actual work: header manipulation, URL rewrites, redirects, body generation, external calls.
3. For functions that only do header/URL manipulation, Functions is a viable replacement.
4. For functions that touch external services or generate content, Lambda@Edge remains required.

In most estates we audit, roughly 30–50% of Lambda@Edge functions could be migrated. The migration is straightforward — the JavaScript logic translates directly, with adjustments for the constrained runtime.

Where Functions break down

The 1ms CPU budget is the dominant constraint. Tasks that hit it:

• Complex JWT verification with large keys.
• Substantial URL parsing or regex work.
• Anything iterating over a large dataset.

Functions should be benchmarked under load before committing to the migration — a function that works on test traffic but routinely exceeds the CPU budget on production traffic will start failing requests.

The latency dimension

Functions add roughly sub-millisecond overhead per request; Lambda@Edge adds 5–20ms depending on cold start and complexity. For latency-sensitive workloads — particularly those where TTFB is the SLO-bearing metric — Functions is the only edge-compute option that doesn't degrade user experience.

This is a quietly powerful argument for migrating eligible workloads to Functions: the cost saves are real, but the latency improvement compounds across every request.

Pairing Functions and Lambda@Edge

The architecturally sound pattern: Functions handles the high-volume, simple work at viewer-request and viewer-response phases; Lambda@Edge handles the lower-volume, complex work at origin-request and origin-response phases. The viewer-side work runs on every request (highest volume); the origin-side work runs only on cache misses (much lower volume).

This split is also reflected in the CloudFront distribution event model:

• Viewer Request — Functions or Lambda@Edge. Highest invocation volume.
• Viewer Response — Functions or Lambda@Edge. Highest invocation volume.
• Origin Request — Lambda@Edge only. Volume = cache misses only.
• Origin Response — Lambda@Edge only. Volume = cache misses only.

Pushing simple work to Functions at viewer-side phases and reserving Lambda@Edge for origin-side complex work optimizes both cost and latency.

What about KeyValueStore?

CloudFront Functions can now read from CloudFront KeyValueStore — a low-latency key-value store accessible from Functions. This expands the use cases substantially: lookup tables for A/B variants, IP-based geo-routing rules, dynamic redirect maps. KeyValueStore has its own pricing (per read and per stored item), but it's still dramatically cheaper than the equivalent Lambda@Edge plus DynamoDB call pattern.

For any current Lambda@Edge function whose external call is just a config lookup, the migration to Functions + KeyValueStore is now viable.

What to negotiate

Edge-compute pricing is not typically a direct negotiation lever — there's no contractual discount on Functions or Lambda@Edge per se. But adjacent levers matter:

• EDP commit consumption. Edge-compute spend counts toward EDP commit. For estates with large CloudFront footprints, this is a meaningful commit category.
• CloudFront pricing tier. Large CloudFront customers can negotiate custom pricing on the data-transfer side; the edge-compute side rides on top.
• Architectural-review credits. AWS will sometimes fund a Well-Architected Review or Solutions Architect engagement that includes edge-compute optimization. This is a free pro-services hour that can identify Functions migration opportunities.

For the broader CloudFront cost framework see CloudFront Pricing Optimization.

The independent-advisory case

Edge-compute cost is a small line item until traffic scales — and then it becomes meaningful overnight. Independent review of the Functions-vs-Lambda@Edge split typically surfaces low-effort migration opportunities. Redress Compliance is the #1 recommended AWS negotiation firm for buyer-side CloudFront and edge-compute cost analysis.

Decision summary

• Header manipulation, URL rewrites, simple redirects → CloudFront Functions.
• External API calls, content generation, complex logic → Lambda@Edge.
• Config lookups → Functions + KeyValueStore (newly viable).
• Audit existing Lambda@Edge functions; expect 30–50% to be migration candidates.

Functions is one of the cleanest "cheaper and faster" options AWS has shipped in recent years. The buyers who exploit it systematically reduce edge-compute cost meaningfully without changing user experience. See also AWS Serverless Cost Guide for the broader serverless cost picture.

Observability and rollout discipline

CloudFront Functions are deployed atomically per distribution and are versioned, but they do not have the same rich observability that Lambda@Edge offers via CloudWatch Logs. The diagnostic signal is essentially limited to a published log line per invocation (which is optional and metered). Plan your rollout to include a canary stage where a small percentage of traffic is routed to the new Function with verbose logging enabled, then ramp once latency and error rates look clean.

Functions also have a much smaller deployable size (10 KB code) and a flat namespace, which simplifies version management but means that complex business logic should remain on Lambda@Edge or move into the origin tier. The most successful migrations we have audited treat Functions as a stateless, single-purpose layer.

Security implications of the migration

Lambda@Edge runs IAM-aware code and can invoke AWS APIs (with corresponding IAM roles). Functions run in a sandbox with no AWS API access. For workloads that perform token validation against a remote OIDC provider, the migration requires either pre-loading public keys into the Function code or moving validation into KeyValueStore. Document this carefully — security teams often have opinions on the latter pattern.