Five Silent Cost Killers in Serverless AWS Apps (and How to Fix Them)
Five hidden serverless cost drivers on AWS, from Lambda memory sizing to NAT Gateway fees, with practical fixes you can apply this week.
Serverless promises that you only pay for what you use. That's true, but "what you use" includes things you never meant to use: oversized logs, NAT traffic, and workflows that bill by the step. Here are five patterns that quietly inflate AWS bills, each with a fix you can apply this week.
1. Guessing your Lambda memory size
Lambda allocates CPU in proportion to memory, so a function with more memory often runs much faster. Because you pay for GB-seconds, a 1024 MB function that finishes in 200 ms can cost less than a 256 MB function that takes 1,000 ms.
Fix: Run the open-source AWS Lambda Power Tuning tool against your busiest functions. It tests multiple memory settings and charts cost against speed, so you pick from data instead of defaults.
2. Ignoring Graviton (arm64)
Lambda functions on arm64 are billed at a lower per-GB-second rate than x86, and many workloads also run faster. For most Python, Node.js, and Java functions, switching is a one-line change.
yaml
1
2
3
4
5
6
7
# AWS SAM
MyFunction:
Type: AWS::Serverless::Function
Properties:
Runtime: python3.12
Architectures:
- arm64Watch out for: native dependencies compiled for x86. Rebuild them for arm64 and test before rolling out.
3. Letting logs pile up forever
CloudWatch Logs charges for ingestion and for storage. By default, log groups never expire, and a chatty function logging full request payloads can cost more than the compute it runs on.
Fixes:
- Set a retention period on every log group (7 to 30 days is plenty for most apps).
- Log at INFO in production and keep DEBUG for troubleshooting.
- Use Lambda's advanced logging controls to filter log levels without code changes.
- Don't log entire payloads. Log IDs and key fields.
4. Paying NAT Gateway fees to reach AWS services
If your Lambda or container sits in a private subnet and talks to S3 or DynamoDB through a NAT Gateway, you pay hourly charges plus per-GB data processing on all that traffic.
Fix: Add gateway VPC endpoints for S3 and DynamoDB. They have no hourly or data processing charge, and they keep traffic on the AWS network. For other services, evaluate interface endpoints, which have their own cost, so compare against your traffic volume.
5. Using the wrong Step Functions workflow type
Standard workflows bill per state transition, which is great for long-running, auditable processes but expensive for high-volume, short-lived ones. Express workflows bill by number of executions and duration, and they suit high-throughput event processing.
Rule of thumb:
| Workload | Better fit |
|---|---|
| Long-running, needs full execution history, human approvals | Standard |
| High volume, short duration, idempotent steps | Express |
Bonus: Make cost visible
None of this helps if you can't see where money goes. Do three things on day one:
- Turn on cost allocation tags (for example
project,env,owner) and activate them in Billing. - Create an AWS Budgets alert at 80% of your expected monthly spend.
- Review Cost Explorer grouped by service once a week for the first month.
Wrap-up
Cost optimization in serverless is mostly about removing waste, not cutting features. Right-size memory, move to arm64, expire your logs, bypass the NAT where you can, and match your workflow type to your traffic. Each change is small, and together they often cut bills noticeably without touching your architecture.
What's the sneakiest cost you've found in your own AWS account? Share it in the comments.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article