Scale-to-zero: a one-line break-even

Below what duty cycle does elastic capacity win, and why is cold start a billing problem?

Let d be the duty cycle: the fraction of time you are active. Let k be the premium the elastic rate carries over the provisioned rate. Going elastic wins when

d × k < 1, that is, when d < 1 ÷ k.

That is the whole decision. It explains why the same architecture is obviously right for a development environment and obviously wrong for a platform with continuous traffic.

Cold start is a billing problem, not only a latency problem

Warm-up time is metered and produces no useful work. A 30-second start on a 5-second job is not a 30-second delay. The job is billed for (30 + 5) ÷ 5 = 7× the useful time, on top of any minimum increment.

Cold start is also not one quantity. It has five parts, with different sizes and different owners.

Only the first two are the vendor's problem. The last one is the dangerous one. A system whose steady-state speed depends on warm caches has a cold-start cost measured in minutes of degraded operation. This is hysteresis (the state of the past affects the present): the system does not return to normal speed the moment the machine is back. When it fails badly, it looks like a "cold-cache collapse": the backend sees all the traffic the cache used to absorb.

A correction to the standard claim

"You pay nothing when idle" is false wherever state exists. Storage keeps billing, and reactivation keeps billing. The genuinely worst case is neither continuous traffic nor zero traffic. It is sparse traffic: one request every few minutes. Then the system is always cold and never idle. If the idle timeout is shorter than the gap between requests, you pay a warm-up on nearly every request. If it is longer, the system never suspends and you pay for always-on capacity. Either way, scale-to-zero gave you nothing. This is exactly Tomás's development warehouse.