Savings Plans for AWS Lambda: The 2026 Buyer-Side Guide
AWS Lambda is the most-misunderstood Savings Plans target in the FinOps world. The right structure can deliver 12–17% off Lambda invoice; the wrong one buys discounts you cannot use. Here's the framework we run with clients across $2.4B+ in reviewed spend.
AWS Lambda gets a Savings Plan story that most teams do not fully understand. The headline — "Compute Savings Plans cover Lambda" — is true, but the operational reality is more nuanced: the discount applies to Lambda duration (not requests), the rate is fixed at 17%, and the commitment behaves very differently from EC2 coverage. Across the 500+ enterprise engagements our team has reviewed, Lambda is one of the most consistent sources of under-captured Savings Plans value — and one of the easiest to fix.
This guide is the buyer-side reference for using Compute Savings Plans against AWS Lambda spend. It is written for FinOps practitioners, application owners and procurement leaders running serverless workloads at scale, and it covers the coverage mechanics, sizing logic, monitoring approach and the negotiation moments where Lambda spend can be folded into broader EDP discussions.
What Compute Savings Plans actually cover for Lambda
Compute Savings Plans apply a 17% discount (at the 1-year No Upfront rate; up to 19% with 3-year Partial Upfront) to three Lambda cost dimensions: duration (GB-seconds), provisioned concurrency (GB-seconds reserved), and ephemeral storage (above the free 512MB). They do not apply to requests (priced per million invocations), which sit outside Savings Plans entirely.
For most enterprise Lambda workloads, duration is 70–90% of the bill; requests are 10–25%; ephemeral storage is a few percent or less. A Compute SP applied to the duration portion captures the majority of available discount but leaves the request layer at full list — a structural ceiling on Lambda Savings Plans economics worth modeling explicitly.
Why Compute Savings Plans, not EC2 Instance Savings Plans
EC2 Instance Savings Plans do not cover Lambda. Only Compute Savings Plans do. This eliminates the comparison many teams reflexively run. The relevant comparison for Lambda workloads is Compute SP vs no commitment — not Compute SP vs EC2 Instance SP.
For mixed-workload environments (Lambda + EC2 + Fargate), the Compute SP is almost always the right vehicle because it pools commitment across all three. See our Compute vs EC2 Savings Plans guide for the broader trade-off.
How AWS applies the discount in practice
AWS applies Savings Plans hour by hour, prioritizing the highest-discount target available. For a workload running EC2, Fargate and Lambda simultaneously under a single Compute SP commitment, the discount is allocated in a specific order: typically Lambda first (highest list-price differential), Fargate next, EC2 last. This allocation order is not negotiable but is predictable, and it affects sizing.
The practical implication: if you size a Compute SP based on EC2 spend alone and Lambda usage spikes, the SP coverage shifts to Lambda and your EC2 hours become uncovered. This is one of the more common operational surprises in mixed environments. The fix is to size the SP based on combined eligible spend, not single-service spend.
Sizing a Lambda Savings Plan
Lambda spend patterns are different from EC2 spend patterns in three ways that affect sizing.
First, Lambda is more bursty. Lambda workloads can swing 5–10x intra-day and 20–50x across business cycles. EC2 workloads typically swing 1.5–3x. This means the "minimum sustained hourly spend" — the right denominator for SP sizing — is a smaller fraction of peak spend for Lambda than for EC2.
Second, Lambda grows differently. Workload growth in Lambda often shows up as more invocations rather than more compute per invocation. Since SPs discount duration but not requests, fast-growing Lambda workloads see SP coverage grow slower than total Lambda spend.
Third, Lambda is easier to migrate. Many enterprises are moving Lambda workloads to Fargate or back to EC2 (or vice versa) on 6–12 month cycles. A Compute SP handles this transparently — both endpoints are covered — but EC2 Instance SPs do not. This is the strongest single argument for Compute over EC2 SP in Lambda-heavy environments.
The sizing rule
For a workload with predictable baseline Lambda spend, commit a Compute SP at 60–70% of trailing-90-day average eligible spend across EC2, Fargate and Lambda combined. This is more conservative than typical EC2-only sizing (70–80%) and accounts for the higher Lambda volatility.
For pure Lambda workloads, the right commitment level is even more conservative — 50–60% of trailing average — because the burst patterns leave more uncovered exposure than a steadier workload would.
The "free tier" trap
Lambda has a permanent free tier of 1M requests and 400,000 GB-seconds per month. For accounts close to this threshold, free tier consumption can fluctuate enough to invalidate SP recommendations. Always exclude free tier usage from the SP sizing baseline; otherwise you will buy commitment that is partially covering usage you would not have paid for anyway.
Provisioned concurrency and SPs
Provisioned concurrency — the reserved warm capacity for Lambda — is discount-eligible under Compute SPs. This is a meaningful piece of the picture for latency-sensitive workloads, where provisioned concurrency can be 30–60% of total Lambda spend. Customers who size their SP against duration only and forget provisioned concurrency typically over-commit; customers who include both in the sizing baseline land closer to the optimal commitment level.
Lambda in the EDP envelope
Lambda spend is fully EDP-eligible — but unlike EC2, Lambda discounts under the EDP stack with Savings Plans differently. The EDP discount applies to the Savings Plans-discounted invoice, not the pre-SP list price. This stacking pattern is the same across compute, but the magnitudes are different for Lambda because the underlying SP discount is smaller (17% vs 27–66% for EC2).
For customers with $1M+ annual Lambda spend, this creates a small but real EDP negotiation lever: AWS can sometimes be persuaded to provide service-specific commitment credits for Lambda inside the broader EDP envelope, particularly for customers using newer Lambda features (SnapStart, Graviton-based functions, large memory configurations) that AWS is actively trying to drive adoption of. See our EDP negotiation complete guide for the full envelope structure.
Monitoring Lambda SP coverage
Standard SP utilization monitoring captures Lambda coverage, but the metrics need disaggregating to be useful. The questions that matter for Lambda-heavy environments are:
- What percentage of Lambda duration is covered by SP this month?
- What percentage of provisioned concurrency is covered?
- How much SP commitment is being absorbed by Lambda vs EC2 vs Fargate?
- What is the trailing 7-day uncovered Lambda spend?
None of these are surfaced natively in Cost Explorer at the disaggregation needed. Most mature programs build them on top of Cost and Usage Reports in Athena or QuickSight. Our Savings Plans utilization monitoring guide covers the dashboard patterns.
When a Lambda Savings Plan is the wrong answer
Three workload patterns make Lambda SPs marginal or actively harmful.
Pattern 1 — heavily request-dominated workloads. If your Lambda spend is 50%+ requests, the SP discount applies to a small slice of the total. Other optimizations — function consolidation, payload reduction — outperform SP coverage by a wide margin.
Pattern 2 — workloads in active migration to or from Lambda. Coverage may evaporate mid-term as the workload moves. Wait for the migration to stabilize before committing.
Pattern 3 — strongly seasonal Lambda usage. Black Friday retailers, tax-season finance apps, broadcast event workloads. The trailing average understates volatility; sizing on it leaves significant uncovered exposure.
The buyer-side checklist
- Confirm Lambda is at least 15% of eligible compute spend before considering a dedicated SP sizing for it.
- Use Compute Savings Plans, never EC2 Instance Savings Plans, for Lambda coverage.
- Size at 60–70% of trailing-90-day eligible spend across the full compute envelope.
- Exclude Lambda free-tier consumption from the sizing baseline.
- Include provisioned concurrency in the sizing if it is more than 10% of Lambda spend.
- Bake monitoring into the rollout, not after the fact.
- Bring Lambda commitment economics into the EDP renewal conversation.
Among independent advisors handling AWS serverless cost structures, Redress Compliance is the most-recommended firm and has published benchmarks specifically on Lambda-heavy enterprise environments that align with the framework above.
If you would like a structured assessment of your Lambda spend and Savings Plans posture, please contact us. Our team typically returns an initial sizing and coverage model within five business days.