CloudFront Functions vs Lambda@Edge cost: lightweight vs full compute
CloudFront Functions cost about $0.10 per million invocations for lightweight viewer logic; Lambda@Edge bills per request plus duration for heavier compute across more event types. Choosing the lighter tool where it fits cuts edge cost. Here is the comparison.
Quick answer
CloudFront Functions cost about $0.10 per million invocations for lightweight, sub-millisecond viewer request/response logic. Lambda@Edge bills per request plus compute duration and runs heavier code across all four CloudFront event types. For simple header manipulation, redirects, and URL rewrites, CloudFront Functions are much cheaper; use Lambda@Edge only when you need its power.
CloudFront offers two ways to run code at the edge, and they sit at very different price and capability points. Choosing the lighter one where it suffices, rather than reaching for Lambda@Edge by default, meaningfully cuts edge-compute cost on high-traffic distributions.
Two edge-compute options
| CloudFront Functions | Lambda@Edge | |
|---|---|---|
| Pricing | ~$0.10 / million invocations | Per request + compute duration |
| Events | Viewer request/response only | All four (viewer + origin, request + response) |
| Capability | Lightweight JS, sub-ms, no network | Full Node/Python, network access, more compute |
| Cost at scale | Much lower | Higher |
CloudFront Functions run lightweight JavaScript in sub-millisecond time for viewer request and response events, priced simply per invocation. Lambda@Edge runs full functions with network access and more compute, across all four event types, billed per request plus duration like regular Lambda.
Use the lighter tool where it fits
Common edge tasks, header manipulation, simple redirects, URL rewrites, token validation, A/B routing, fit CloudFront Functions, which are dramatically cheaper at high request volume. Lambda@Edge is for tasks that need its power: calling other services, heavier processing, or origin-side events. On a high-traffic distribution, doing simple logic in CloudFront Functions instead of Lambda@Edge is a large saving.
Choosing between them
Default to CloudFront Functions for viewer-side, lightweight logic, and use Lambda@Edge only when you need network access, more compute, or origin events. This is the same match-the-tool discipline as choosing the right compute for a task: the cheaper option is often enough.
FAQ
How do CloudFront Functions and Lambda@Edge differ in cost?
CloudFront Functions cost about $0.10 per million invocations for lightweight viewer logic. Lambda@Edge bills per request plus compute duration, like regular Lambda, and is more expensive. For simple edge tasks at high volume, CloudFront Functions are dramatically cheaper.
When should I use CloudFront Functions?
For lightweight, viewer-side logic: header manipulation, simple redirects, URL rewrites, token validation, and A/B routing. They run sub-millisecond JavaScript at low per-invocation cost, so they are ideal for common edge tasks at high request volume.
When do I need Lambda@Edge instead?
When you need capabilities CloudFront Functions lack: network access to call other services, heavier compute, longer execution, or origin-side events (origin request and response). Lambda@Edge is more powerful and more expensive, so use it only where its capabilities are required.
How do I reduce CloudFront edge-compute cost?
Do lightweight viewer logic in CloudFront Functions rather than Lambda@Edge, since they are much cheaper per invocation. Reserve Lambda@Edge for tasks that genuinely need its power. On high-traffic distributions, moving simple logic to CloudFront Functions is a large saving.
Can CloudFront Functions call other AWS services?
No. CloudFront Functions run lightweight JavaScript with no network access, for sub-millisecond viewer request and response manipulation. If you need to call other services or the network, use Lambda@Edge, which has full compute and network access at higher cost.
Does C3X estimate edge compute cost?
Edge compute cost is driven by invocation volume and, for Lambda@Edge, duration, which are usage inputs tied to request traffic. C3X prices the surrounding CloudFront infrastructure, and you model invocation volume to estimate the edge-function charges.
What to do next
Model your edge compute before you deploy. C3X reads your Terraform and prices CloudFront and the rest of your stack against a live catalog. Start with the quickstart.
Pricing references
Related posts
- Global Accelerator vs CloudFront cost: two edge services, two bills
Global Accelerator charges a fixed $0.025 per hour plus a per-GB premium, while CloudFront has no fixed fee and bills per GB and per request. They solve different problems, and picking the wrong one wastes money. Here is the cost comparison.
- CloudFront cost optimization guide: cutting CDN spend on AWS
CloudFront bills for data transfer out, requests, and optional features, and the biggest savings come from raising cache hit ratio, choosing the right price class, and using commitments. Here is a complete guide to optimizing CloudFront cost.
- Lambda ARM Graviton savings: cheaper functions by switching architecture
Running Lambda functions on ARM-based Graviton instead of x86 costs about 20 percent less per unit of compute, and many functions run just as fast or faster. Here is how the savings work, what to check before switching, and how to migrate.
- Lambda vs Fargate cost: which serverless compute is cheaper
Lambda charges per request and per GB-second and scales to zero; Fargate charges per vCPU and GB by the second for continuously running tasks. The cheaper option depends entirely on your traffic pattern. Here is how to choose.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.