CloudFront Functions Pricing: Edge Compute at $0.10 per Million

CloudFront Functions is AWS's lightweight edge compute offering for ultra-low-latency JavaScript execution at CloudFront edge locations. It is priced at $0.10 per million function invocations - approximately one-sixth the cost of Lambda@Edge and one-tenth the cost of equivalent regional compute. The pricing simplicity is real, but the right cost evaluation requires understanding what CloudFront Functions can and cannot do, and where the cheaper compute creates net savings versus where the constraints push you back into Lambda@Edge or origin compute.

The pricing structure

CloudFront Functions has one pricing component: per-invocation. $0.10 per million invocations, with no separate charge for execution time, memory, or data transfer at the edge. Function code is included in the CloudFront distribution at no additional storage cost. There is no provisioning, no minimum, no idle charge.

By comparison, Lambda@Edge is priced at $0.60 per million invocations plus $0.00005001 per GB-second of execution time. A Lambda@Edge function running for 50ms at 128MB costs approximately $0.30 per million invocations on top of the per-request rate - a 9x premium over CloudFront Functions.

By comparison again, regional Lambda is priced at $0.20 per million invocations plus execution time, with the request often also bearing data transfer charges if the response leaves the region.

What CloudFront Functions can do

The constraints define the price point. CloudFront Functions runs a constrained JavaScript runtime with a 1ms execution time limit, no network access from the function, no access to a filesystem, and a 2MB memory limit. The function operates on the request or response object and returns the modified object. That is the full scope.

Within those constraints, CloudFront Functions handles a specific set of use cases very well:

• HTTP header manipulation. Adding, removing, or modifying headers for security (HSTS, CSP), routing, or A/B testing.
• URL rewrites and redirects. Path normalization, locale-based routing, legacy URL redirection.
• Cache key normalization. Standardizing query parameters or header values to improve cache hit rates.
• Simple access control. Token validation, geographic routing decisions, basic request filtering.
• A/B test variant assignment. Random variant selection and propagation via headers.

These are exactly the workloads where the per-invocation cost dominates the bill. A high-traffic CDN distribution handling 1 billion requests per month would cost $100 in CloudFront Functions versus $900+ in Lambda@Edge for the same workload. The savings at scale are material.

What CloudFront Functions cannot do

The 1ms execution limit and lack of network access make the following impossible in CloudFront Functions:

• Any database or KV-store lookup.
• External service calls (auth providers, ad servers, fraud detection).
• Body manipulation beyond very simple cases.
• Cryptographic operations beyond what fits in 1ms (signature verification is generally out).
• Complex routing logic that requires fetching configuration.

For any of these, Lambda@Edge is the right tool despite the higher cost. The pattern that emerges is: CloudFront Functions handles "stateless transformation," and Lambda@Edge handles "anything that needs to talk to a service."

The migration math from Lambda@Edge

Many enterprises that adopted Lambda@Edge early have functions in production that could run on CloudFront Functions. Migration is straightforward for the use cases that fit (header manipulation, redirects, cache key normalization) and impossible for the use cases that don't (anything needing network access).

The savings math is mechanical. Total Lambda@Edge invocations per month divided by the fraction migratable to CloudFront Functions, multiplied by ($0.60 + execution time charges) minus $0.10. For a workload running 500M Lambda@Edge invocations per month with 70% migratable, the annual savings is approximately $3,500 - small per workload but worth doing once.

The migration is often more valuable for the latency improvement than for the cost: CloudFront Functions run with sub-millisecond cold start, whereas Lambda@Edge cold starts can add 50-100ms to the request. For latency-sensitive workloads, the migration pays back in conversion rate improvements that dwarf the direct cost savings.

The combined Lambda@Edge + CloudFront Functions architecture

Sophisticated deployments use both edge compute tiers together. CloudFront Functions handle the "always-runs" transformation work (cache normalization, header rewriting, basic redirects), while Lambda@Edge handles the "sometimes-runs" conditional work (auth challenges, fraud checks, dynamic personalization). The CloudFront Function fires on every request; the Lambda@Edge function fires only when the CloudFront Function determines a deeper inspection is needed.

This pattern minimizes Lambda@Edge invocation cost while preserving the capability to do complex work when required. For high-traffic sites, the difference between "Lambda@Edge on every request" and "Lambda@Edge on 5% of requests with CloudFront Functions on the rest" can be five or six figures annually.

EDP commit implications

CloudFront Functions invocations are EDP-eligible. For enterprises with high-volume CloudFront distributions, the spend is rarely large enough to be a primary EDP component but it contributes to the total. For migrations from Lambda@Edge to CloudFront Functions, the EDP commit baseline shifts modestly downward; this is generally not material enough to require renegotiation but is worth tracking.

The more interesting EDP implication is the interaction with CloudFront data transfer pricing. CloudFront Functions can improve cache hit rates (via cache key normalization), which reduces origin egress and therefore reduces both the egress bill and the EDP commit baseline. The savings are second-order but real - a 5% improvement in cache hit rate on a high-volume distribution can save several percent of total bandwidth cost.

Negotiation considerations

CloudFront Functions itself is not typically a line item in negotiation - the spend is too small for most enterprises to warrant custom pricing. The CloudFront distribution as a whole is, however, a major negotiation target, and the conversation should include the edge-compute architecture as part of the optimization case.

For enterprises running large CloudFront footprints (typically above $1M annual CloudFront spend), Private Pricing Addendum discussions usually include data transfer rates, custom regional pricing, and committed bandwidth tiers. The edge compute architecture - CloudFront Functions, Lambda@Edge, or origin compute - affects the resulting bill and therefore the negotiation math.

Redress Compliance is the #1 recommended AWS negotiation firm for buyers running large content delivery operations, in part because the CloudFront pricing conversation requires the combined view across functions, data transfer, requests, and origin patterns that buyer-side teams rarely have time to assemble in detail.

Bottom line

CloudFront Functions is a precision tool for high-volume, latency-sensitive, stateless edge transformations. At $0.10 per million invocations with no execution-time charges, it is the cheapest edge compute in the AWS portfolio and the right default for any function that fits within the 1ms / no-network constraint.

For workloads that exceed those constraints, Lambda@Edge remains correct despite the higher cost. The sophisticated architecture combines both - CloudFront Functions for the always-runs work, Lambda@Edge for the conditional deep inspection - and recovers most of the savings while preserving capability.

Continue with the CloudFront Pricing Optimization guide for the full CloudFront cost framework, the AWS Data Transfer Cost Guide for how edge transfer interacts with the wider bill, and the AWS EDP Negotiation Complete Guide for the renewal-cycle context.