Serverless: When It Saves Money and When It Doesn't
Key takeaway
Serverless wins decisively for spiky, event-driven, and low-volume workloads, where you'd otherwise pay for idle capacity. It loses on sustained high throughput, where a reserved instance is cheaper, and on workloads sensitive to cold-start latency or needing long-running connections.
Serverless is sold as cheaper and simpler. It genuinely is for a particular shape of workload, and it's neither for others — and the difference is predictable enough to work out in advance.
Where it's clearly the right choice
- Spiky or unpredictable traffic — you pay for execution, not for capacity sitting idle overnight.
- Event-driven processing: file uploaded, message queued, record changed, scheduled job.
- Low-volume internal tools and glue between systems, where an always-on server is mostly idle.
- Small teams without operations capacity — patching, scaling, and availability come with the platform.
Where it works against you
- Sustained, predictable high throughput. Past a certain constant load, reserved instances cost less per request.
- Latency-sensitive user-facing paths, where cold starts add hundreds of milliseconds to the unlucky request.
- Long-running work — most platforms cap execution time, and splitting a job to fit the cap adds real complexity.
- Persistent connections such as WebSockets, which fit the model badly.
- Heavy database use — hundreds of concurrent function instances will exhaust a connection pool without a proxy in front.
The costs that don't appear in the calculator
- Local development and testing are harder; reproducing the environment takes deliberate effort.
- Debugging is distributed by default — you need tracing from the start, not after the first mystery.
- Many small functions means many deployment units, permissions, and configurations to keep coherent.
- Vendor coupling is real: the function code ports easily, the surrounding event plumbing does not.
A practical hybrid
Most mature systems end up mixed: a conventional service for the steady, latency-sensitive core, and functions for background processing, scheduled work, and integrations. That split gets the cost benefit where idleness is expensive without putting cold starts in front of customers. Model your actual request profile — requests per month, duration, memory — against both options before deciding; the answer is usually obvious once the numbers are on the page.