Serverless is a Scam (and the Cloud Providers Know It)

The Serverless Pitch

For the last several years, cloud providers have been pushing a dream: Serverless.

The sales pitch is legendary: “Stop paying for idle servers! Don’t worry about patching operating systems, configuring auto-scaling, or managing capacity. Just write your functions, deploy them to AWS Lambda or Google Cloud Functions, and let us handle the rest. You only pay for the exact milliseconds your code runs. If you get zero traffic, you pay zero dollars.”

It sounded like the ultimate operational model. Developers bought in en masse. We built applications made of dozens of small, isolated cloud functions tied together by message queues and event buses.

But the invoice has arrived. And it is eye-watering.

Far from simplifying operations and reducing costs, serverless has introduced massive system complexity, vendor lock-in, weird architecture workarounds, and cloud bills that are 5x to 10x higher than running the same workload on standard virtual machines.

Serverless isn’t an architectural revolution; it’s a high-margin pricing grift designed by cloud providers to lock you into their ecosystem.

The Cost Trap: The Idle Myth

The core assumption of serverless cost-saving is that your application is mostly idle.

And yes, if you are running a cron job that runs once a day for 5 seconds, or a hobby project that gets 100 hits a month, serverless is incredibly cheap.

But if you are running a real business with consistent, predictable traffic, serverless is the most expensive way to compute.

Let’s do some math comparing AWS Lambda to a standard AWS EC2 instance or a VPS (Virtual Private Server).

Suppose your application runs a web API that processes 100 requests per second. Each request takes 100ms to process and requires 1GB of RAM.

1. AWS Lambda Cost:

   • 100 requests/sec = 8.64 million requests per day = 259.2 million requests per month.
   • Total compute time: 25.92 million seconds.
   • For a 1GB Lambda, AWS charges $0.0000166667 per GB-second.
   • Compute cost: $432/month.
   • Request cost ($0.20 per million): $51.84.
   • Total Lambda Cost: ~$484/month (just for compute).

2. VPS Cost (Hetzner / DigitalOcean):

   • To handle 100 concurrent requests with 100ms response time, a standard 8-core CPU with 16GB of RAM is more than enough.
   • A dedicated 8-core, 16GB RAM cloud server on Hetzner costs about $35/month.
   • Total VPS Cost: $35/month.

By choosing Lambda, you are paying a 1,300% markup for CPU and memory. Cloud providers love serverless because it allows them to sell the exact same hardware at astronomical margins.

The Cold Start and Latency Tax

Computers need time to start. When you call a serverless function that hasn’t been run recently, the cloud provider has to:

1. Spin up a new microVM.
2. Download your code/container.
3. Start your runtime (Node.js, Python, Java).
4. Initialize database connections.
5. Finally, process the request.

This is a Cold Start.

Depending on your runtime and bundle size, a cold start can add anywhere from 200ms to 5 seconds to your request latency. For a web application, a 2-second delay means lost conversions and frustrated users.

To combat cold starts, we write “warmer” scripts that ping our Lambdas every 5 minutes to keep them awake.

Or, we pay for AWS Provisioned Concurrency. This feature tells AWS to keep a set number of execution environments warm and ready.

But wait. If you are paying AWS a flat monthly rate to keep a server environment warm and running 24/7…

You just rented a server.

Except it’s a server that is more expensive, has restrictive timeouts, and is harder to debug than a standard VM. The circle of serverless irony is complete.

graph TD
    A[Adopt Serverless to Avoid Servers] --> B[Experience Cold Start Latency]
    B --> C[Implement Keep-Warm Scripts]
    C --> D[Still Have Latency Spikes under Load]
    D --> E[Pay for Provisioned Concurrency]
    E --> F[Pay a Flat Monthly Rate for Warm Instances]
    F --> G[Realize You Just Rented an Expensive Server with Extra Steps]

The Database Connection Bottleneck

Relational databases like PostgreSQL and MySQL are designed for a persistent pool of connections. A web server boots, opens 20 connections, and reuses them for every incoming request.

In a serverless architecture, your functions scale up instantly. If you get a spike of 1,000 concurrent requests, AWS spins up 1,000 independent Lambda instances.

Each instance try to open its own connection to your database.

Your database limits are instantly exceeded, and the database crashes under the connection overhead.

To fix this, you have to buy AWS RDS Proxy, which sits between your Lambdas and your database to pool connections.

RDS Proxy costs $0.015 per vCPU-hour. For a small database, this adds another $50-$100/month to your bill.

We are constantly adding layers of complex cloud infrastructure (Proxies, API Gateways, EventBridge) to solve networking and database problems that don’t exist in a standard monolithic server model.

Vendor Lock-In

In a serverless app, your code is rarely pure logic. It is tightly coupled to the cloud provider’s proprietary APIs.

You use AWS Lambda triggers, DynamoDB streams, S3 events, and Cognito auth. Your code is littered with AWS SDK calls.

If you ever want to move your application to Google Cloud, Azure, or a private server to save money, you can’t just copy the files. You have to rewrite your entire storage, queue, authentication, and execution layer.

You are locked into their ecosystem, and the cloud provider is free to raise prices, deprecate runtimes, or change API structures because they know you cannot leave.

Keep it Simple: Run a Monolith on a VM

Serverless is a specialized tool. It is excellent for:

• Event-driven, asynchronous background tasks (like image processing, resizing uploads, or transcoding).
• High-volume, short-lived cron jobs.
• Webhook endpoints that get erratic, unpredictable traffic.

For your core web application, do not go serverless.

Deploy a standard compiled or interpreted monolith to a virtual private server or a container runner (like AWS ECS or GCP Cloud Run, which scale container instances but keep them warm). You will get predictable performance, simple debugging, standard database pooling, and a cloud bill that doesn’t require a venture capital round to pay.