Serverless vs. Containers: When to Use Each

“Should this run on Lambda or in a container” comes up in nearly every backend architecture conversation, and it’s often treated as a matter of team preference or whatever’s trendier this year. It shouldn’t be. The two models have genuinely different cost and performance characteristics, and the right choice follows directly from a workload’s traffic pattern and execution profile — not from which one a given engineering team happens to be more comfortable with.

The Core Difference That Actually Matters

A container runs continuously, whether it’s handling a request or not — which means you’re paying for it around the clock regardless of actual traffic. Serverless (Lambda specifically) scales to exactly zero when idle and costs nothing during that time, then scales up automatically — genuinely automatically, with no capacity planning required — when traffic arrives, up to very high concurrency.

For a workload with highly variable traffic — busy during business hours, near-idle overnight — that difference compounds into real money. For a workload with steady, predictable, always-on traffic, it matters much less, and containers’ other advantages start to dominate the decision instead.

Where Serverless Genuinely Wins

Lambda is a strong fit for REST and GraphQL APIs with variable or spiky traffic, event-driven processing triggered by S3 uploads, SQS messages, or DynamoDB streams, scheduled jobs, webhooks, and document or image processing pipelines. The economics are most compelling specifically when idle time is significant — paying nothing while nothing is happening is Lambda’s structural advantage, and it’s largest exactly where traffic is least predictable.

An IoT platform processing events from 2 million devices illustrates this well: traffic was highly variable, near-zero overnight with spikes of 50,000 requests a minute during business hours, and the previous container-based (ECS) infrastructure cost $8,200 a month regardless of how much of that capacity was actually being used at any given moment. Migrating to Lambda, API Gateway, and SQS — scaling automatically from zero to 10,000 concurrent executions with no idle compute cost — brought that same workload down to $1,100 a month, an 87% reduction, while also eliminating the capacity planning the previous architecture required and handling traffic spikes automatically with no manual intervention.

Where Serverless Structurally Doesn’t Fit

Lambda has real constraints that aren’t tuning problems — they’re architectural boundaries. A 15-minute maximum execution time rules out genuinely long-running processes outright. Applications needing persistent connections don’t map cleanly onto Lambda’s invocation model. And cold starts — the latency incurred when a function spins up from zero — can be mitigated substantially but not eliminated entirely, which matters for workloads where that latency is simply unacceptable regardless of how rare it is.

Database connectivity is a related, specific gotcha: Lambda functions don’t hold persistent connections the way a long-running server process does, so at high concurrency, direct connections to a relational database can exhaust its connection pool fast. RDS Proxy exists specifically to solve this — pooling connections between Lambda and the database so Lambda’s concurrency doesn’t translate one-to-one into database connections.

Where Containers Are the Better Fit

Containers handle everything Lambda structurally can’t: long-running processes, workloads needing persistent connections, applications with complex startup requirements or large dependencies that don’t fit Lambda’s package size expectations, and situations where consistent behavior across environments matters more than scale-to-zero economics. Containerisation also solves a completely different, common problem: “works on my machine” failures caused by environment inconsistency between development, staging, and production.

A Laravel e-commerce application deployable only to a specific cPanel hosting environment, with no usable local development setup and deployments taking over four hours of manual steps, is a useful illustration of that different problem. After containerising it — PHP-FPM, Nginx, and Redis running as separate containers, with Docker Compose providing a consistent local development environment and a CI/CD pipeline building and pushing images automatically — new developer onboarding dropped from two days to 45 minutes, and deployment time dropped from four hours to twelve minutes, with zero “works on my machine” incidents in the following six months. None of that was a cost optimisation; it was an environment-consistency and developer-velocity fix, which is a different problem than the one serverless solves.

Making the Actual Decision

The practical filter: if a workload has genuinely variable or spiky traffic, executes in well under 15 minutes per invocation, and doesn’t need persistent connections, serverless architecture is very likely the more cost-efficient choice. If it runs continuously, needs longer execution windows, or the actual problem is environment consistency rather than idle compute cost, containerisation is the better fit. The wrong approach is picking one as a default and forcing every workload into it regardless of which problem is actually being solved.