We default to serverless on most web apps. Not as a religion. As a starting point that pushes the bill and the ops load down until the app earns something heavier.
The default is Lambda plus API Gateway plus DynamoDB. You pay per request, not per idle hour. A side project that gets 40 hits a day costs cents. An internal tool that spikes at 9am and sleeps the rest of the day scales without a single config change. Nobody patches an OS. Nobody sizes a node pool.
That last part matters more than the bill. A 2-person team cannot babysit a Kubernetes cluster and ship features. So we don't run one unless the workload demands it.
What Lambda is actually good at
Lambda fits request-response work that finishes fast. CRUD APIs, webhooks, auth flows, scheduled jobs, image resizing, the glue between two SaaS tools. Work that arrives in bursts and then goes quiet.
It fits new products best of all. When you don't know your traffic shape yet, paying per request beats guessing at instance counts. You learn the real load curve from the bill instead of from a load test you made up.
It also fits spiky internal tools. We built and run a support agent in production. The traffic is uneven by nature - quiet overnight, busy during business hours. Per-request pricing matches that shape. You don't pay for the quiet hours.
Where Lambda starts to hurt
Cold starts are the first complaint, and the most overstated one. For a typical API on a warm runtime, the penalty is small and the function stays warm under steady traffic. If a few hundred milliseconds on a rare cold path breaks your UX, that's a signal, not a disaster.
The real limits are sharper. A Lambda runs 15 minutes, max. A video transcode or a long ETL job will blow past that. The deployment package has size limits. A heavy ML model with fat native dependencies fights the bundle every time.
Per-request pricing also flips on you at scale. Cheap traffic is cheap. Sustained high-volume traffic, the kind that would keep a container busy 24/7, gets expensive on Lambda. At that point you are paying a premium to not manage servers, and the premium stops being worth it.
WebSockets and long-lived connections are awkward too. You can do them. You will not enjoy the plumbing.
When we reach for containers
We move to containers, usually Fargate, when the workload outgrows the function model. The signals are concrete, not vibes.
Move when jobs run longer than 15 minutes. Move when traffic is high and steady enough that always-on compute is cheaper than per-request. Move when you need a persistent process, a custom runtime, a big dependency tree, or fine control over memory and CPU. Move when an existing app already ships as a container and rewriting it as functions buys nothing.
Fargate keeps you off server management while giving you the long-running process Lambda won't. You still don't patch hosts. You define a task, set CPU and memory, and AWS runs it. It is the honest middle between Lambda and a cluster you operate yourself.
The pattern we ship most
Most real apps are not one or the other. They are mostly Lambda with a container or two for the heavy parts.
The API, the auth, the webhooks, the cron jobs - all Lambda. The one job that transcodes video or runs a 20-minute report - a Fargate task. You get serverless economics on the 90% that suits it and a container only where the function model breaks.
That hybrid is the design, not a compromise. Picking the right compute per workload is the work. Defaulting everything to containers because "serverless is hard" leaves money on the table. Defaulting everything to Lambda because "serverless is the future" eventually fights you on the long jobs.
How we decide
We size this in the first conversation, before any code. Most AWS bills hide savings nobody is tracking, and a chunk of that waste is the wrong compute choice for the workload. Right-sizing serverless versus containers up front is cheaper than fixing it after launch.
Our Web App builds are fixed-price and ship in 3 to 5+ months, on a date you have before we start. We pick the compute model that fits your traffic and your budget, write it down, and you own the code when we exit. No surprise re-architecture invoice six months in.
If you are deciding between Lambda and containers for something real, we can sketch the right split in 30 minutes. Book a free call and bring your traffic shape.