When Serverless Makes Sense (And When It Doesn't)

Serverless gets pitched as the answer to every scaling and cost problem. In reality, it's a powerful tool for specific workloads — and a poor fit for others. The teams that succeed with serverless are the ones that match the architecture to the problem.

We've seen serverless cut infrastructure costs by 60% for event-driven workloads and blow budgets for long-running, stateful applications. The difference is knowing when to use it.

Where serverless shines

Serverless excels when your workload is sporadic, stateless, and bounded in duration. API endpoints that handle variable traffic, event processors that react to queues or streams, scheduled jobs that run infrequently — these are ideal. You pay for execution time, not idle capacity.

Cold starts matter less when invocations are measured in seconds and your users tolerate a few hundred milliseconds of latency. For internal tools, webhooks, and background processing, cold starts are often irrelevant.

• Webhooks and event handlers with unpredictable volume
• Scheduled cron jobs (daily reports, cleanup tasks)
• API backends with spiky or low average traffic
• Image or document processing pipelines triggered by uploads

When serverless is the wrong choice

Long-running processes hit timeout limits and force awkward workarounds. Stateful applications require external storage and add complexity. High-throughput, consistently busy services often cost more on serverless than reserved instances because you're paying per invocation at a premium.

Vendor lock-in is real. Lambda's execution model, API Gateway's quirks, and provider-specific triggers create switching costs. If you need multi-cloud or might change providers, serverless can become a liability.

Cost curves and the crossover point

At low and variable traffic, serverless is almost always cheaper: no idle capacity, no over-provisioning. As traffic grows and becomes more consistent, the per-invocation cost of serverless starts to exceed the amortized cost of a few always-on instances.

We model the crossover by comparing monthly serverless cost (invocations × duration × price) against equivalent EC2 or container costs. For most of our clients, the break-even sits somewhere between 1–5 million invocations per month depending on function duration and memory. Above that, we recommend moving hot paths to containers or VMs.

A pragmatic stance

Use serverless for net-new, event-driven, or low-traffic components. Use containers or VMs for core transactional paths and anything that runs continuously. Hybrid architectures — API Gateway and Lambda for edge logic, ECS or EKS for the heavy lifting — are common in production.

The goal isn't to be serverless. It's to match the architecture to the workload and keep optionality where it matters.