$0.20 Per Million Requests Sounds Cheap. Your Actual Bill Will Not Be.
Here is a scenario we see constantly. A team spins up a new API on AWS Lambda. They look at the pricing page: $0.20 per million requests, $0.0000166667 per GB-second of compute. They run the math on their expected traffic (say 10 million requests per month at 256MB and 200ms average duration) and land on roughly $10. Practically free.
Then the first real bill shows up at $57. Sometimes $350 if they are on REST API Gateway with verbose logging and VPC-attached functions.
Where does the money go? Into charges that never appear on the Lambda pricing page. API Gateway takes $1-3.50 per million requests. CloudWatch Logs ingestion runs $0.50/GB. NAT Gateway processing costs $0.045/GB for every byte your function sends to an external API. These "supporting" services routinely account for 50-80% of a serverless workload's total cost, and most teams do not find out until the invoice lands.
We want to be clear: Lambda is genuinely cost-effective for the right workloads. But "the right workloads" is a narrower category than most teams realize. This post breaks down every Lambda cost in 2026, models real-world bills at three different scales, shows you exactly where the money hides, and helps you figure out when Lambda stops being the cheapest option.
For a broader look at serverless cost tradeoffs, see our serverless cost optimization and autoscaling guide.
AWS Lambda Pricing: The Complete 2026 Breakdown
Lambda pricing has two core dimensions (requests and compute duration) plus several secondary charges that quietly inflate your total cost.
Core Compute Pricing
| Component | Rate (2026) | Free Tier |
|---|---|---|
| Requests | $0.20 per 1M ($0.0000002/request) | 1M requests/month |
| Duration (x86) | $0.0000166667 per GB-second | 400,000 GB-seconds/month |
| Duration (ARM64/Graviton2) | $0.0000133334 per GB-second | 400,000 GB-seconds/month |
| Provisioned Concurrency | $0.0000041667 per GB-second (idle) | None |
| Ephemeral Storage | $0.0000000309 per GB-second (above 512MB) | 512MB included |
A few things worth understanding here:
- GB-second = memory allocated (in GB) multiplied by execution time (in seconds). A 256MB function running for 200ms consumes 0.05 GB-seconds.
- ARM64 is free money. Graviton2-based Lambda functions cost 20% less per GB-second with comparable or better performance. Unless you have x86-specific binary dependencies, there is no reason to stay on x86.
- Minimum billing is 1ms per invocation (rounded up). The old 100ms minimum was eliminated in 2022, which is great news for fast functions.
- Memory ranges from 128MB to 10,240MB (10GB) in 1MB increments. CPU scales proportionally with memory. At 1,769MB you get 1 full vCPU.
The Hidden Costs: What the Lambda Pricing Page Does Not Show
This is where serverless bills go sideways. These charges come from other AWS services, but they exist only because of your Lambda functions.
| Hidden Cost | Rate | Typical Impact |
|---|---|---|
| API Gateway (REST) | $3.50 per 1M requests | 10-50% of total bill |
| API Gateway (HTTP) | $1.00 per 1M requests | 5-15% of total bill |
| CloudWatch Logs ingestion | $0.50 per GB | 10-30% of total bill |
| CloudWatch Logs storage | $0.03 per GB/month | 5-15% (accumulates over time) |
| NAT Gateway processing | $0.045 per GB | 10-40% if functions call external APIs |
| Data Transfer Out | $0.09 per GB (first 10TB) | Varies by payload size |
| SQS/SNS/EventBridge | $0.40-1.00 per 1M messages | 5-10% for event-driven architectures |
| X-Ray tracing | $5.00 per 1M traces | 2-5% if enabled |
CloudWatch Logs is the silent killer. Every single Lambda invocation generates log entries: start, end, report line, plus whatever your function writes. A verbose function that logs request/response bodies at 10M invocations can easily generate 50-100GB of logs per month. That is $25-50 in ingestion alone, plus $1.50-3.00/month in perpetuity for storage. Most teams never bother to set a log retention policy, so this cost just keeps compounding month after month after month.
NAT Gateway is the expensive surprise. If your Lambda function lives in a VPC and calls any external API (think Stripe, Twilio, or a third-party service), every byte of that traffic passes through a NAT Gateway at $0.045/GB. A function that makes a 50KB API call 10 million times pushes 500GB through NAT Gateway, costing $22.50/month just for the privilege of reaching the internet. We have a full guide on how to cut NAT Gateway costs if this sounds familiar.
Real-World Lambda Cost Modeling
Abstract per-request pricing does not tell you much without real numbers behind it. Let us walk through what Lambda actually costs at three scales, including every supporting service.
Assumptions for All Three Models
- Function: REST API endpoint behind API Gateway (HTTP API, the cheaper option)
- Memory: 256MB
- Average duration: 200ms
- Architecture: x86 (we will show ARM64 savings separately)
- VPC: Yes, with NAT Gateway for external API calls
- Logging: Moderate (1KB per invocation average)
- No Provisioned Concurrency (purely on-demand)
Cost at 1M Requests/Month
| Component | Calculation | Monthly Cost |
|---|---|---|
| Lambda requests | 1M x $0.0000002 | $0.20 |
| Lambda duration | 1M x 0.05 GB-sec x $0.0000166667 | $0.83 |
| API Gateway (HTTP) | 1M x $0.000001 | $1.00 |
| CloudWatch Logs | 1GB x $0.50 | $0.50 |
| NAT Gateway | 50GB x $0.045 | $2.25 |
| Total | $4.78 | |
| Lambda compute only | $1.03 | |
| Supporting services | $3.75 (78%) |
Your Lambda compute is $1.03 but the actual bill is $4.78. The free tier covers the Lambda portion entirely, but API Gateway, CloudWatch, and NAT Gateway do not have an equivalent free tier. Even at this small scale, the surrounding services cost 3.6x more than Lambda itself.
Cost at 10M Requests/Month
| Component | Calculation | Monthly Cost |
|---|---|---|
| Lambda requests | 10M x $0.0000002 | $2.00 |
| Lambda duration | 10M x 0.05 GB-sec x $0.0000166667 | $8.33 |
| API Gateway (HTTP) | 10M x $0.000001 | $10.00 |
| CloudWatch Logs | 10GB x $0.50 | $5.00 |
| NAT Gateway | 500GB x $0.045 | $22.50 |
| Data Transfer Out | 100GB x $0.09 | $9.00 |
| Total | $56.83 | |
| Lambda compute only | $10.33 | |
| Supporting services | $46.50 (82%) |
Lambda compute is $10.33. Your bill is $56.83. Take a moment to appreciate that the NAT Gateway alone costs more than twice your Lambda compute. This is the kind of thing that makes FinOps engineers lose sleep.
Cost at 100M Requests/Month
| Component | Calculation | Monthly Cost |
|---|---|---|
| Lambda requests | 100M x $0.0000002 | $20.00 |
| Lambda duration | 100M x 0.05 GB-sec x $0.0000166667 | $83.33 |
| API Gateway (HTTP) | 100M x $0.000001 | $100.00 |
| CloudWatch Logs | 100GB x $0.50 | $50.00 |
| NAT Gateway | 5TB x $0.045 | $225.00 |
| Data Transfer Out | 1TB x $0.09 | $90.00 |
| Total | $568.33 | |
| Lambda compute only | $103.33 | |
| Supporting services | $465.00 (82%) |
At 100M requests, Lambda compute is $103. Total spend is $568. And remember, this uses HTTP API Gateway (the cheaper option). If you are on REST API Gateway at $3.50/1M, that adds $350 and pushes total spend past $900. For one API endpoint.
This is the moment where you should ask yourself: do I actually need serverless for this workload?
Lambda vs. Fargate vs. EC2: When Lambda Stops Being Cheapest
Lambda's pay-per-invocation model is efficient when utilization is low and traffic is unpredictable. But at sustained high volume, always-on compute becomes dramatically cheaper. Here is the comparison that surprises most teams.
Cost Comparison at Sustained 100M Requests/Month
| Platform | Configuration | Monthly Cost | vs. Lambda |
|---|---|---|---|
| Lambda (x86) | 256MB, 200ms avg | $568 (all-in) | Baseline |
| Lambda (ARM64) | 256MB, 200ms avg | $548 (all-in) | -4% |
| Fargate | 0.25 vCPU, 0.5GB, 2 tasks | $29.42 | -95% |
| Fargate + Spot | Same config, 70% Spot | $17.10 | -97% |
| EC2 (On-Demand) | t4g.micro (2 vCPU, 1GB) | $6.05 | -99% |
| EC2 (Savings Plan) | t4g.micro, 1yr Compute SP | $3.87 | -99% |
Read that table again. A single t4g.micro EC2 instance at $6.05/month can handle 100M+ simple API requests per month (assuming roughly 3,200 requests/second throughput with Go or Rust). Lambda costs 94x more for the same throughput. Even Fargate with two tasks is 95% cheaper.
Where the Crossover Happens
Lambda is cheaper than Fargate when your average utilization stays below roughly 10-15% of a full compute unit. Here is the practical breakdown:
- Lambda wins: Under 5-10M requests/month, highly variable traffic, cron jobs, event processors, webhooks, background tasks that sit idle most of the day
- Fargate wins: 10M-100M requests/month, somewhat predictable traffic, long-running processes, workloads that need more than 15 minutes of execution
- EC2 wins: 100M+ requests/month, steady-state traffic, latency-sensitive workloads, teams that can manage their own infrastructure
The most expensive mistake we see is teams running Lambda at steady high volume because "serverless is cheaper." It is not. Not at scale. The second most expensive mistake is running EC2 for sporadic workloads because "servers are simpler." They are simpler, but you pay for every second they sit idle waiting for the next request.
Provisioned Concurrency: The Cold Start Tax
Lambda cold starts add anywhere from 100ms to 5 seconds of latency depending on your runtime, VPC configuration, and package size. For a user-facing API, a 3-second cold start on a Java function is not a minor inconvenience. It is a broken experience.
Provisioned Concurrency is AWS's answer. It keeps function instances pre-initialized and ready to go. The tradeoff? It fundamentally changes Lambda's cost math.
Provisioned Concurrency Pricing
| Component | Rate |
|---|---|
| Provisioned capacity (idle) | $0.0000041667 per GB-second |
| Provisioned duration (active) | $0.0000097222 per GB-second |
| Requests | $0.20 per 1M (same as on-demand) |
What this looks like in real dollars: A 512MB function with 100 provisioned instances costs:
- Idle cost: 100 x 0.5GB x 86,400 sec/day x $0.0000041667 = $18.00/day ($540/month)
- Active duration: Billed on top of that when functions actually execute
- Requests: Standard per-request rate
Now compare that to on-demand Lambda for the same 512MB function processing 10M requests at 200ms: roughly $20/month.
That is a 27x cost increase. Provisioned Concurrency only makes sense when:
- P99 latency requirements are non-negotiable (you absolutely need sub-100ms response times)
- Traffic is predictable enough that you can set the right provisioned level without massive waste
- The cold start is genuinely painful (Java/JVM functions with large dependency trees, not a 50ms Node.js init)
For most workloads, Lambda SnapStart (available for Java runtimes) or keeping functions warm with scheduled CloudWatch Events is a far more cost-effective way to handle cold starts.
7 Strategies to Cut Your Lambda Bill by 30-50%
These are the optimizations we implement most often for clients running production Lambda workloads. They are ordered by impact.
1. Switch to ARM64 (Graviton2): Save 20% Instantly
ARM64 Lambda functions cost 20% less per GB-second and run on AWS Graviton2 processors. For Node.js, Python, and Go functions, this is a one-line configuration change with zero code modifications. Java and .NET functions may need minor dependency updates, but the savings are automatic and immediate.
# SAM template
MyFunction:
Type: AWS::Serverless::Function
Properties:
Architectures:
- arm64
If you do nothing else from this list, do this one.
2. Right-Size Memory Allocation: Save 20-40%
This is counterintuitive, so read carefully. Lambda CPU scales proportionally with memory. A function at 128MB gets a tiny fraction of a vCPU. At 1,769MB it gets a full vCPU. Increasing memory often reduces your total cost because the function finishes faster and the shorter duration more than offsets the higher per-second rate.
We have seen functions running at 128MB for 800ms that drop to 150ms at 512MB. The 512MB configuration costs less because 0.5 x 0.15 = 0.075 GB-seconds, compared to 0.125 x 0.8 = 0.1 GB-seconds at 128MB. Faster and cheaper.
Use AWS Lambda Power Tuning to find the sweet spot for each function. In our experience, the optimal setting is almost never where teams initially configured it.
3. Replace NAT Gateway with VPC Endpoints: Save $0.045/GB
If your Lambda functions call AWS services (DynamoDB, S3, SQS, Secrets Manager) from within a VPC, use VPC endpoints instead of routing through NAT Gateway. Gateway VPC endpoints are free. Interface VPC endpoints cost $0.01/hour plus $0.01/GB, which is still 78% cheaper than NAT Gateway at $0.045/GB.
This single change has saved some of our clients more money than all other Lambda optimizations combined.
4. Control CloudWatch Logs: Save 15-30%
Four changes that make a real difference:
- Set log retention policies to 7-30 days for most functions. The default retention is forever, and "forever" gets expensive fast.
- Use structured JSON logging at appropriate levels. No DEBUG in production. Seriously.
- Filter unnecessary output at the application level before it ever hits CloudWatch.
- For long-term storage, route logs to S3 via Kinesis Firehose at $0.023/GB/month instead of paying $0.03/GB/month in CloudWatch.
5. Use HTTP API Instead of REST API Gateway: Save 71%
HTTP API Gateway costs $1.00 per million requests. REST API Gateway costs $3.50. Unless you specifically need REST API features (API keys, request validation, WAF integration, usage plans), make the switch. At 100M requests/month, this one change saves $250.
6. Batch and Debounce Event-Driven Functions
Instead of triggering a Lambda function for every single SQS message or DynamoDB stream record, configure batch sizes. Processing 10 records per invocation instead of 1 reduces your invocation count by 90%, which cuts request charges and eliminates 90% of cold start potential.
# SAM template - SQS batch
Events:
SQSEvent:
Type: SQS
Properties:
Queue: !GetAtt MyQueue.Arn
BatchSize: 10
MaximumBatchingWindowInSeconds: 5
This is especially impactful for high-throughput event pipelines where each individual message takes only a few milliseconds to process.
7. Know When to Leave Lambda
If your Lambda bill exceeds $500/month for a single workload, run the Fargate/EC2 comparison from the section above. At sustained high volume, migrating to Fargate with Spot capacity or EC2 with Savings Plans typically saves 60-90%.
Lambda's operational simplicity has real value. Not having to manage servers, patches, and scaling logic is worth something. But it is not worth $500+/month for a workload that could run on a $30 Fargate task. Be honest about the math.
When Lambda Is the Right Choice (And When It Is Not)
Lambda Wins
- Sporadic workloads: Cron jobs, webhooks, file processors triggered a few thousand times per day. You pay nothing when they are idle.
- Variable traffic: APIs with 10x-100x traffic spikes that would require massive over-provisioning on fixed compute. Lambda absorbs spikes effortlessly.
- Event-driven pipelines: S3 triggers, DynamoDB streams, SQS consumers processing a few million events per month. The per-event pricing model is perfect here.
- Rapid prototyping: Ship an API in hours without thinking about infrastructure. Get to market, then optimize later.
- Multi-tenant isolation: Per-request isolation without container orchestration overhead. Each invocation is a clean environment.
Lambda Loses
- Steady high-volume APIs: 50M+ requests/month at predictable traffic. Fargate or EC2 is 90%+ cheaper at this scale.
- Long-running processes: Anything approaching the 15-minute execution limit. Use Fargate or Step Functions instead.
- Latency-critical paths: Sub-10ms P99 requirements are nearly impossible with Lambda's inherent invocation overhead and cold start risk.
- Heavy compute: Image processing, video transcoding, ML inference. These need EC2 with GPUs or Fargate with large task definitions.
- Cost-sensitive workloads at scale: When every dollar matters and your team can manage infrastructure, always-on compute wins on pure cost every time.
The Bottom Line
AWS Lambda's per-request pricing is transparent but incomplete. The $0.20/1M requests and $0.0000166667/GB-second charges typically represent just 20-40% of your actual serverless bill. API Gateway, CloudWatch Logs, NAT Gateway, and data transfer quietly fill in the rest.
Lambda is genuinely cost-effective for workloads under 10-15 million monthly invocations with variable traffic patterns. Above that threshold, the math favors Fargate or EC2 by a wide margin. The most common mistake we see at LeanOps is teams running steady-state API workloads on Lambda because they assumed serverless is always cheaper, without ever modeling the full cost stack.
If your serverless bill is growing faster than your traffic, our cloud cost optimization team specializes in Lambda-to-Fargate migration analysis and full-stack serverless cost optimization. We typically cut serverless bills by 40-60% within 90 days, or you do not pay. Start with a free Cloud Waste Assessment.
Further reading:
