Serverless Is Not Cheaper by Default

The pitch is clean: you pay only for what you use. No servers idling at 3 a.m., burning cash. No capacity planning. Just functions that appear when needed and disappear when done. Serverless feels like the ideal everyone was waiting for — and sometimes it actually is. Then the bill shows up.

A developer I know — an experienced guy, not some junior making rookie mistakes — built what looked like a simple proof of concept. AWS Bedrock knowledge base, OpenSearch Serverless backend. Nothing fancy. A few LLM queries, maybe 2 GB of PDFs uploaded for testing. He was expecting maybe twenty or thirty bucks. The invoice came back at over $200. He spent an hour just staring at the line items, trying to figure out what happened. No error, no hack. Just the way it works.

This is what you eventually learn if you stick with serverless long enough: it doesn’t make cost complexity vanish. It just moves the complexity into places you weren’t looking. Traditional infrastructure makes you pay upfront for capacity whether you use it or not. Serverless makes you pay for orchestration, for state management, for all the little services that keep running in the background even when you think nothing’s happening. Different complexity, same pain.

What They Don’t Tell You About “Serverless”

That OpenSearch Serverless thing? It bills in OCUs — OpenSearch Compute Units. Even when completely idle, there’s a minimum cluster that has to stay alive: two OCUs for indexing and two for search. About $0.24 per OCU per hour. Do the math and you’re looking at roughly a $350 monthly baseline before you’ve indexed a single document.

The word serverless suggests things appear and disappear as needed, right? Ephemeral. But search indices can’t just materialize out of thin air when a query comes in. The data structures have to live somewhere, in memory, consuming resources — and costing money.

This shows up everywhere once you know to look for it. Step Functions charge per state transition. Build a nice, clean workflow with lots of states — which seems like good practice for readability — and you’re paying for every decision node and retry. Cloud Functions bill by invocation but also by GB-seconds of allocated memory. Configure a function with 2 GB of RAM and it costs twice what a 1 GB function costs per second, even if neither one actually uses the full allocation. Durable Functions store orchestration history in blob storage, so now your function costs include table operations and transaction fees you didn’t plan for.

None of this is exactly hidden. It’s all documented. But the mental model — “I only pay when my code runs” — doesn’t naturally extend to “I also pay for the orchestration layer, the persistent queues, the NAT gateway, the log ingestion, the metrics system, and the minimum infrastructure required to make things feel instant.” The simplicity evaporates once you understand what’s actually happening.

Where It Actually Makes Sense

Look, serverless isn’t a scam. For certain workloads, it’s legitimately great.

A webhook that fires twice a day? Perfect fit. A nightly job that runs for six minutes? Ideal. An API that gets a few hundred requests during business hours and goes completely silent overnight? That’s exactly where serverless wins — resources scale to zero, billing follows, and you’re not wasting money on a VM that sits idle 23 hours a day.

The economics work when the duty cycle is genuinely low. A function that runs 10 minutes per day at 512 MB? You’re paying pennies. Compare that to even a t3.micro running 24/7 at maybe $7.50 monthly. The serverless function costs under a dollar. Easy choice.

But watch what happens when cumulative execution time starts climbing. Running functions for hours every day — or worse, continuously? You’d be better off with a container or a right-sized VM. Reserved instances give you 40–60% off. Fargate or ECS, properly configured, often beats serverless once you hit steady-state load.

Then there are cold starts. The first invocation after a function’s been idle takes longer — runtime loads, libraries import, database connections establish. For anything latency-sensitive, that’s unacceptable. So you keep functions warm with scheduled pings or provisioned concurrency. Both approaches kill the cost benefit. Provisioned concurrency charges for reserved capacity whether you use it or not. You’ve basically recreated an always-on server — just more expensive and with less control.

Memory, Timeouts, and Configuration Mistakes

Lambda bills by GB-seconds. Memory allocation multiplied by execution duration. Allocate 1 GB, function runs for 2 seconds — that’s 2 GB-seconds. Around $0.0000166667 per GB-second in us-east-1. Sounds negligible. It adds up fast.

A function invoked 10 million times monthly at 1 GB and 200 ms? That’s 2 million GB-seconds, about $33. Double the memory to 2 GB without the runtime actually needing it and you’re at $66. Over-allocate because you’re not sure what you need? You’re paying for Amazon’s infrastructure.

Here’s the weird part: memory allocation also controls CPU. You can’t tune vCPU independently. More memory means proportionally more CPU. Sometimes increasing memory actually reduces cost because execution time drops faster than the GB-second product grows. A function that runs 400 ms at 512 MB might finish in 150 ms at 1 GB, cutting cost by 25% despite doubled memory. Not intuitive. It depends entirely on your workload. You have to profile and test.

Timeout settings bite people too. The default is often 3 seconds. Developers bump it to 15 minutes “to be safe.” If a function hangs or gets stuck retrying, you’re billed for the full timeout on failed invocations. A function that should take 2 seconds but times out at 15 minutes burns 450× the expected cost on each failure. Lambda retries twice by default on async invocations. One stuck invocation can cost more than a thousand successful ones.

State Machines Get Expensive

Step Functions are elegant — great for coordination, nice visual editor, built-in retry logic. They’re also expensive at scale.

Each state transition costs $0.025 per thousand (Standard Workflows). A workflow with 10 states, invoked a million times monthly? That’s $250 just in state transitions, before you count the Lambda executions those states trigger. Express Workflows are cheaper — $1 per million requests plus duration — but limited to 5-minute execution windows.

