What you'll take away
The serverless promise was compelling: pay only for what you use, eliminate idle compute costs, and scale to zero automatically during quiet periods. For the workloads serverless was designed for — event-driven functions, irregular batch processing, infrequent API handlers — it delivers on that promise. The problem is that the same promise was applied to workloads where it doesn't hold: steady-state APIs, high-throughput data processing, and latency-sensitive applications where cold start penalties matter.
The result is a growing class of cloud environments where serverless functions are running at high invocation rates, staying warm constantly to avoid cold starts, and accumulating per-invocation costs that significantly exceed what equivalent always-on container or VM hosting would cost. The 'serverless tax' is the premium paid for the serverless model on workloads that don't benefit from it.
When Serverless Is Actually More Expensive
High-Throughput APIs
AWS Lambda charges per invocation plus per GB-second of compute. At low invocation rates, this is dramatically cheaper than running a container 24/7. At high invocation rates — tens of thousands of requests per hour sustained throughout the day — the per-invocation costs accumulate. A Lambda function handling a high-traffic API can cost more than an equivalent ECS service running at 60% utilisation, which can be further reduced with Savings Plans or Reserved Capacity.
Provisioned Concurrency Anti-Patterns
Lambda's cold start latency — the time required to initialise a new execution environment — is unacceptable for latency-sensitive applications. The solution is Provisioned Concurrency: keeping a number of warm instances ready at all times. But Provisioned Concurrency has an hourly cost that is approximately 60–70% of the equivalent on-demand compute cost. A Lambda function with substantial provisioned concurrency running constantly is approaching the cost structure of always-on compute, without the same flexibility in configuration.
Heavy-Dependency Functions with Large Packages
Lambda's memory/CPU allocation is proportional. If a function requires substantial memory due to a large dependency set — machine learning inference, complex document processing, large SDK initialisation — you're paying for memory-proportional compute on every invocation. A container running the same logic can be right-sized independently of the memory requirement.
The heuristic for serverless economics: if your function runs fewer than 20 hours of total compute per month, serverless is almost certainly cheaper. If it runs more than 700 hours of compute per month, containerised hosting is almost certainly cheaper. The break-even varies by memory allocation and specific pricing.
The Workloads Where Serverless Genuinely Wins
Paying for cloud you're not using?
48-hour turnaround. No obligation.
- Webhook handlers with unpredictable, bursty traffic patterns
- Scheduled jobs that run for minutes or seconds at defined intervals
- Event-driven processing triggered by data uploads or queue messages
- Development and staging environments where idle time dominates
- Infrequently-used internal tools and admin functions
How to Audit Your Serverless Spend
Start with a function-level cost breakdown from your cloud provider's cost explorer, segmented by invocation count, average duration, and memory configuration. For each function over a cost threshold, calculate the total compute hours consumed per month. Compare against the cost of an equivalent containerised workload at your typical utilisation rate, accounting for the management overhead of running containers versus serverless.
The functions most likely to be candidates for migration to containers: any function with provisioned concurrency that runs continuously; any function with consistently high invocation rates throughout the day; any function where cold start mitigation is a significant architectural concern; any function that's been vertically scaled to 1GB+ memory to handle its workload.
The Migration Decision
Migrating from serverless to containers is not a trivial engineering task, and the cost savings need to be weighed against migration cost, added operational complexity, and the loss of the auto-scaling simplicity that serverless provides. The right decision depends on the function's cost trajectory, your team's container operations capabilities, and whether the migration creates a more manageable architecture overall.
GYSP's Cloud & DevOps Engineering practice conducts serverless architecture reviews as part of broader FinOps engagements. The common finding: two or three high-traffic Lambda functions account for a disproportionate share of the serverless bill, and migrating those specific functions to containerised hosting reduces total cloud spend by 15–25% with minimal architectural complexity increase.
“Serverless is not cheaper by definition — it's cheaper for the workloads it was designed for. Using it everywhere because it worked somewhere is how infrastructure costs become mysterious and hard to explain.”
— Ankush, Chief Technology Officer — GYSP.tech
