What is scale to zero?

Scale to zero is the behavior of a cloud service that, once requests stop arriving, shuts down even its last instance (the last running copy of the service) and stops consuming compute, so it stops running up charges. When the next request comes in, the service spins an instance back up, and that first response is slower: this is the cold start, the time needed to prepare the environment before the code can run. In the Cloud Run documentation, Google says removing the last instance is "commonly referred to as scale to zero". Functions do it by design (see the entry on FaaS), but today it is a setting you turn on or off in many kinds of services: containers, databases, AI models on GPUs. The trade-off is always the same: no compute bill during idle hours, in exchange for a wait on the first request after a lull.

See also: FaaS · Functions that run only when an event calls them: no servers to manage, you pay only for what you run.

Not just functions: containers, databases and GPUs

For containers, Cloud Run and Azure Container Apps offer it; in Container Apps the minimum replica count defaults to zero, and Microsoft states that no usage charges apply at zero. On Kubernetes, the open source projects Knative and KEDA add it. Among databases, Aurora Serverless v2 has been able to drop to zero capacity units since November 2024: it pauses when it has no connections and typically resumes in about 15 seconds, while storage is still billed. Neon by default suspends compute after 5 minutes of inactivity and brings it back within a few hundred milliseconds. On the GPUs that run model inference, the timescale changes: by default, Hugging Face Inference Endpoints shuts an endpoint down after an hour with no traffic, but scaling back up can take a few minutes, and its own documentation advises against starting from zero when the application has to be responsive.

What keeps it awake without anyone noticing

Shutdown depends on traffic, not processor load: Cloud Run checks whether an instance is handling a request, Aurora checks for open connections. A connection pool (database connections an application keeps open for reuse) prevents the pause: AWS notes that with RDS Proxy, Aurora instances never pause on their own, and that even a login attempt with the wrong credentials wakes them up. An external uptime check that polls the service every minute sends it, by definition, one request a minute. And setting a minimum instance count above zero disables scale to zero on purpose.

An enterprise example

A manufacturer runs many cloud services: an expense portal, a staging environment for each team, a GPU model classifying supplier documents a few times a day, a development database and a customer portal for orders. Scale to zero on staging and development takes nights and weekends off the invoice, but only once the team has retired the monitor that checked the database every minute and the pool that kept it awake. The classifier goes to zero because nobody is waiting on its results in real time. The customer portal, though, keeps one instance always on: making a customer wait a few seconds costs more than that machine.

Why it matters for decision makers

The price of not paying for idle hours is the wait on the first request: from a few hundred milliseconds to a few minutes, depending on what has to wake up. So who waits? If it is a nightly job or a colleague, zero pays off; if it is a customer or a contractual response-time commitment, keeping one instance always on is a fixed, predictable cost. Then check the invoice, with FinOps discipline, to confirm idle hours really cost nothing: where uptime is what gets billed (databases, GPU endpoints), a service kept awake by a forgotten check costs as much as one that never sleeps. The same load profile also bears on the choice between serverless, on-prem and edge.