Lambda@Edge Pricing in 2026: A Cost-Model Playbook

A single Lambda@Edge function running at 128 MB for 50 ms across 100 million monthly viewer-request invocations costs roughly $87 in compute alone — before you touch CloudFront data transfer. Double the memory to handle JWT validation or header rewriting, and that figure nearly doubles with it. Understanding lambda@edge pricing at the line-item level is the difference between a predictable edge-compute bill and a six-figure surprise after a traffic spike. This article gives you the 2026 rate card, a side-by-side cost comparison against CloudFront Functions, a worked cost model you can plug your own numbers into, and optimization patterns that cut invocation costs by 40–70% in production.

Lambda@Edge Pricing: The 2026 Rate Card

As of May 2026, AWS bills Lambda@Edge on two axes — requests and duration — identical in structure to standard Lambda but at different rates. There is no free tier for Lambda@Edge; the standard Lambda free tier of 1 million requests and 400,000 GB-seconds per month does not apply to functions triggered by CloudFront events.

These rates have remained unchanged since 2024. The real cost movement in 2026 comes from behavioral changes: more teams adopting viewer-request triggers for auth and geo-routing, which places the invocation on the hottest path and multiplies volume.

How Lambda@Edge Cost Stacks Against CloudFront Functions

CloudFront Functions, the lightweight alternative that runs at the edge in a JavaScript-only sandbox, operates on a fundamentally different pricing model. Comparing the two is the single most impactful cost decision you make when designing edge logic on CloudFront.

At 500 million viewer requests per month, the CloudFront Functions vs Lambda@Edge pricing gap is roughly 10:1. The decision point is capability, not cost preference: if your logic needs network calls (token validation against an external JWKS endpoint, origin selection based on a DynamoDB lookup), you are forced into Lambda@Edge. If you are rewriting headers, normalizing cache keys, or redirecting based on geo headers already present in the CloudFront request object, CloudFront Functions is the correct choice by an order of magnitude on cost.

Worked Cost Model: Lambda@Edge at Scale

Below is a realistic cost projection for a mid-sized media platform running Lambda@Edge on the viewer-request trigger for authentication token validation. All figures are as of Q2 2026.

Assumptions

• 200 million CloudFront requests per month
• Lambda@Edge attached to viewer-request event
• 128 MB memory allocation (viewer trigger cap)
• Average execution duration: 35 ms
• Cache hit ratio: 65% — only cache misses and viewer-request triggers fire the function, meaning all 200M requests invoke it since viewer-request fires before cache lookup

Monthly Calculation

• Request charges: 200M x $0.60 / 1M = $120.00
• Duration charges: 200M invocations x 0.035 s x (128 MB / 1024 MB) = 875,000 GB-seconds x $0.00000625125 = $5.47
• Total Lambda@Edge cost: ~$125.47/month

The request component dominates at short durations. This is a critical insight: for viewer-trigger functions running under 100 ms, lambda@edge request pricing is 90%+ of the bill. Optimizing duration has minimal impact. Reducing invocation volume — by restructuring which events trigger the function — is where the money is.

What Happens When Traffic Spikes

During a product launch or live event pushing 2 billion requests in a month, that same function costs $1,254 in Lambda@Edge charges alone, on top of CloudFront data transfer. This is where teams get caught. The viewer-request trigger fires on every single request, including those served from cache. There is no way to conditionally skip it at the CloudFront distribution level.

Failure Modes and Cost Traps in Production

After operating Lambda@Edge at scale across multiple production environments, certain cost failure modes recur often enough to document explicitly.

Viewer-request triggers on static assets

The most expensive misconfiguration is attaching Lambda@Edge to a behavior that matches static assets (images, CSS, JS). A site serving 50 million page views with 30 assets per page generates 1.5 billion Lambda@Edge invocations monthly. At $0.60/million, that is $900/month for function execution on requests where the logic likely does nothing. Use CloudFront behavior path patterns to scope your function to the paths that actually need it.

Cold start cascades during traffic spikes

Lambda@Edge cold starts at viewer-request add 100–200 ms of latency. During a sudden traffic spike, a wave of cold starts compounds into elevated P99 latency that triggers retry storms from impatient clients, which in turn increases invocation count beyond the organic request volume. Monitor the CloudFront x-edge-detailed-timing header and instrument your function's init duration to detect this early.

Unthrottled origin-request functions making external calls

Origin-request triggers that call external APIs (authorization services, feature-flag providers) without circuit breakers can rack up lambda@edge duration charges rapidly when that external service degrades. A 200 ms function that balloons to 5 seconds on a slow upstream, multiplied across thousands of concurrent invocations, shifts duration from a rounding error to the dominant cost line.

Missing the viewer-response vs origin-response distinction

Attaching a response-manipulation function to viewer-response means it fires on every response, including cache hits. Attaching it to origin-response means it fires only on cache misses. If your function adds security headers or modifies response metadata, origin-response combined with CloudFront's managed response headers policy can eliminate the function entirely.

