Serverless Explained: What It Is and When It Costs More

Serverless is a way of paying for compute. That is the whole thing. You hand a cloud provider a zip file or a container image, tell it how much memory the code needs, and it runs that code inside a managed execution environment it creates, freezes, thaws and eventually throws away without telling you.^[3] There is no machine you log into, no kernel you patch, and no capacity you reserve. When nothing calls your code, you owe nothing. When something does, AWS meters it in milliseconds.

The word makes it sound like an architecture. It isn't. It's a billing model with a runtime attached, and the second you treat it as a billing question the whole decision gets easy. AWS Lambda charges $0.20 per million requests and $0.0000166667 per GB-second of x86 compute in US East (N. Virginia).^[1] Those two numbers, plus your traffic shape, tell you everything.

So let's actually do the arithmetic, because almost nobody does. I went looking for the point where a function stops being the cheap option and starts being the expensive one, and the answer surprised me: it isn't about scale at all.

What you actually hand over

Four things change when code moves into a function. The provider owns the operating system and the runtime patching. The environment scales to zero, so an endpoint nobody hits costs nothing. Billing is per invocation and per unit of duration rather than per hour of a rented box. And you lose the machine as a place to keep state, because AWS freezes the environment after each invocation and terminates it every few hours anyway, even for functions that are invoked continuously.^[3]

That last one is the part people underrate. Your process is not long-lived, so anything you were relying on a long-lived process for stops working the way you expect. In-memory session state. A warm connection pool. A background worker that finishes after the response goes out. All of it becomes somebody else's problem, and the somebody is you.

The cost crossover, worked out

Take a boring API endpoint. It reads a row, does a little work, returns JSON. Call it 512 MB of memory and 120 ms of billed duration, which is a realistic shape for a warm handler doing one database round trip. Now price it both ways.

# AWS Lambda, x86, first duration tier
REQUEST_PRICE = 0.20 / 1_000_000      # $ per request
GB_SECOND     = 0.0000166667          # $ per GB-second

memory_gb, duration_s = 0.5, 0.120
per_request = memory_gb * duration_s * GB_SECOND + REQUEST_PRICE
# -> $0.0000012 per request

# AWS Fargate, Linux/x86, always on
VCPU_SECOND = 0.000011244             # $ per vCPU-second
MEM_SECOND  = 0.000001235             # $ per GB-second

vcpu, mem_gb = 0.25, 0.5
seconds_per_month = 730 * 3600        # 2,628,000
monthly = (vcpu * VCPU_SECOND + mem_gb * MEM_SECOND) * seconds_per_month
# -> $9.01 per month, whether anyone calls it or not

crossover = monthly / per_request
# -> 7,508,000 requests per month, about 2.9 per second

Seven and a half million requests a month, or 7.5 million if you prefer it as a number you can search for. That is the line. Under it, the function is cheaper, and at low volume it is dramatically cheaper: two million requests costs $2.40 against $9.01 for the container, and the first million requests plus 400,000 GB-seconds are free anyway.^[1] Over the line, the function loses, and it keeps losing faster the more traffic you send, because its bill is a straight line through the origin and the container's is flat.

Duty cycle is the variable, not scale

Here's the part I find genuinely interesting. Look at what the container is doing at the moment the two lines cross.

At 1,769 MB a Lambda function gets the equivalent of one vCPU.^[2] So a 512 MB function is running on roughly 0.29 of a vCPU, and 120 ms of it consumes about 0.035 vCPU-seconds of work. A 0.25 vCPU Fargate task delivers 0.25 vCPU-seconds every second, so it can absorb about 7.2 of those requests per second before it saturates. The crossover sits at 2.9 requests per second. That is 40% utilization.

Run the same comparison at matched shapes and you get the same answer from the other direction. A 1,769 MB Lambda costs $0.0000288 per second of one-vCPU compute. A 1 vCPU, 2 GB Fargate task costs $0.0000137 per second.^[1,4] Lambda is about 2.1 times the price per unit of CPU time, which means it wins right up until the box you would otherwise rent is busy more than about half the time.

