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

Lambda's per-invocation pricing wins for spiky or low traffic, but past a breakeven point an always-on EC2 or Fargate instance is cheaper. How to find the invocation volume where that flips, and why concurrency caps are the planning problem serverless doesn't remove.

chaotictoejamSeptember 11, 2025

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.

Lambda vs always-on EC2 cost breakeven chart

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.