What 'Serverless' Actually Costs You (The Part the Video Skipped)

I am starting a new AWS Micro-learnings series and this video, "What Serverless Actually Means" is the first of the series.

It walks you through what serverless actually means. And that means, you have stop thinking about the machine and start thinking about paying per execution.

This is the right way to think about serverless.

But the video (for simplicity's sake) doesn't answer one important question you should ask when deciding whether to use it:

Is it cheaper for you?

So, here's the deeper dive.

Lambda's per-invocation pricing is great when your traffic is spiky (i.e. unpredictable) or low. But if you run enough volume through it, a steadily-busy EC2 instance, or a container on Fargate, can actually be cheaper.

That's because you're no longer paying a per-invocation premium on top of compute time.

Now, it's important to know that a breakeven point isn't a fixed rule of thumb. It depends on your memory configuration, average execution duration, and what you're comparing Lambda against.

For a 512MB function averaging 200ms, that breakeven lands around 8 million invocations a month against a single always-on t3.small. Your own numbers will move with memory and duration, but the shape of the curve doesn't change.

Lambda scales linearly with volume. A server doesn't.

This is the math you need to do before you commit to "serverless" as the answer.

Here's the thing that can't really fit in a less than 2 minute video:

"No capacity planning" doesn't mean "no limits."

Lambda concurrency caps are real, per-region and per-account, and a traffic spike can throttle you before it ever shows up as a cost problem.

Serverless doesn't remove the planning problem, it just moves it.

You're planning for concurrency ceilings and cold start tolerance instead of server counts.

So before you go serverless for something, run your expected invocation volume and duration through a cost calculator.

The micro-learning video gives you the model.

You need to find the number that actually applies to you.

Comments

[Raknaos]

The shape-of-the-curve framing is right, and the per-invocation premium is the number people skip because it only shows up on the invoice. The two variables that moved our breakeven most were duration variance and the memory-to-vCPU coupling: you often buy memory you don't need just to get a fair share of CPU, so the per-invocation cost at p50 hides what p95 costs when a cold container does the real work. Provisioned concurrency then adds back exactly the always-on cost you moved away from, but only on the floor of the curve.

Did you model the cold-start tail as a cost or just as latency? In our case the same job retried because the first attempt timed out warm-up, so the effective breakeven against a small always-on box arrived noticeably earlier than the single-attempt math suggested. Curious whether you'd put a retry multiplier into the calculator you're recommending, or keep the series one-variable-at-a-time.

[Joanne Skiles AWS Community Builders]

Good catch, and yes, the premium hiding until the invoice arrives is exactly why it doesn't make it into a 2 minute video.

Memory-to-vCPU coupling is the one people miss most: you're often overpaying for memory just to get CPU headroom, and that shifts the curve before duration variance even shows up.

The model in this post treats cold start as latency, not cost. And for simplicity, single-attempt math with no retry multiplier. A retry that eats a timeout because the container wasn't warm yet is a cost event, and if that's a normal pattern in your traffic, your real breakeven arrives earlier than what the calculator shows.

For this series I'm keeping it one-variable-at-a-time on purpose. This is because when you are starting off learning you need the base model before the compounding effects make sense. But the p50-vs-p95 gap and a retry multiplier are worth their own post. Might steal that framing for future deep dive.