A complex workflow like loan approval or multi-step ETL simplifies logic with Step Functions but introduces a recurring cost that never stops. The alternative is to collapse states into fewer, larger functions or handle orchestration yourself with queues. SQS is cheap: $0.40 per million requests after the free tier. A function polls SQS, processes messages, updates DynamoDB for state tracking — this might cost a tenth of the equivalent Step Functions setup. You lose the visual workflow and automatic retry handling, but you get your money back.

Hidden Costs: Logs, Metrics, and Data Transfer

Functions don’t run in isolation. They write logs, emit metrics, talk to databases, and call APIs. Each interaction costs something.

CloudWatch Logs charges for ingestion ($0.50/GB) and storage ($0.03/GB monthly). A function that logs every request and response at INFO level generates gigabytes weekly. Leave that running indefinitely and costs pile up. I’ve seen apps where logging cost more than compute because someone left debug logging on in production and never set log expiration.

Data transfer is worse. Egress to the internet costs $0.09/GB after the first gigabyte. A function scraping external APIs or serving large responses? Egress becomes a real line item. Internal transfers — Lambda to S3 in the same region — are free. Cross-region? You’re paying. A function in us-east-1 reading from RDS in us-west-2 incurs inter-region transfer fees, and they compound fast under load.

Lambda Insights gives you detailed telemetry but costs $0.0000084 per metric monthly, plus CloudWatch charges. X-Ray tracing is $5 per million traces recorded and $0.50 per million retrieved. Small individually. Add up 50 functions, each generating 20 custom metrics and 10,000 traces daily, and you’re looking at $150–200 monthly just for observability.

When to Just Use Containers

High-throughput, always-on applications don’t belong in serverless. An API handling 500 requests per second needs sustained compute. Lambda at that scale is more expensive than Fargate or EKS. A Fargate task with 0.5 vCPU and 1 GB RAM runs about $25 monthly. Lambda serving the same load at 1 GB and 100 ms per invocation costs closer to $100 in execution alone, before API Gateway fees.

Batch jobs? Consider ECS on EC2 with Spot Instances. Spot gives you 70–90% off on-demand pricing. A four-hour batch process might cost $2–3 on Spot versus $15–20 in Lambda GB-seconds. Spot instances can be interrupted, but for fault-tolerant workloads that’s manageable — checkpoint progress, handle interruptions, requeue failures.

If you’re already running Kubernetes, KEDA (Kubernetes Event-Driven Autoscaling) lets you scale deployments to zero when idle. Similar economics to serverless, but with container pricing. More operational complexity — you’re managing a cluster — but costs become far more predictable.

Figure Out Costs Before Production

Most teams discover serverless cost problems after deployment. By then, refactoring is politically painful and technically messy. A better approach is to calculate costs during development.

A function with 512 MB memory, 200 ms execution time, and 1 million invocations monthly:
200 ms × 512 MB = 102.4 MB-seconds per invocation, or 0.1024 GB-seconds.
Times 1 million invocations: 102,400 GB-seconds.
At $0.0000166667 per GB-second, that’s $1.71 in compute plus $0.20 for invocations.
Add CloudWatch Logs: 1 million invocations × 2 KB average log size = 2 GB ingestion = $1.00.
Total: $2.91.

Still cheap. Scale to 100 million invocations monthly? $170 compute + $20 invocations + $100 logs = $290. That’s when reserved capacity starts making sense.

Build this into CI. Tag functions with expected rates and memory profiles. Show cost projections in pull requests. Developers should see “This change adds $X monthly” before merging. It’s not perfect — usage drifts — but it prevents nasty surprises.

There’s Money in Solving This

The confusion around serverless costs creates business opportunities. FinOps tools that parse metrics and billing data, attributing costs to specific functions and teams, are in demand. CloudZero, Vantage, and Infracost all offer serverless breakdowns. Smaller players focus on specific providers — Helius for Cloudflare Workers, Lumigo for Lambda.

Training and consulting work too. Teams adopt serverless reactively, migrating without understanding the new cost model. A consultant who can audit architecture, identify leaks, and recommend hybrids — serverless for spikes, containers for steady load — adds real value. I’ve seen engagements where a week of analysis saved $50k annually by moving three high-volume functions to Fargate and tuning memory on the rest.

Early warning systems are another gap. Something that monitors billing APIs, detects anomalies — like a function suddenly invoked 10× baseline — and alerts before month-end would sell. AWS Budgets is too coarse. A tool that understands serverless semantics and projects “this trajectory suggests $2k monthly by month-end, 4× the historical average” would be genuinely useful.

What You Should Actually Do

Serverless works best for episodic, unpredictable workloads small enough that orchestration overhead doesn’t swamp execution cost. It struggles when applied blindly to always-on services, high-throughput APIs, or complex stateful workflows. The real cost isn’t just execution time — it’s the substrate that makes serverless feel effortless: queues, state machines, logs, metrics, NAT gateways, and minimum cluster sizes.

Before committing, model your workload. Estimate invocations, duration, memory, logging volume, and data transfer. Compare against container pricing. Duty cycle under 10%? Serverless probably wins. Over 50%? Containers or reserved instances are likely cheaper. Between 10–50%? It depends on cold-start tolerance, operational maturity, and team experience.

When the bill arrives, don’t panic. Figure out what you’re paying for. Reverse-engineer the line items. Then decide if it’s worth it. Sometimes it is. Sometimes it absolutely isn’t. That’s just how it works.