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.
Top comments (1)
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.