Optimization Playbook

These patterns consistently reduce lambda@edge cost in production without sacrificing functionality.

• Migrate eligible logic to CloudFront Functions. Any viewer-facing logic that does not require network access, filesystem access, or more than 2 MB memory belongs in CloudFront Functions. Header rewrites, cache key normalization, simple redirects, and basic token presence checks are immediate candidates.
• Scope behaviors tightly. Use CloudFront behavior path patterns to ensure Lambda@Edge only fires on paths that require it. Serving /api/* through a behavior with Lambda@Edge while /static/* uses a plain caching behavior is the simplest cost win.
• Push auth to origin-request. If your function validates tokens, attach it to origin-request instead of viewer-request. It fires only on cache misses. This is viable when the response itself is cacheable per-user (using Vary or cache-key customization) — the function runs once per unique cache key, not once per viewer request.
• Set aggressive TTLs for authenticated content. Even a 60-second TTL on personalized API responses reduces origin-request invocations dramatically under sustained load.
• Monitor with CloudWatch Embedded Metrics. Instrument your Lambda@Edge function to emit invocation count, duration P50/P99, and external call latency as embedded metric format logs. CloudWatch will parse them at no additional per-metric cost. Set billing alarms on the Lambda line item in Cost Explorer with a daily granularity.

When CloudFront Stops Being the Right Answer

For workloads where the edge compute cost of Lambda@Edge (or even CloudFront Functions) becomes disproportionate to the value of running logic at the edge — particularly high-volume media delivery where the primary concern is throughput and cost per TB rather than programmable edge logic — alternative CDN architectures deserve evaluation. BlazingCDN delivers stability and fault tolerance comparable to CloudFront while operating at significantly lower cost: starting at $4 per TB for volumes under 25 TB, scaling down to $2 per TB at the 2 PB tier. With 100% uptime SLAs, flexible configuration, and fast scaling under demand spikes, it handles the delivery layer efficiently while you retain Lambda@Edge only for the narrow set of requests that genuinely require server-side compute at the edge.

FAQ

Does Lambda@Edge increase CloudFront costs?

Yes. Lambda@Edge invocations are billed separately from CloudFront request and data transfer charges. They appear as distinct line items under the Lambda service in your AWS bill, not under CloudFront. The magnitude depends on invocation volume and function duration, but for viewer-request triggers the request charge alone ($0.60/million) can exceed the CloudFront request charge for the same traffic.

Is Lambda@Edge included in the CloudFront free tier?

No. As of Q2 2026, the CloudFront free tier covers 1 TB of data transfer and 10 million HTTP/HTTPS requests monthly. Lambda@Edge invocations are not included, nor does the standard Lambda free tier (1 million requests, 400,000 GB-seconds) apply to Lambda@Edge functions.

How much does Lambda@Edge cost per million requests?

$0.60 per million invocations, plus duration charges. For a typical viewer-request function running 35 ms at 128 MB, duration adds roughly $0.027 per million, making the effective rate approximately $0.627 per million invocations. Request charges dominate for short-duration functions.

Are Lambda@Edge invocations billed separately from CloudFront?

Yes. They appear under the AWS Lambda service billing, not CloudFront. This is a frequent source of confusion in cost allocation. If you use AWS Organizations with consolidated billing, tag your Lambda@Edge functions with a cost-allocation tag to attribute them to the correct team or project.

What is the impact of Lambda@Edge on CloudFront pricing at high volume?

At 1 billion monthly viewer-request invocations with a 50 ms average duration at 128 MB, Lambda@Edge adds approximately $631/month on top of CloudFront delivery costs. The proportional impact depends on your CloudFront data transfer volume — for a 50 TB/month workload, Lambda@Edge is a ~5% surcharge; for a 5 TB/month workload with the same request count, it can be a 25%+ surcharge.

Can I use CloudFront Functions instead of Lambda@Edge to reduce cost?

For use cases that fit within CloudFront Functions' constraints (JavaScript-only, no network access, sub-millisecond execution, 2 MB memory cap), switching from Lambda@Edge to CloudFront Functions reduces invocation cost by approximately 6x and eliminates duration billing entirely. Header manipulation, URL rewrites, and cache key normalization are the most common migration candidates.

What to Instrument This Week

Pull your last 30 days of Lambda@Edge invocation data from CloudWatch and split it by CloudFront behavior path pattern. Identify which behaviors are generating the most invocations and map each to the actual logic the function performs on that path. Any path where the function runs but does nothing meaningful — returns the request unmodified, adds a header that could be added via CloudFront managed headers — is an immediate candidate for removal. Run this audit quarterly. The traffic patterns shift, but the Lambda@Edge attachment rarely gets revisited after initial deployment. That drift is where the cost accumulates.