GCP Cloud Run CPU allocation cost: request-based vs always-allocated

Quick answer

Cloud Run has two CPU allocation modes. In request-based (CPU allocated only during requests) billing, you pay for CPU only while an instance handles a request, at roughly 0.000024 dollars per vCPU-second, plus a per-request fee of about 0.40 dollars per million, which suits bursty request-driven services. In instance-based (CPU always allocated) billing, CPU stays on for the instance's whole lifetime at a lower per-second rate with no per-request fee, which suits services doing background work between requests or with steady traffic. The rule of thumb is request-based is cheaper for spiky request-only workloads, and always-allocated is cheaper for steady traffic or background processing, so match the mode to the traffic shape.

Cloud Run lets you choose how CPU is allocated, and the choice is both a behavior decision and a cost decision. One mode bills CPU only while a request is in flight, the other keeps CPU allocated for the instance's entire life. Picking the wrong mode either pays for idle CPU you do not need or starves background work you do, so it is worth understanding the tradeoff.

The two modes compared

Aspect	Request-based (CPU during requests)	Instance-based (CPU always on)
CPU billed	Only during requests	Whole instance lifetime
vCPU rate	Higher per-second (about 0.000024 dollars)	Lower per-second
Per-request fee	About 0.40 dollars per million	None
Background work between requests	Throttled	Runs at full CPU

In request-based billing, CPU is allocated only while the instance processes a request, and it is throttled to near zero between requests. You pay the higher per-second CPU rate but only for active request time, plus the per-request fee. In instance-based billing, CPU stays fully allocated for the instance's whole lifetime at a lower per-second rate with no per-request charge, so you pay for all the time the instance is alive, whether or not it is handling a request.

Which is cheaper for request-only work

For a service that only does work when a request arrives and sits idle otherwise, request-based billing is usually cheaper, because you pay CPU only during the brief request windows and nothing between them. A low-traffic API that handles a request in 100 milliseconds and then waits pays for those milliseconds, not the idle gaps. This is the classic serverless economics that makes Cloud Run attractive for spiky, event-driven traffic, similar to the Cloud Functions versus Cloud Run comparison.

Which is cheaper for steady or background work

For a service with steady high traffic, or one that needs to do work between requests, such as streaming responses, background processing, or maintaining connections, instance-based billing is usually cheaper and works correctly. Since request-based billing throttles CPU between requests, background tasks stall in that mode, and at high steady request volume the per-request fee and higher CPU rate add up faster than the always-allocated rate. Instance-based also removes the per-request fee, which matters at large request counts.

Choosing the mode

Match the mode to the traffic shape. Choose request-based for spiky, request-only services where instances sit idle much of the time, so you pay only for active request seconds. Choose instance-based for steady traffic, background work, or streaming, where CPU needs to stay on and the lower per-second rate plus no per-request fee wins. Combine the mode choice with minimum instances and right-sized CPU and memory to keep the total honest. Price both modes for your traffic against the resource catalog so the cheaper allocation is chosen before deploy.

FAQ

What are the two Cloud Run CPU allocation modes?

Request-based billing allocates CPU only while an instance handles a request, at roughly 0.000024 dollars per vCPU-second plus a per-request fee of about 0.40 dollars per million, and throttles CPU between requests. Instance-based billing keeps CPU always allocated for the instance's whole lifetime at a lower per-second rate with no per-request fee, so background work runs at full CPU between requests.

Which Cloud Run mode is cheaper?

It depends on traffic shape. Request-based is usually cheaper for spiky, request-only services that sit idle much of the time, since you pay CPU only during brief request windows. Instance-based is usually cheaper for steady high traffic or background processing, since its lower per-second rate and lack of a per-request fee win when CPU needs to stay on most of the time.

When do I need CPU always allocated on Cloud Run?

When your service does work between requests, such as streaming responses, background processing, or maintaining connections. Request-based billing throttles CPU to near zero between requests, so background tasks stall in that mode. Instance-based billing keeps CPU on for the instance's lifetime so that work runs correctly, and it is also cheaper for steady high-traffic services.

Does the per-request fee apply in both modes?

No. The per-request fee of about 0.40 dollars per million applies in request-based billing but not in instance-based billing. At large request volumes, removing that fee is part of why instance-based billing can be cheaper for steady, high-traffic services, on top of its lower per-second CPU rate.

How does C3X help choose a Cloud Run CPU mode?

C3X prices your Cloud Run configuration from Terraform before you deploy, so you can compare request-based and instance-based billing for your expected traffic in the pull request. That lets you match the CPU allocation mode to your traffic shape at design time, choosing the cheaper mode rather than discovering that the wrong billing model inflated the Cloud Run bill.

What to do next

Match the CPU mode to your traffic before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.