cloudcostdown.euAWS Lambda Cost Optimization · Startup Guide
How to Reduce AWS Lambda Costs by 40–70%
Lambda costs are invisible until they aren’t. Memory over-allocation, missed Graviton discounts, and high invocation counts silently compound - often costing 2–4× what an optimized setup would.
Why Lambda Costs Surprise Engineering Teams
The pricing model
Lambda charges per GB-second: memory (GB) × duration (seconds). A function at 1024 MB running 500ms costs the same as one at 256 MB running 2000ms. Most teams default to higher memory thinking it’s “safer” - but duration rarely changes linearly with memory for I/O-bound functions.
At scale, the difference between 256 MB and 1024 MB for 10 million invocations is $664/month - with identical real-world performance.
Where to look first
- 1. Cost Explorer → Group by Service → Lambda
- 2. Cost Explorer → Group by Usage Type → find Lambda-GB-Second and Lambda-Request
- 3. CloudWatch → Lambda Insights → sort by cost (memory × average duration × invocations)
- 4. Identify top 10 functions by cost - these are where to focus first
- 5. Run Lambda Power Tuning on each to find optimal memory
5 Proven Lambda Cost Fixes
Apply these in order - highest ROI first.
Right-size Lambda memory allocation
Lambda charges for GB-seconds - memory × duration. Most teams set memory conservatively high and never revisit it. A function allocated 1024 MB running in 200ms costs 4× more than the same function at 256 MB running in 250ms. The AWS Lambda Power Tuning open-source tool runs your function at every memory tier and finds the optimal point automatically.
How to implement
- Deploy the Lambda Power Tuning state machine from the AWS Serverless Application Repository
- Run it against your highest-invocation functions (start with top 10 by cost in Cost Explorer)
- Set the optimization strategy to 'cost' (not 'speed')
- Update the MemorySize in your IaC (Terraform aws_lambda_function or SAM template)
- Re-run quarterly - usage patterns change as code evolves
Note: A fintech startup reduced Lambda spend by $1,800/month purely from memory right-sizing across 12 functions. No code changes, 4 hours of work.
Migrate to Graviton2 (ARM) runtime
Lambda on Graviton2 (arm64 architecture) costs 20% less per GB-second than x86, with comparable or better performance for most workloads. Node.js, Python, Java, Go, and .NET 6+ all run on arm64 with no code changes - only a runtime and architecture setting change.
How to implement
- Check your function runtime: Node.js 18+, Python 3.8+, Java 11+, Go 1.x, .NET 6+ are all arm64-compatible
- Set Architectures = ['arm64'] in your Lambda resource definition
- Deploy and test - no code changes needed for interpreted runtimes
- For compiled languages (Go, Rust), rebuild with GOARCH=arm64 / target=aarch64
- Monitor duration in CloudWatch for 48 hours after switch to confirm parity
Note: This is a free 20% discount with a one-line IaC change. It is one of the most overlooked quick wins in Lambda cost optimization.
Add Compute Savings Plans for predictable workloads
Compute Savings Plans apply automatically to Lambda GB-seconds with no configuration needed beyond the commitment purchase. If you have baseline Lambda invocations that run predictably every month (scheduled jobs, API handlers), a 1-year no-upfront Compute Savings Plan saves 17% with zero commitment risk.
How to implement
- Open AWS Cost Explorer → Savings Plans → Recommendations
- Filter by Lambda and select your lookback period (90 days recommended)
- Purchase a no-upfront 1-year plan for your baseline commitment amount
- Plans apply automatically - no tagging or function-level configuration needed
- Review utilization monthly in the Savings Plans coverage report
Note: Compute Savings Plans also cover EC2 and Fargate. If you run all three, a single plan covers all predictable compute spend across your account.
Reduce invocation count with batching and filtering
Lambda charges per invocation ($0.20 per million) plus duration. If you process SQS or Kinesis records one at a time, you pay for each record as a separate invocation. Batching processes up to 10,000 records per invocation, cutting costs proportionally.
How to implement
- Enable batch processing on SQS event sources: set BatchSize to 100–1000 and MaximumBatchingWindowInSeconds to 30
- For Kinesis: increase BatchSize and use enhanced fan-out only where latency requires it
- For EventBridge rules: consolidate rules that trigger the same function
- Use SQS filter policies to discard irrelevant events before they invoke Lambda
- Review Lambda Insights in CloudWatch to identify high-invocation-count functions
Note: Teams processing high-volume event streams (analytics pipelines, webhook ingestion) often see 60–80% invocation count reduction from batching alone.
Eliminate idle time with proper timeout configuration
Lambda charges for the entire configured timeout when a function hangs waiting on an unresponsive upstream service. Default timeouts of 3–15 seconds combined with slow database connections or third-party APIs generate unnecessary GB-seconds charges.
How to implement
- Identify functions with P99 duration significantly below configured timeout
- Set timeout to P99 duration + 30% buffer (not the maximum 15 minutes)
- Add circuit breakers for external HTTP calls (use axios-retry or httpx timeouts)
- Configure DLQ (Dead Letter Queue) on async invocations so failed functions don't silently retry
- Enable Lambda Insights to track average vs. max duration per function
Note: If any function has a configured timeout of 60s but P99 duration of 3s, you are overpaying by 20× on hung invocations.
Lambda Cost Comparison: Before vs. After
| Scenario | Before | After | Monthly saving |
|---|---|---|---|
| 10M invocations/mo · 1024 MB · 200ms avg | $340/mo | $86/mo (256 MB · 250ms) | $254/mo |
| x86 vs. Graviton2 (arm64), same workload | $500/mo | $400/mo (arm64) | $100/mo |
| 1-year Compute Savings Plan on baseline | $400/mo | $332/mo | $68/mo |
| SQS: 1M records, batch size 1 vs. 500 | $200/mo | $0.40/mo | $199.60/mo |
Frequently Asked Questions
How much does AWS Lambda cost?
Lambda charges on two dimensions: requests ($0.20 per million, first 1M free) and duration ($0.0000166667 per GB-second). A function using 512 MB of memory running for 100ms consumes 0.05 GB-seconds and costs $0.00000083335 per invocation - very cheap individually, but adds up at millions of invocations.
Does switching to Graviton/arm64 require code changes?
For interpreted runtimes (Node.js, Python, Ruby) and JVM-based runtimes (Java, Kotlin): no code changes. Only an architecture setting change in your IaC. For compiled languages (Go, Rust, C++), you need to rebuild for arm64. Lambda container images also need to be rebuilt for arm64.
What is the Lambda Power Tuning tool?
AWS Lambda Power Tuning is an open-source AWS Step Functions state machine that runs your function at every memory configuration (128MB to 10GB) and reports the optimal balance of cost and performance. It's deployed via the AWS Serverless Application Repository and runs entirely in your own account.
Do Compute Savings Plans work for Lambda?
Yes. Compute Savings Plans apply automatically to Lambda GB-second usage at a 17% discount (1-year no-upfront). The plan covers Lambda, EC2, and Fargate usage in aggregate, so a single plan covers your entire compute spend.
What is the biggest Lambda cost mistake startups make?
Setting memory to 1024MB or higher as a default and never tuning it. Lambda memory allocation is a proxy for CPU - but most functions are I/O bound and don't benefit from more CPU. Right-sizing memory is the single highest-ROI Lambda optimization.