- Lambda's base price ($0.20 per 1M requests) represents only 20–40% of your actual bill; API Gateway, logging, and data transfer add 60–80% in hidden costs.
- A typical 10M-request API costs $10 in raw Lambda compute but $57 total once you factor in supporting services—and cold starts destroy performance that kills conversions.
- Below ~1M requests per day, serverless wins on cost; above that, a single always-on container instance typically beats per-invocation pricing by 2–3x.
Your serverless architecture isn't cheap. It just looks cheap until the bill arrives.
You've probably seen AWS Lambda's headline pricing: $0.20 per 1 million requests and $0.0000166667 per GB-second on x86. On paper, that's a bargain. A 10M-request API with 256MB memory and 200ms average execution time should cost about $10. Except it doesn't. The real bill for that same workload lands around $57—and that's before you hit any scale or performance optimization.
The gap between what you think you're paying and what you actually pay comes from hidden fees buried across AWS's ecosystem. They're not surprises in the sense of being undisclosed; AWS lists them all publicly. They're surprises because most teams don't add them up until reconciliation time.
Where the Real Costs Hide
Lambda's base compute charge is straightforward enough. But the moment you connect it to anything—an API, a database, monitoring—you enter a fee structure that compounds fast.
API Gateway is the first shock. Every request your Lambda function receives likely routes through API Gateway, which charges $3.50 per million requests. On a 10M-request API, that's $35 alone—before Lambda executes once. API Gateway also charges for data transfer out ($0.09 per GB). A modestly chatty API can double or triple this line item.
CloudWatch Logs is the silent killer. Lambda functions generate logs by default. CloudWatch charges $0.50 per GB ingested and $0.03 per GB stored. A function logging just 1KB per invocation on 10M requests per month ingests 10GB—$5 ingestion plus storage. Verbose logging (which debugging often demands) can easily hit $50–100 monthly on moderate workloads.
Data transfer and egress add another layer. Any data leaving your AWS region costs $0.09 per GB. If your Lambda crosses availability zones or exits AWS entirely (to call third-party APIs), costs multiply. A function calling external APIs 10M times with 5KB per call is 50GB out—$4.50 minimum, but often much higher depending on destination.
Provisioned concurrency is where serverless teams usually break. If you use Provisioned Concurrency to avoid cold starts, you pay $0.0000041667 per GB-second on x86. A modest always-on configuration—say, 10 instances of 512MB each—costs over $100 monthly before a single extra invocation. This moves you off the "pay per use" promise entirely.
Supporting services (DynamoDB, SQS, SNS, S3) each add their own pricing tiers. A serverless architecture typically couples Lambda to at least two or three of these. DynamoDB on-demand mode charges per request; provisioned mode charges per hour regardless of usage. SQS charges per million requests. S3 charges for storage, requests, and transfer. These services aren't optional—they're the glue holding serverless together—but their costs are almost always underestimated in the architecture phase.
The Real Math: Where 5x Comes From
Lambda's base compute typically represents just 20–40% of the actual bill. The remaining 60–80% spreads across the ecosystem. Here's a realistic breakdown for that 10M-request API:
| Component | Monthly Cost | % of Total |
|---|---|---|
| Lambda compute | $10 | 18% |
| API Gateway requests | $35 | 61% |
| CloudWatch Logs | $8 | 14% |
| Data transfer | $4 | 7% |
| Total | $57 | 100% |
Scale this to 100M requests monthly, and the gap widens. The real bill becomes 2–5x the raw function cost because each supporting service scales with throughput while remaining hidden from initial estimates.
Memory and duration matter too. A function running 1M times per month at 128MB and 200ms average duration costs ~$0.63, but the same workload at 1GB and 1-second duration jumps to ~$16.87 monthly for just the compute component. Add supporting services, and you're easily 10–15x higher.
Cold Starts: The Invisible Revenue Killer
Hidden costs aren't only financial. Cold starts—the latency spike when Lambda initializes a new container—erode user experience and conversions in ways that don't show up on your AWS bill.
A 1-second delay in page load time cuts conversions by approximately 7%. Cold starts routinely add 2–5 seconds. On a B2B SaaS product where leads matter, this is a revenue problem masquerading as an infrastructure problem.
Leads contacted within 5 minutes achieve a 32% close rate, which is 2.6x higher than the 12% close rate for leads contacted after 24+ hours. If your serverless API adds 3 seconds to lead capture, you're not just degrading experience—you're losing deals. Fixing this typically means Provisioned Concurrency, which costs $100–200 monthly and defeats the entire cost premise of serverless.
When Serverless Actually Wins
This isn't a case against serverless. It's a case for building the right infrastructure for your actual workload.
At low volume (under ~1M requests per day), serverless is almost always cheaper than equivalent containers. If you're running a low-traffic service, experimental product, or background worker that executes sporadically, serverless remains genuinely cost-effective. The hidden fees are real, but they're smaller in absolute terms.
Above that threshold, a single always-on container instance typically beats per-invocation pricing by 2–3x when you sum up everything. A t3.medium on EC2 costs about $30 monthly and can handle millions of requests without per-request charges. No API Gateway fees. No per-invocation logging charges. No Provisioned Concurrency tax.
The decision isn't about serverless versus containers. It's about workload volume and predictability. Serverless excels at variable, low-to-moderate traffic. It crumbles at consistent, high-volume workloads where you end up paying for capacity you're going to use anyway.
Building for Realistic Costs
If you're committed to serverless, cost control requires discipline:
- Right-size memory aggressively. Lambda bills for memory × duration. Allocating 1GB when 512MB handles the workload is throwing money away. Test real-world invocations and size down.
- Log strategically. Disable verbose logging by default. Route critical logs to a dedicated logging service, not CloudWatch. Implement structured logging with sampling for high-volume functions.
- Cache aggressively. Use ElastiCache or DynamoDB DAX to avoid repeated database hits. Each avoided call saves both Lambda invocation costs and supporting service costs.
- Batch operations. Instead of invoking Lambda 1M times for 1M items, process batches. Fewer invocations mean lower API Gateway and Lambda costs.
- Monitor cost per feature. Instrument your functions to track cost alongside performance. You'll spot which features generate outsized infrastructure expense and can optimize or reconsider them.
If you're building a product that demands both scale and speed—like real-time data monitoring systems or AI-powered logistics platforms—the architecture decision directly impacts both margins and user experience. Getting it right often means starting with a technical assessment of realistic traffic, latency requirements, and cost exposure before committing to a platform.
FAQ
Does Provisioned Concurrency ever make sense financially?
Yes, but only if you genuinely need to eliminate cold starts for user-facing traffic. If cold starts are a performance issue that's affecting conversions or user retention, the cost is justified. If you're trying to avoid cold starts purely for elegance, you're paying a tax. Provisioned Concurrency should come as a last resort after optimizing function size, memory allocation, and caching.
How do I know if serverless is still the right choice for my product?
Calculate your actual monthly traffic and project 12 months forward. If you're consistently above 1–2M requests per day and traffic is predictable, run a cost comparison against a single t3.medium or t3.large instance. Factor in all supporting services (databases, logging, API Gateway), not just Lambda compute. If the always-on instance is cheaper, you've outgrown serverless economically.
Can I reduce API Gateway costs without abandoning serverless?
Partially. Use API Gateway's caching feature for GET requests (charges still apply, but reduce Lambda invocations). If you control the client, use HTTP/2 connection reuse to batch requests. For internal services, skip API Gateway entirely and use direct Lambda invocation or EventBridge. For public APIs, API Gateway is standard, and the cost is baked in—plan for it.
What's the real cost of a cold start in dollar terms?
Cold starts don't appear as a separate line item on your bill, but the performance hit (2–5 seconds extra latency) translates to lost conversions at ~7% per second of delay. On a B2B SaaS with a 5% conversion rate and $200 average contract value, every cold start on a lead capture API costs roughly $7 in expected revenue. That compounds across thousands of invocations monthly.