This reframes the whole argument. “Will we outgrow serverless?” is the wrong question, because a service handling a hundred million requests a month in four sharp daily spikes can still be firmly on the cheap side of the line, while a background job that quietly chews CPU at a constant rate is on the expensive side at a fraction of that volume. Spiky and low duty cycle wins. Steady and high duty cycle loses. Scale is almost irrelevant except insofar as it correlates with duty cycle, and in real systems it correlates a lot less than people assume.

The constraints that aren't on the landing page

Cost is the argument people have. These are the things that actually break projects.

Cold starts, and what really causes them. When no warm environment exists, AWS downloads your code, starts an environment and runs your initialization code before the handler executes. AWS says this happens in under 1% of invocations and lasts from under 100 ms to over 1 second.^[3] The important detail is whose fault it is: AWS states plainly that the largest contributor to pre-execution latency is the initialization code you wrote, driven by package size, imported libraries and connection setup.^[3] A fat SDK import in the global scope is a self-inflicted cold start. The Init phase is also capped at 10 seconds for on-demand functions.^[3]

Fifteen minutes, and 6 megabytes. A function times out at 900 seconds, period.^[2] Synchronous requests and responses cap at 6 MB each, asynchronous at 1 MB.^[2] Video transcoding, big report generation and anything that streams a large file need a different execution model or a chunking strategy, and the chunking strategy is real work that a long-running process would never have needed.

The connection pool problem. This is the one that bites hardest. The default quota is 1,000 concurrent executions per region,^[2] and each one is a separate environment that will happily open its own database connection. Your pooling library, which assumes one process serving many requests, now has a pool of one inside each of a thousand processes. AWS recommends Amazon RDS Proxy for exactly this, describing it as a service that “manages a pool of shared database connections which enables your function to reach high concurrency levels without exhausting database connections.”^[5] That proxy is billed hourly, which is quietly funny: the fix for your always-on cost being zero is to add an always-on component. This is also the moment to get serious about caching in front of the database, because a cache hit is a connection you never opened.

Lock-in through the event model, not the runtime. People worry about the wrong lock-in. Your handler is ordinary Python or Node and it ports in an afternoon. What doesn't port is everything around it: the event shapes, the IAM policies, the queue semantics, the retry and dead-letter behavior, the fact that your application's control flow now lives in a cloud console rather than in your code. That is the same coupling problem you get when splitting a monolith into services, except the wiring belongs to a vendor.

The observability tax. You cannot attach a profiler to a process that no longer exists. You get logs, metrics and traces, you pay per gigabyte ingested, and the volume is proportional to invocations rather than to machines. A container on a box you control gives you the same telemetry plus the ability to just go look. Losing that is a real cost, it just never appears in the pricing comparison.

How I'd actually decide

Estimate the duty cycle of the box you would otherwise rent. Peak requests per second, times CPU seconds per request, divided by the vCPUs you would provision. If that number is under about 40%, take the function and don't think about it again. If it's over 60%, run a container. Between the two, pick on operational fit rather than price, because the difference is a rounding error next to one engineer's afternoon.

Then override that on shape. Anything spiky, scheduled, event-driven or embarrassingly parallel is a function even when the arithmetic is close, because elasticity is the product you are buying. Anything with a long tail of duration, a big payload, a chatty database or a warm cache is a container even when the arithmetic looks fine, because you will spend the savings on workarounds. If the isolation model rather than the billing model is what you actually want, that is a containers versus virtual machines question and serverless is not the answer to it. And if the goal is latency rather than cost, the interesting move is usually pushing work outward into edge and distributed execution, not inward into a function in one region.

The honest summary is that serverless is an excellent default and a bad destination. Start there, because at low volume it is free and it removes an entire category of work. Watch your duty cycle. When it crosses 40% and stays there, you have stopped buying elasticity and started renting the same CPU at twice the price with extra rules attached.

Go pull one month of invocation counts and average duration out of CloudWatch and run the two lines. It takes ten minutes and it will either confirm you are fine or hand you the cheapest infrastructure win you will find this quarter.