Serverless Isn't Always Cheaper

Lambda and SQS are great for bursty workloads, but sustained, high-throughput traffic — like a game server under continuous load — is often cheaper and more predictable on right-sized EC2 with load balancing. Know your traffic shape before you pick your infrastructure, because the “serverless is always cheaper” pitch only holds for a specific usage pattern.

Why the pitch is true for bursty workloads

Serverless billing is per-invocation and per-millisecond of execution. For a workload that’s idle most of the time and spikes unpredictably — a webhook handler, a nightly batch job, a Slack bot, an image-processing pipeline triggered by uploads — that model is genuinely excellent:

• You pay nothing while idle. No servers sitting warm waiting for traffic that might not come.
• Scaling is automatic and near-instant. A traffic spike from 10 to 10,000 requests doesn’t require any capacity planning.
• Operational overhead drops. No patching, no instance health checks, no autoscaling group tuning.

For that shape of traffic, the economics and the operational simplicity both favor Lambda, and it’s not close.

Where the math flips

The failure mode is applying that same reasoning to sustained, high-throughput traffic — a workload that’s busy most of the time, not idle most of the time. A game server handling continuous player connections is close to the worst case for Lambda’s pricing model:

• You’re paying the per-millisecond rate for nearly 100% utilization, which is exactly the scenario where a flat hourly EC2 rate wins — you’re comparing metered pricing against a workload that never stops metering.
• Cold starts become a recurring tax, not a rare event. On bursty traffic, a cold start is an occasional cost. On sustained traffic that’s constantly scaling instances up and down at the margins, you’re paying that latency penalty far more often.
• Connection-oriented protocols fight the model. Lambda is built around short-lived, stateless invocations. A game server needs long-lived, stateful connections — you end up bolting on complexity (API Gateway WebSocket routes, external state stores) to make a fundamentally connection-oriented workload fit a request/response execution model.
• SQS adds queueing latency you don’t need for real-time traffic. Queues are the right tool for decoupling and absorbing bursts — they’re the wrong tool when the requirement is low, predictable latency on every request.

What right-sizing actually looked like

Moving that workload to EC2 wasn’t “throw it on a bigger box and hope” — it was a deliberate, measured process:

1. Load-tested to find the actual resource ceiling per instance (CPU and memory at target concurrent-connection counts), rather than guessing at an instance size.
2. Put it behind an Application Load Balancer with health checks, so unhealthy instances got cycled out automatically instead of silently degrading.
3. Set up an Auto Scaling Group with target-tracking on the metric that actually mattered (concurrent connections, not CPU alone — CPU headroom doesn’t tell you when you’re about to run out of connection capacity).
4. Used a mix of On-Demand and Reserved/Savings Plan pricing for the baseline sustained load, keeping On-Demand only for the scaling margin — since the baseline load was predictable, most of the capacity didn’t need to be paid at full on-demand rates.

The result was lower cost than the Lambda equivalent at the same throughput, and more predictable latency, because there was no cold-start variance and no queueing delay in the request path.

The actual decision framework

Before picking infrastructure, plot your traffic against two axes: how idle is it, and how latency-sensitive is it?

• Idle most of the time, latency-tolerant → serverless is close to a free win. Lambda, SQS, EventBridge.
• Sustained high throughput, latency-sensitive → right-sized, load-balanced compute (EC2, ECS, or similar) usually wins on both cost and predictability.
• Somewhere in between → model both costs explicitly before deciding. AWS’s own pricing calculators make this a spreadsheet exercise, not a guess, and it’s worth doing before committing to an architecture that’s expensive to unwind later.

“Serverless is cheaper” is a claim about a traffic shape, not a universal law. Match the infrastructure to the actual shape of your traffic, and the cost conversation mostly resolves itself.