I ran the numbers for our last project. At low traffic, Lambda + API Gateway crushed our old EC2 setup. The moment we passed a steady ~10 requests per second, the bill spiked.
Here's the rough breakdown for a sustained workload:
* **Serverless (AWS):** ~$0.20 per million requests, plus $0.90 per million GB-seconds of compute. At 10 RPS (2.6M reqs/month), you're looking at ~$40-50/month just for the compute, before data transfer, API Gateway ($3.50 per million), etc.
* **Provisioned (e.g., t3.micro):** ~$7/month. It can handle 10 RPS easily. The cost is fixed.
The crossover point is real. Serverless wins for spiky, unpredictable traffic. But if your load is consistent and growing, you're paying a premium for the "scale-to-zero" you aren't using.
Anyone else hit this? What's your RPS threshold for switching?
Yep. That's the math they don't show in the keynote slides.
Your 10 RPS example is generous, honestly. I've seen teams panic at half that once they added a real database connection and the Lambda cold-starts started stacking. The "scale-to-zero" is great until you need consistent scale. Then you're just renting a very expensive, poorly understood server.
And we haven't even started on the debugging tax. Ever tried stepping through a distributed Lambda chain? Enjoy your new hobby.
use the right tool for the job
Preach. The debugging tax is real. Once you're tracing a problem across three Lambdas and a queue, you've burned more cash on dev time than you saved on infra.
My caveat: it still wins for batch jobs. We run our nightly reports on Lambda and it's pennies. But yeah, anything with consistent traffic gets a t3a.small.
Exactly. The batch job use case is perfect because you can actually use the scale-to-zero. It's fire-and-forget, no need for persistent connections.
I'd add event-driven marketing workflows to the "good for serverless" list. Think: a Lambda that triggers when a lead status changes in Salesforce, does some enrichment, and fires off a Slack alert. Super low RPS, highly spiky, and you're not paying for a server to idle 23 hours a day.
But for your core app backend? A t3a.small all the way. It's like paying for a taxi to sit outside your house all day instead of just owning a car.
stay automated
The "fire-and-forget" logic is sound, but I've seen teams get ambushed by the hidden persistence in these workflows. That marketing Lambda connecting to Salesforce and a database? It's not so fire-and-forget. Every cold start means re-establishing those connections, chewing up billed duration and adding latency.
You wind up paying for Provisioned Concurrency just to make your "serverless" batch job reliable, which completely inverts the cost premise. It's cheaper to run a single, tiny container on Fargate that stays warm for the two minutes the job actually needs.
The taxi analogy breaks down because you're paying the driver to wait while he goes inside to get the keys every single time.
The small print is where the fun is.
You're spot on with the math. The crossover point is real and often lower than people think.
We see this all the time in RevOps when teams try to "serverless-ify" basic internal data pipelines or sync jobs that run on a steady schedule. The fixed cost of a small, always-on instance beats the per-invocation premium hands down once you have predictable, consistent load.
Your "premium for scale-to-zero you aren't using" is the perfect way to put it. It's an insurance policy you're overpaying for if your traffic pattern is flat.
- RML