The Runtime Theory
mediumApplicationDSA#serverless#pricing#cost#infrastructure

Explain the cost difference between serverless and servers

Probes whether you can read billing models as machine behavior — GB-seconds vs. flat capacity pricing, the cold-start tax, and where the crossover point actually lives.

The Runtime Theory Team2 min readasked at vercel · cloudflare · amazon · microsoft

This question is testing whether you can read a billing model as a description of machine behavior, not just quote price lists. A strong answer decomposes both models into what the machine actually does, then shows where the crossover point lives.

The mental model: serverless prices latency; servers price capacity. Lambda's unit is the GB-second: $0.0000166667 per GB-second plus $0.20 per million requests, billed per millisecond. One 512 MB function at 200 ms costs about $0.0000019 per invocation — 10 million invocations is roughly $19. The multiplier is memory, which sets your CPU share: doubling memory typically halves duration while doubling the rate, so the cheapest function is the one that uses just enough memory to finish fastest, found by sweeping memory and computing cost per call. A server, by contrast, is a flat hourly rental — an instance bills the same whether it processes 100 requests or 10 million. The difference is that serverless makes every millisecond a line item, including ones you don't control: request transport, runtime dispatch, response serialization, logging — all inside your billed duration but outside your code. For chatty workloads, a webhook fanout that calls 20 downstream functions pays 20 request fees and 20 durations per event.

The cold-start tax is the real divergence. A cold call bills at full rate. The 2.3 seconds a JVM function spends booting a microVM and initializing the SDK costs ~15x a 150 ms warm call — 1M cold calls a month is ~$23 against ~$1.50 warm. That is not a latency problem with a pricing footnote; it is the pricing model amplifying the latency problem. Timeouts and retries compound it: a function configured for 30 s that normally finishes in 300 ms bills 20 s when a dependency stalls — the timeout is a budget, set it to p99 plus margin — and event-source retries re-invoke the same function with the same payload, so a failing function is a compounding bill, not a flat one.

Where the crossover lives. Serverless wins on bursty, idle, spiky workloads: you pay for what you run, and scale-out is free until concurrency budgets and cold starts hit. A server wins on steady, latency-critical, or stateful workloads: you pay for boot once, not per request. If the aggregate monthly bill is dominated by cold starts and platform overhead rather than handlers, the invoice is telling you the workload doesn't fit the model — move it to a warm container.

Edge cases. Provisioned concurrency pre-pays for warmth at roughly $0.000004-0.000008 per GB-hour and only pays off when the kept-warm instances serve real traffic — otherwise you pay for idle heat. Vercel and Cloudflare Workers bill on different granularity — requests plus duration — but the structure, latency as a line item, is the same. And remember the abstraction: serverless is still a server — someone is paying rent on the machine in latency or dollars either way.

This answer walks

Follow-ups they'll push on

  1. 01What does the memory multiplier do to the cheapest-function math?
  2. 02How do timeouts and retries amplify the bill?
  3. 03When does provisioned concurrency pay for itself?

More interviews in this topic

One dispatch a week

The trace behind each question, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.