5 Lambda Cost Mistakes I See Teams Make (And How to Fix Them)
Lambda’s pay-per-use model sounds simple: you pay for what you use. But after reviewing dozens of AWS bills with teams, I’ve found that “what you use” is often far more than “what you need.”
Here are the five most expensive mistakes I see repeatedly—and how to fix them.
Mistake #1: Using the Default 128MB Memory
This is the most common mistake, and it’s counterintuitive: allocating more memory can actually lower your bill.
Many teams deploy Lambda functions with the default 128MB memory allocation, thinking they’re being cost-conscious. The problem is that Lambda allocates CPU power proportionally to memory. At 128MB, your function gets a tiny slice of CPU, which means slower execution times.
Lambda pricing is calculated by multiplying the memory allocated by the execution time by the price per GB-second. If doubling your memory cuts execution time by more than half, you save money.
The Fix
Use AWS Lambda Power Tuning, an open-source tool that tests your function across memory configurations and shows you the cost-performance tradeoff. You can deploy it directly from the AWS Serverless Application Repository by searching for “aws-lambda-power-tuning.”
Run it against your production functions quarterly. Memory requirements change as your code and data evolve.
Mistake #2: Synchronous Chains of Lambda Functions
I’ve seen architectures where Lambda A calls Lambda B, which calls Lambda C, all synchronously. While the request waterfall completes, you’re paying for all three functions simultaneously.
Picture this flow: API Gateway triggers Lambda A, which invokes Lambda B and waits three seconds for a response, which in turn invokes Lambda C and waits two seconds, which finally does one second of actual work. The total billed Lambda execution time is ten seconds, but the actual compute work being done might only be two seconds. You’re paying for wait time, not compute time.
The Fix
Break synchronous chains with asynchronous patterns using SQS, SNS, or EventBridge.
Instead of having Lambda A invoke Lambda B directly and wait for a response, have Lambda A send a message to an SQS queue and return immediately to the caller with a 202 Accepted status. Lambda B then processes messages from the queue independently.
This approach means each function only runs for the time it needs to do its own work. No function sits idle waiting for another.
If you need orchestration with waiting, branching logic, or error handling across multiple steps, use Step Functions. You pay for state transitions rather than idle Lambda time, and you get built-in retry logic and visualization of your workflows.
Mistake #3: Logging Everything to CloudWatch
CloudWatch Logs ingestion costs $0.50 per GB. That sounds cheap until you realize how much your Lambdas are logging.
I audited one team’s account and found a single function generating 50GB of logs per month—$25/month for one function’s logs. They were logging full request and response bodies for debugging purposes during development and forgot to remove it before going to production.
The Fix
Use log levels properly. Configure your log level via environment variables so you can set DEBUG in development and INFO or WARN in production without changing code. Only log full payloads at the DEBUG level so they don’t appear in production logs.
Set CloudWatch Logs retention policies. The default retention is “never expire,” which means you’re storing and paying for logs forever. In your infrastructure templates, set retention to 14 or 30 days for most functions. You can always set longer retention for audit-critical functions.
Sample logs in high-throughput functions. If a function processes thousands of requests per minute, you don’t need detailed logs for every single one. Implement sampling where you only log full details for 10% of requests. This gives you enough data to debug issues while cutting log volume by 90%.
Audit what you’re logging. Search your codebase for log statements that include full event objects, request bodies, or response payloads. Each of these can add kilobytes per invocation that compound quickly at scale.
Mistake #4: Using Lambda for Long-Running Workloads
Lambda charges per millisecond of execution. For quick, bursty workloads, it’s incredibly cost-effective. For long-running processes, it becomes expensive fast.
I worked with a team running data transformation jobs that took 10-14 minutes per execution. They hit Lambda’s 15-minute timeout regularly and were paying a premium for what was essentially a batch job.
The Math
For a job running 12 minutes at 2048MB memory, executed 100 times per day:
Lambda cost: approximately $72 per month
Fargate cost (equivalently sized, running only when needed): approximately $5.40 per month
That’s a 13x difference.
The Fix
For workloads that exceed a one-minute runtime, consider evaluating AWS Fargate.
For workloads that can be parallelized, consider breaking them into smaller Lambda functions coordinated by Step Functions. You might process data faster and cheaper than a single long-running container by fanning out work across many concurrent short-lived functions.
Mistake #5: Provisioned Concurrency “Just in Case”
Provisioned Concurrency eliminates cold starts by keeping initialized execution environments ready. It’s great for latency-sensitive workloads. It’s terrible for your bill if misconfigured.
Provisioned Concurrency charges you whether the capacity is used or not. I’ve seen teams provision 100 concurrent executions “to be safe” for functions that peak at 20.
At 1024MB memory, keeping 100 provisioned instances running 24/7 for a month costs approximately $1,203—for capacity that sits mostly idle.
The Fix
Check your actual concurrency patterns in CloudWatch before deciding on provisioned concurrency. Look at the ConcurrentExecutions metric with the Maximum statistic over the past 30 days. You might find your function rarely exceeds 10 concurrent executions, making 100 provisioned instances wildly excessive.
Conclusion
Lambda cost optimization isn’t about using less serverless—it’s about using it more intelligently. The teams I see with the lowest bills per transaction aren’t the ones avoiding Lambda. They’re the ones who understand the pricing model and architect accordingly.
Start with Mistake #1. Run Lambda Power Tuning on your most-invoked functions this week. It takes 10 minutes and often pays for itself immediately.