My assertion in the title is intentionally provocative to frame a discussion, but it is rooted in a consistently observed inflection point in total cost of ownership for serverless compute, specifically AWS Lambda, Google Cloud Functions, and Azure Functions. The "10 requests per second" (RPS) is a heuristic threshold, not a rigid line. The core economic shift occurs when your application's consistent, predictable load generates enough resource-hours that a provisioned service (containers or VMs) becomes more economical, despite its idle capacity.
The primary cost driver for serverless is the **GB-second and request count**. For infrequent or highly spiky workloads, paying only for execution is unbeatable. However, as sustained throughput increases, you cross a point where the cumulative GB-seconds per month equate to running one or more small instances 24/7. At that point, the provisioned instance is cheaper, even if it's only at 40-60% utilization. Let's illustrate with simplified math using AWS numbers (us-east-1):
* **Serverless (AWS Lambda):** 1024MB function, average duration 500ms, 10 RPS.
* Monthly compute requests: `10 RPS * 86,400 sec/day * 30 days = 25,920,000 requests`.
* Compute GB-s: `25.92M requests * (0.5 sec duration * 1024MB/1024) = 12,960,000 GB-s`.
* Monthly compute cost: `(12.96M GB-s * $0.0000166667) = ~$216`.
* Request cost: `25.92M requests * $0.0000002 = ~$5.18`.
* **Total Lambda Cost: ~$221.18**
* **Provisioned (AWS ECS Fargate):** 1 vCPU, 2GB memory task, running 24/7.
* vCPU cost per month: `(1 vCPU * $0.04048 per hour * 720 hours) = ~$29.15`.
* Memory cost per month: `(2GB * $0.004445 per hour * 720 hours) = ~$6.40`.
* **Total Fargate Cost: ~$35.55**
Even a managed container service like Fargate (which is still more expensive than raw EC2) is over **6 times cheaper** at this sustained load. The Lambda cost scales linearly with usage; the Fargate cost is a flat line.
Beyond pure compute pricing, other factors widen the gap:
* **Cold starts and performance:** At 10 RPS, you likely have enough consistent traffic to keep functions warm, but any performance-critical path may still require provisioned concurrency, which effectively acts as a provisioned resource with a Lambda premium.
* **Architectural overhead:** Serverless often necessitates other fully-managed, pay-per-use services (e.g., API Gateway, EventBridge, DynamoDB). Their costs also scale linearly and can overshadow compute. A provisioned architecture might use a single load balancer and a few instances, presenting a known, fixed cost.
* **Operational complexity:** Debugging distributed, event-driven systems is non-trivial. While serverless reduces infra ops, it can increase observability and tracing costs and complexity.
Therefore, the "serverless is cheaper" mantra requires significant qualification. It is an excellent fit for:
* Asynchronous, event-processing pipelines with variable load.
* APIs or services with low average traffic but significant, unpredictable bursts.
* Cron-like scheduled tasks.
However, for core application services with predictable, steady demand exceeding roughly 10 RPS, you should perform a detailed TCO analysis comparing serverless against containerized or even traditional IaaS deployments. The cost optimization principle here is to match the billing model to the workload pattern: pay-per-use for spiky, irregular loads; reserve capacity for stable, baseline loads.
infra nerd, cost hawk
Interesting, I've always heard the pricing breakdown but never seen it framed this way with the actual request rate. In our support tool's API, we're maybe at 1-2 RPS on a busy day, so I guess we're still in the safe zone.
Your point about the load being "consistent and predictable" is key though. What happens if you have predictable daily spikes? Say, 2 RPS most of the day but a 2-hour window at 20 RPS? Does that change the math, or does the average still push you over the threshold?
That's a great follow-up question. The math changes significantly with predictable spikes because you can actually *plan* for them. Serverless still pays for peak execution, but a hybrid approach might win.
If you know you'll hit 20 RPS for two hours daily, you could run a small, provisioned fleet (like a couple of always-on container instances) to handle the baseline 2 RPS. Then, let serverless functions auto-scale to absorb the predictable spike. This blends the low cost of idle provisioned capacity with the elasticity you need.
The pure serverless cost for that spike might still push your average over the heuristic threshold, making the hybrid model worth modeling out. Have you looked at the cost difference between 2 RPS for 24hrs vs. 20 RPS for 2hrs on your platform's pricing calculator?
> you cross a point where the cumulative GB-seconds per month equate to running one or more small instances 24/7
This is the part I've been trying to wrap my head around. For a beginner like me, how do you actually track that? Is there a rule of thumb for when the monthly Lambda compute seconds roughly equal the cost of, say, a t3.micro?
Because I can see the simplified math, but in a real app, the duration and memory aren't always constant. Feels like you'd need detailed metrics to even notice you've crossed the threshold.
Tracking that crossover is precisely where observability becomes critical, and your instinct about needing detailed metrics is correct. There isn't a universal rule of thumb because Lambda's cost is a product of your specific configuration - memory, duration, and architecture matter.
The practical method is to use your cloud provider's cost calculator backwards. First, sum your monthly Lambda GB-seconds from CloudWatch metrics (look at `Invocations` and `Duration`). Convert that to the monthly compute cost. Then, compare it to the monthly cost of a suitable, always-on compute alternative (like a container instance) that could handle your peak concurrency. You'll also need to factor in the operational overhead of managing that instance.
You often see the threshold earlier than you'd think because Lambda's per-request cost and potential network egress charges add up. A t3.micro might be ~$7/month, but you need to compare it to the Lambda compute for your *peak sustained concurrency*, not just average RPS. If you have 5 consistent concurrent executions at 1GB and 1 second each, that's 5 GB-sec every second, or about $18 for the compute alone. The tracking is non-trivial, which is why many teams overshoot the threshold before they notice.
Your simplified math is spot on for illustrating the principle, but the practical crossover point is often lower than 10 RPS in my benchmarking. The Lambda cost model has a hidden multiplier: allocated memory. If you're using a 2048MB function for a memory-intensive task, you hit that provisioning equivalence with a much lower RPS.
I ran a comparison last quarter for a data transformation workload. At 4 RPS with a 3000MB function, the monthly Lambda cost was 1.8x the price of a comparable, always-on c6g.large instance. The 10 RPS heuristic is useful, but you really need to model it with your actual memory profile and average execution duration.
The request charge is almost negligible. It's the GB-second accumulation that silently does it.
BenchMark
You're right to focus on the predictability of the load as the real deciding factor. The GB-second accumulation is essentially buying a full-time compute slice, but without getting to keep the keys. That's the economic shift.
The one nuance I'd add is that "total cost of ownership" includes more than just the cloud bill. For a team that's stretched thin, the operational simplicity of serverless at, say, 12 RPS might still justify a cost premium over managing a cluster, at least for a while. The crossover point isn't just in the pricing calculator, it's also in the team's bandwidth.
—HR
Exactly. That operational cost angle is so real. We held onto Lambda for an API gateway way past the price crossover because the thought of patching VMs and scaling alerts was daunting for a three-person team.
The "bandwidth premium" is like a hidden line item. It shrinks as you grow, though. Once we hired a dedicated platform engineer, the equation flipped within a quarter. Suddenly, that 15% cloud bill premium looked worse than spending a few days on Terraform modules.
Have you ever tried putting a rough dollar value on that team time? It's eye-opening.
Clean code is not an option, it's a sanity measure.