Serverless bills stay tiny right up until one pattern in your code turns a $20/month function into a $2,000 invoice. The pricing model is per-invocation and per-millisecond, which means every inefficiency you’d never notice on a fixed VM gets billed to you directly, at scale.

Cold starts you pay to avoid

Provisioned concurrency keeps functions warm so users don’t eat a cold-start latency hit — but you’re billed for that reserved capacity whether it’s invoked or not, essentially turning part of your serverless function back into an always-on server, at serverless per-unit pricing. If you find yourself reaching for provisioned concurrency everywhere to fix latency complaints, that’s a sign the workload doesn’t actually fit the serverless model anymore, and a small always-on instance would be cheaper.

Chatty functions calling functions

A function that calls another function, which calls another, multiplies your per-invocation cost and adds latency at every hop. This creeps in gradually as a codebase grows — someone splits a function “for separation of concerns” and now every request pays for three cold starts and three invocation charges instead of one.

Before: 1 function, 200ms, $0.0000042/invocation
After:  3 functions chained, 650ms total, $0.0000126/invocation + retry risk

Combine what you can into a single function unless you genuinely need independent scaling or deploy cadence for each piece.

Retries multiplying failures

Serverless platforms retry failed invocations automatically, by default, multiple times. If a downstream dependency is down and every request fails, you’re now paying for 2-3x the invocation volume of your actual traffic, and possibly hammering the downstream service harder while it’s already struggling. Set retry limits explicitly and use a dead-letter queue instead of unlimited automatic retries.

Data transfer and API gateway fees, not the function itself

Teams price out the function’s per-millisecond cost and forget the API gateway fee sitting in front of it, which is often billed per-request independent of function cost, plus data transfer out. On a high-traffic endpoint, the gateway and egress can dwarf the compute cost that got all the attention during planning.

Log volume nobody capped

Verbose logging on a function invoked millions of times generates a log ingestion bill that scales with traffic just like compute does, and it’s easy to miss because it shows up as a separate line item on a different service. Set log retention and sampling on high-volume functions instead of logging every request at full verbosity forever.

The workload shapes that don’t fit

Serverless is billed for being efficient at spiky, low-average-utilization workloads. It stops being cheap once you have:

Watch it before it surprises you

Set a billing alert at a real threshold, not the default. A serverless bill runaway looks nothing like a runaway VM bill — there’s no server to notice is on fire, just a number in a dashboard nobody’s watching until the invoice arrives.

aws budgets create-budget --account-id 123456789012 \
  --budget file://serverless-budget.json \
  --notifications-with-subscribers file://alert.json

The gotcha

The bill that blindsides people is never the steady-state cost — it’s the retry storm, the recursive trigger loop (a function writing to a bucket that re-triggers the same function), or the chatty fan-out nobody load-tested. Load-test failure paths, not just the happy path, before you trust serverless pricing at production scale.