Serverless pricing has a sweet spot, and it is real: zero to a few hundred thousand invocations per month, and you are paying cents while someone else manages patching, scaling, and availability zones. The pitch works because the alternative — provisioning, securing, and babysitting a server — has a real labor cost that small teams try hard to avoid.
The problem is that serverless pricing scales linearly with usage, while VPS pricing scales in steps. Past a certain volume, the line crosses the step, and your Lambda bill is suddenly a mortgage payment for compute that would run comfortably on a $6 Hetzner box. The question is where the crossover sits and whether you notice before the invoice arrives.
The pricing trap that catches teams at scale
Take a typical API workload: 10 million requests per month, each averaging 200 ms of execution time with 256 MB of memory allocated. On AWS Lambda in us-east-1, that works out to roughly $34 per month in request charges plus $28 in compute duration charges — about $62 total. That sounds cheap. A single EC2 t3.medium reserved instance costs roughly $25 per month, and it handles the same workload with headroom to spare.
At 100 million requests, the Lambda math shifts to $340 in request charges and $280 in compute — $620 per month. The t3.medium handling 100 million requests might need to become two instances, or it might not, depending on whether the workload is evenly distributed or spiky. Two reserved t3.medium instances run about $50 per month, plus perhaps $20 for a load balancer. The serverless bill is 9 times higher.
The pattern is not specific to AWS. Cloudflare Workers, Vercel Functions, and Google Cloud Run all share the same dynamic: below a threshold, serverless is the cheapest option because you are paying zero for idle time. Above it, reserved compute is cheaper because you are paying by the machine-hour rather than by the invocation. The question is whether your traffic crosses the threshold.
The crossover point depends on your specific workload profile — request count, average duration, memory allocation, and whether your traffic is spiky or steady. A workload that bursts to 10× baseline for two hours a day keeps serverless competitive longer than one with a flat 24/7 curve, because reserved compute sitting idle during the troughs is waste. Run the numbers against your own CloudWatch or Datadog data rather than trusting a general rule of thumb.
What a $6 VPS actually buys you
A Hetzner CX22 (2 vCPU, 4 GB RAM, 40 GB NVMe, 20 TB transfer) costs about $4.50 per month. Add $1.50 for off-site backups. For an always-on Node.js or Go API behind Nginx and Certbot, this machine comfortably handles 30 to 50 million API requests per month if the handler is lightweight — sub-10ms database queries, no heavy image processing, no ML inference.
The equivalent on Lambda, at 50 million requests with 200 ms average duration and 256 MB allocation, runs around $310 per month. That is 69 times the VPS cost.
The catch, of course, is that the VPS costs labor. Someone needs to provision it, keep packages updated, rotate logs, monitor disk usage, and respond to the 3 a.m. alert when the database connection pool saturates. Serverless pricing bakes that labor into the per-invocation cost. Whether the tradeoff makes sense depends on whether your team already has the operational skill to manage a server or whether buying that skill (in the form of a higher compute bill) lets you ship features faster.
The honest answer for a two-person startup: the Lambda bill probably costs less than the opportunity cost of a founder spending Fridays on apt upgrades and kernel patches. The honest answer for a 10-person team with an on-call rotation: the VPS bill plus one person's attention during business hours costs less than the Lambda bill.
The in-between options
You do not have to choose between "everything on Lambda" and "everything on a box in a German data center." The middle ground is wider than most teams assume.
Keep the edge on serverless, move the core to a VPS. API authentication, webhook ingestion, and file upload endpoints tend to be spiky and benefit from serverless scaling. Background workers, batch processing, and database-heavy queries tend to be steady and benefit from reserved compute. Run the former on Lambda or Workers, the latter on a VPS, and route between them with a reverse proxy or a message queue.
Use serverless for staging, VPS for production. The staging environment gets almost no traffic, so serverless there costs cents. Production gets the VPS or reserved instances. The tradeoff is that staging and production now run on different runtimes, which means you will catch runtime-specific bugs only after deploying to production. Whether that risk is acceptable depends on your error budget.
Start on serverless, plan the migration path. Build with a standard HTTP framework — Express, Fastify, Hono — rather than a Lambda-specific handler signature. Wrap it in a serverless adapter for launch. When the bill crosses your threshold, unwrap the adapter and deploy the same handler to a VPS. The migration is a configuration change, not a rewrite.
If you are already on a platform that abstracts away the underlying compute — Fly.io, Railway, or Render — you have effectively bought a managed VPS already. These platforms charge a premium over raw cloud VMs but handle the patching, monitoring, and deployment pipeline. For many teams, the price difference between Railway and raw Hetzner is smaller than the labor cost of managing the bare metal, and the decision collapses to "do I have a person who wants to manage servers."
When the bill tells you it is time
The trigger to revisit your compute architecture is rarely an epiphany. It is a line item on the AWS bill that grew 40% month-over-month while user growth was 15%. When the per-user infrastructure cost is rising, serverless pricing is working against you.
Three signals that push the decision:
- Your API is increasingly steady-state. Spiky workloads are serverless's best case. If your traffic has flattened into a predictable curve because you found product-market fit, reserved compute captures that value.
- Your per-request duration is growing. Lambda bills by gigabyte-seconds. As you add middleware, validation, or database round-trips, the same request count costs more. A VPS bills by wall-clock time regardless of how much work each request does.
- You are paying for provisioned concurrency or reserved capacity. Some teams run enough Lambda that they buy reserved concurrency to avoid cold starts. At that point, you are paying reserved pricing on top of per-invocation pricing — the worst of both models.
None of this means serverless is a mistake. It means serverless is a stage. The same pricing model that got you from 0 to 10,000 users may not be the one that carries you from 10,000 to 100,000. Recognizing that before the bill forces the conversation is the difference between a planned migration and a panicked one.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)