"Serverless is cheaper" and "containers are cheaper" are both true statements, depending entirely on the workload's traffic pattern. We get asked to settle this debate regularly, and the honest answer requires actually modeling the specific workload rather than applying a blanket rule.
The Variable That Actually Matters: Traffic Pattern Shape
Spiky, Low-Baseline Traffic → Serverless Usually Wins
Workloads with long idle periods and occasional bursts (internal tools used a few times a day, webhook processors, scheduled batch jobs) pay for containers even during idle time, while serverless functions cost nothing when not invoked. For this shape, serverless is typically the clear cost winner.
Steady, High-Volume Traffic → Containers Usually Win
Workloads with consistent, high request volume around the clock benefit from containers' ability to amortize fixed capacity across continuous usage. At sufficient scale, Lambda's per-invocation pricing model costs more than a right-sized container fleet running the same workload continuously.
A Concrete Cost Model
For a workload handling roughly 10 million requests/month at 200ms average execution time and 512MB memory:
Lambda cost: Roughly $0.0000166667 per GB-second plus $0.20 per million requests. At this volume, this lands in the range of several hundred dollars per month.
Container equivalent (ECS Fargate): A right-sized fleet handling the same sustained volume, running continuously, typically costs less at this specific volume level — the crossover point where containers become cheaper than Lambda for steady traffic usually falls somewhere in the range of a few million to tens of millions of monthly invocations, depending heavily on execution duration and memory allocation.
The exact crossover point shifts significantly based on function duration, memory configuration, and how "steady" the traffic actually is — which is why we model the specific workload rather than quoting a universal number.
Factors Beyond Raw Compute Cost
Cold Starts
Serverless functions incur cold start latency on infrequent invocation, which can matter for latency-sensitive user-facing endpoints even when the raw compute cost favors serverless. Provisioned concurrency mitigates this but adds cost that partially erodes serverless's cost advantage for spiky workloads.
Operational Overhead
Containers require more operational investment — cluster management, scaling configuration, patching — even when using managed services like Fargate. Serverless shifts more of this operational burden to the cloud provider, which has a real (if harder to quantify) cost benefit in engineering time saved.
Vendor Lock-In Considerations
Deep use of provider-specific serverless features (Lambda-specific triggers, proprietary event sources) increases migration cost if a future move to a different cloud provider or architecture becomes necessary. Containers, by contrast, are more portable across environments.
Our Approach: Model Before Deciding
Rather than defaulting to either pattern, we build a cost model using the workload's actual or projected traffic pattern, request volume, and execution characteristics, comparing realistic Lambda pricing against a right-sized container deployment before recommending an architecture. For many real-world systems, the right answer is actually a hybrid — serverless for spiky, event-driven components, and containers for steady-state core services.
Results
For one client running an event-processing pipeline, this analysis revealed their existing all-serverless architecture was costing meaningfully more than a hybrid approach would, specifically because one high-volume, steady-traffic component was a poor fit for Lambda pricing. Migrating just that component to a small container fleet while keeping the rest serverless produced a substantial reduction in the affected component's cost with no architectural overhaul needed elsewhere.
Not sure whether your workload is a better fit for serverless or containers? Get a cost model built for your specific traffic pattern — 907-841-8407 or contact@rutagon.com.
Frequently Asked Questions
Is serverless always cheaper than containers?
No. Serverless tends to be cheaper for spiky, low-baseline traffic with significant idle time, while containers tend to be cheaper for steady, high-volume traffic that can amortize fixed capacity continuously. The actual crossover point depends on the specific workload's traffic pattern and execution characteristics.
What is the crossover point where containers become cheaper than Lambda?
It varies significantly based on function duration, memory allocation, and traffic steadiness, but for many workloads it falls somewhere between a few million and tens of millions of monthly invocations. We model the specific workload rather than relying on a universal number.
Does serverless reduce operational overhead compared to containers?
Generally yes — serverless shifts more infrastructure management to the cloud provider, reducing time spent on cluster management, scaling configuration, and patching, which represents a real cost savings in engineering time even when raw compute cost is comparable.
Can a single application use both serverless and containers?
Yes, and for many real-world systems this hybrid approach is actually optimal — serverless for spiky, event-driven components and containers for steady-state core services, each matched to the traffic pattern it handles best.
How do cold starts affect the serverless cost equation?
Cold starts add latency for infrequently invoked functions, which can matter for latency-sensitive endpoints. Mitigating this with provisioned concurrency adds cost that can partially offset serverless's cost advantage, which is a factor worth including in any serverless-vs-container cost model.