Cloud Run CPU and Memory Allocation
Cloud Run charges for the CPU and memory allocated to your container while it is handling requests — or, in instance-based billing, for the whole time an instance exists. Which mode you are in is the single biggest factor in a Cloud Run bill, and minimum instances put you effectively in the second one.
Billed: Per vCPU-second and gibibyte-second, plus a per-request charge. Billing differs sharply between request-based and instance-based modes.
What triggers this charge
- Request-based billing charges only during request handling, and scales to zero when idle.
- Instance-based billing charges for the instance lifetime regardless of traffic.
- Minimum instances keep containers warm — and billed — around the clock, which is a latency purchase, not a scaling one.
- CPU always-allocated, needed for background work, which removes the idle discount.
How to reduce it
Set minimum instances to zero where cold starts are tolerable
Minimum instances is often set during a launch to smooth latency and never revisited. For internal and batch services the cold start rarely matters.
Raise concurrency
Cloud Run defaults to 80 concurrent requests per instance; many services can handle far more. Higher concurrency means fewer instances for the same traffic.
Right-size the container
CPU and memory are allocated per instance and billed per second. A service given 4 vCPU because someone once saw a spike is paying for it on every request.
Rates
Now find out how much of this you are actually paying.
Finitizer breaks your Google Cloud bill down to the SKU, shows how each one has moved since last week, and separates rate changes from usage changes — so you know whether to talk to engineering or to procurement.