Serverless pricing and warm pools

Why can more memory make a function cheaper, and how big must a warm pool be?

Serverless per-invocation pricing

Per-invocation pricing gives one result that is counterintuitive, because the meter is a product and not a sum. You are billed memory × time, with CPU allocated in proportion to memory. If doubling the memory more than halves the runtime, the bill falls.

Worked example (illustrative)

Memory	Runtime	Billed (GB·s)
1 GB	10 s	1 × 10 = 10
2 GB	4 s (CPU-bound code gets 2× CPU)	2 × 4 = 8, cheaper
4 GB	3.5 s (no longer CPU-bound: more CPU did not help)	4 × 3.5 = 14, more expensive

DefinitionServerless cost is memory × time →

GB \times s

Raising the allocation to lower the cost is real, derivable from the coupled meter, and bounded exactly where the workload stops being CPU-bound. At that point the product term reverses, and the same move doubles the cost.

The deeper value of per-invocation pricing is not cheapness. The duty-cycle arithmetic already settled that. It is that cost becomes strictly proportional to traffic. That converts a capacity-planning problem into a unit-economics problem (cost per useful unit), and it removes the failure mode where demand collapses and spend does not. That property is worth a premium, whether or not the rate is competitive.

Warm pools: a guarantee you must pre-pay

A warm pool is a set of pre-started, idle machines kept ready for new work. It follows a general rule: a guarantee that cannot be reclaimed must be paid for in advance, in idle capacity.

Size it with Little's Law, applied to capacity and not to requests. If you must start 10 instances per minute and each takes 2 minutes to become useful, you hold 10 × 2 = 20 warm: in flight = rate × time, sizing a fleet of idle machines.