Serverless isn't automatically cheap

Serverless gets sold as the end of infrastructure cost management: no servers to size, no idle capacity, pay only for what you use. For spiky, low-volume, event-driven work, that promise is real and it’s wonderful. But “pay only for what you use” quietly becomes expensive when what you use is a lot, and the tuning knobs that control the bill are invisible until you go looking.

Serverless doesn’t remove cost management. It changes what you manage — from provisioning to per-invocation efficiency — and teams that don’t make that shift end up surprised.

Lambda: memory is the dial that controls everything

Lambda pricing is memory × duration. The trap is that memory isn’t just a memory setting — it scales CPU too. So the naive “give it less memory to save money” often increases cost, because the function runs proportionally slower and you pay for the extra duration.

There’s a genuine sweet spot, and it’s per-function, not a global rule:

  # Under-provisioned: cheap per-ms, but slow enough that total cost is higher
- MemorySize: 256
+ MemorySize: 1024   # more CPU, finishes ~4x faster — often lower total cost

Finding it means profiling actual duration at several memory settings and picking the point where cost-per-invocation bottoms out. Set once and forgotten, most functions sit on the wrong side of that curve.

Fargate: still a size you have to pick

Fargate takes the servers away but not the sizing decision — you still choose task CPU and memory, and an over-provisioned task definition is over-provisioned whether or not there’s a server underneath. Same rightsizing discipline as EC2: read the task’s real utilization and match it, instead of copying a number that felt safe.

The crossover point is the real question

The decision that actually moves the bill isn’t tuning — it’s architectural. Serverless wins decisively on spiky, intermittent, low-baseline workloads, where paying per-invocation beats paying for idle servers. But every workload has a crossover point: a level of sustained, predictable throughput where a right-sized, committed container fleet becomes cheaper than paying per-request forever.

A Lambda handling a few thousand calls a day is a bargain. The same Lambda handling millions of steady calls an hour may cost several times what a small, committed Fargate or EC2 service would. Neither choice is wrong; running past your crossover point without noticing is.

You can’t see the crossover without the data

Every serverless cost decision — the memory sweet spot, the Fargate size, the crossover point — requires joining invocation volume, duration, and cost, then comparing against what the always-on alternative would run. That data exists across your billing and metrics, but it’s split across systems and nobody’s watching the curve, so functions drift onto the wrong side of it and stay there.

That’s the visibility Lizrd brings to serverless: it reads invocation patterns and cost together, flags the functions sitting off their efficiency sweet spot and the high-volume workloads that have crossed into “a container would be cheaper,” and proposes the tuning or migration as a concrete change. Serverless is cheap right up until it isn’t — and the only way to know which side you’re on is to look.