Scale-to-zero shifts cloud billing from paying for existence to paying for execution. Learn how this model eliminates idle compute costs and when you should—or shouldn't—use it for your infrastructure.
The Hidden Cost of Always-On Compute
In the traditional cloud billing model a virtual machine (VM) is charged for every wall‑clock hour it exists, independent of the amount of traffic it processes. The metric used is “vCPU‑hours” and “GB‑hours”, which are summed over the month. Because a month of 31 days contains 730 hours, a VM that never sleeps accrues 730 metered hours regardless of whether it serves a million requests or none.
At the published rates of $0.036 per vCPU‑hour and $0.004 per GB‑hour, the cost of simply keeping a VM alive can be calculated as follows:
- vCPU cost: 730 h × $0.036 ≈ $26.28
- Memory cost (1 GB): 730 h × $0.004 ≈ $2.92
- Total idle cost for a 1 vCPU/1 GB instance ≈ $29 per month
Scaling the same calculation to larger instance sizes yields the baseline “existence” costs shown below:
- 2 vCPU, 2 GB ≈ $58/month
- 4 vCPU, 8 GB ≈ $141/month
These figures represent the price paid before any application code runs. In practice, many workloads spend a large fraction of the month idle. An internal audit of a 16‑day period revealed that 84 % of the billed credits (1,096 of 1,305) came from vCPU‑hours on a VM that never entered a sleep state, even though the VM performed less than one vCPU of useful work on average.
For enterprise engineers, the hidden cost can be identified by comparing two metrics:
- Billed compute hours – the total vCPU‑hours reported on the invoice.
- Request volume or active seconds – the time the application actually handled traffic.
If the billed compute hours substantially exceed the active seconds, the surplus represents idle capacity that is being rented without delivering value. Recognizing this pattern is the first step toward cost‑optimization, whether by right‑sizing instances, implementing auto‑scaling, or adopting a scale‑to‑zero platform that pauses the VM when no requests are present.
Defining Scale-to-Zero
Scale‑to‑zero changes the traditional cloud billing model by decoupling cost from wall‑clock time. In a conventional always‑on deployment, a virtual machine (VM) accrues charges for every hour it exists, regardless of whether it processes any requests. The compute meter therefore records a non‑zero value even during idle periods. With scale‑to‑zero, the platform pauses the instance as soon as the request stream ends; the compute meter is set to exactly zero until a new request arrives, at which point the instance is “woken” and begins billing again.
During the paused state only storage‑related charges remain. For example, at a published rate of $0.036 per vCPU‑hour and $0.004 per GB‑hour of memory, a 1 vCPU/1 GB VM that never sleeps costs roughly $29 per month purely for existence. If the same workload is configured to scale‑to‑zero, those $29 disappear when the service is idle, and billing resumes only for the actual compute bursts needed to serve traffic.
Practical implementation patterns include:
- Functions: Each invocation is billed separately; the runtime is automatically parked between calls.
- Run services: Autoscaling with a minimum instance count of zero allows the service to park after an idle timeout.
- Managed databases (e.g., ScalixNova Postgres): The database suspends to zero when no queries are received, incurring only storage costs and brief compute for the first query.
Wake latency is the primary trade‑off. Production measurements show a median wake‑up time of about 200 ms for a TCP connection and roughly 600 ms for a full TLS request. For most APIs, dashboards, and internal tools this delay is negligible, but workloads that require sub‑10 ms tail latency should retain an always‑on instance or increase the minimum instance count.
Guidelines for deciding whether to use scale‑to‑zero:
- Traffic is intermittent or exhibits long idle periods.
- The workload is stateless or can tolerate a brief warm‑up period.
- Cost analysis shows a high proportion of billed compute hours without corresponding request volume.
- Persistent connections (WebSockets, long‑running DB sessions) are not required.
To enable scale‑to‑zero, an engineer typically:
- Configure the service’s autoscaling policy with
min‑instance‑count = 0. - Set an appropriate idle timeout based on acceptable wake latency.
- Validate that stateful components are externalized (e.g., using external caches or databases) so that pausing does not lose critical data.
Where Scale-to-Zero Applies
Scale‑to‑zero changes the billing model from “pay for the machine’s existence” to “pay only while code is executing”. When traffic stops, the platform pauses the compute instance; the meter stops, and no compute charges accrue. The next request triggers a wake‑up, the instance processes the request, and then returns to a paused state after the idle timeout. This model eliminates idle‑hour costs that dominate traditional always‑on VMs.
Functions – per‑invocation billing
Functions are executed on demand and are billed for each invocation. Between calls the runtime is completely stopped, so no vCPU‑hour or memory charges are generated.
Practical example: A webhook handler that receives an average of 10 events per hour can be deployed as a function. Each event incurs a single invocation charge; the underlying compute is parked the remaining 99.99 % of the time, resulting in zero compute cost during idle periods.
Run services – autoscaling with min‑instance‑count=0
Run services use an autoscaler that can reduce the replica count to zero when no traffic is observed. Setting min‑instance‑count to zero allows the service to park completely, then wake on the next request.
- Typical wake latency: ~200 ms to establish a TCP connection, ~600 ms for a full TLS request (median values from production benchmarks).
- Suitable for APIs, dashboards, or internal tools where sub‑10 ms latency is not a strict SLO.
Practical example: An internal reporting API that receives bursts of traffic during business hours can run with min‑instance‑count=0. Outside peak hours the service parks, eliminating compute charges while still meeting latency requirements when it wakes.
ScalixNova shared Postgres – suspend‑to‑zero
The shared Postgres offering suspends the database instance when no queries are received. While suspended, only storage costs accrue; a brief compute burst occurs to serve the first query after suspension.
- Suspension eliminates idle compute billing for low‑traffic workloads.
- Wake‑up latency is comparable to the function and Run service wake times, making it appropriate for batch jobs or infrequently accessed data stores.
Practical example: A microservice that queries a configuration table a few times per day can rely on the shared Postgres suspension. The service pays only for the storage of the few megabytes of data and the compute needed to answer each occasional query.
When deciding whether to keep an instance always on, compare the total billed compute hours to request volume. If a significant portion of billed hours occurs without corresponding traffic, configuring the workload for scale‑to‑zero will reduce cost without compromising functionality, provided the measured wake latency fits within the service’s SLO.
The Latency Trade-off
Cold starts occur when a scale‑to‑zero instance must be re‑initialized after an idle period. The platform must allocate CPU, load the runtime, and establish network bindings before it can accept traffic. This “wake latency” is measurable and directly impacts request‑level Service Level Objectives (SLOs).
Production benchmarks from the platform show two median latency points:
- ≈ 200 ms to wake a parked service for a plain TCP connection.
- ≈ 600 ms to complete a full TLS‑terminated request through the edge.
These numbers are useful when classifying workloads:
- Interactive APIs – latency budgets of 100 ms to 300 ms will feel the 200 ms TCP wake as a noticeable delay on the first request after idle.
- Dashboard or admin UI – a 600 ms TLS wake is often acceptable because users expect occasional loading pauses.
- Sub‑millisecond, high‑frequency paths (e.g., real‑time trading, low‑latency micro‑services) cannot tolerate any warm‑up cost; an always‑on instance or a higher minimum replica count is required.
Practical example: a micro‑service that processes webhook events at an average rate of one request per minute. If the service is configured with a minimum instance count of zero, each minute‑gap triggers a cold start. The observed 200 ms TCP wake adds ~12 seconds of cumulative latency per hour, which may breach a 99th‑percentile latency SLO of 250 ms. Setting the minimum count to one eliminates the wake latency at the expense of idle compute cost.
When deciding whether to keep an instance always on, consider:
- Steady traffic patterns (e.g., > 80 % of the hour contains requests).
- Stateful protocols such as WebSockets that require persistent connections.
- Latency‑sensitive SLAs where a few hundred milliseconds of additional latency is unacceptable.
In environments where cost is a primary driver and occasional latency spikes are tolerable, scale‑to‑zero remains advantageous. Engineers should instrument request latency, isolate the cold‑start component, and use the benchmarked medians (200 ms TCP, 600 ms TLS) as baselines for capacity planning and SLO verification.
When to Choose Always-On vs. Scale-to-Zero
Scale‑to‑zero changes the billing model from “pay for the machine’s existence” to “pay only while code is executing”. When traffic ceases, the platform pauses the instance; the compute meter drops to 0 credits. A subsequent request triggers a wake‑up, the instance processes the request, then returns to a paused state after the idle timeout. The trade‑off is a wake latency of roughly 200 ms for a raw TCP connection and about 600 ms for a TLS‑terminated request, as measured in production benchmarks.
Always‑on billing, by contrast, accrues cost for every wall‑clock hour regardless of activity. At the published rates of $0.036 per vCPU‑hour and $0.004 per GB‑hour, a 1 vCPU / 1 GB instance costs about $29 per month even if it processes zero requests. In a 16‑day observation, 84 % of a customer’s compute credits were spent on idle vCPU‑hours.
Decision framework
Use the following checklist to decide between always‑on and scale‑to‑zero:
- Traffic pattern: If request volume is steady across the day, the fixed hourly cost of always‑on may be justified. If traffic is bursty with long idle periods, scale‑to‑zero eliminates the idle‑hour expense.
- Connection type: Persistent connections (WebSockets, long‑running database sessions, gRPC streams) require the process to stay alive; scale‑to‑zero would break the connection each time the instance parks.
- Latency sensitivity: Workloads that must meet sub‑10 ms p99 response times cannot tolerate the 200‑600 ms wake latency. Such workloads should remain warm with an always‑on instance or a minimum instance count > 0.
- Statefulness: Applications that keep in‑memory caches, session state, or open file handles benefit from always‑on to avoid re‑initialization overhead.
Practical examples
- Real‑time collaboration tool: Uses WebSockets for live editing; requires always‑on to keep sockets open.
- Internal analytics dashboard: Accessed a few times per hour by engineers; scale‑to‑zero reduces cost while the 600 ms cold start is acceptable.
- High‑frequency trading API: Sub‑millisecond latency SLA; must stay always‑on.
- Batch data‑processing microservice: Triggered by a nightly job; scale‑to‑zero eliminates idle cost.
To evaluate your current spend, compare billed compute hours to request volume. Hours without requests represent cost that scale‑to‑zero can remove. When the workload meets any of the “always‑on” criteria above, retain a minimum instance count greater than zero; otherwise configure the service (functions, run services, or serverless Postgres) with a zero minimum to benefit from the pay‑while‑serving model.
Looking for Custom Software or AI Solutions?
Appworks Technologies designs, builds, and scales production enterprise platforms, microservices, and AI agent workflows tailored to your business goals.
Editorial Policy & Research Methodology
Our findings are based on rigorous internal research, verified industry benchmarks, and direct technical implementation experience from our enterprise client projects. All statistics and technical claims are reviewed by senior engineers before publication to ensure accuracy, transparency, and helpfulness for our readers.