Cloud Run and GKE run the same containers but bill on opposite principles, and that is the whole cost decision. Cloud Run charges for CPU and memory only while a request is being served and scales to zero when idle, so you pay near nothing for a service that is quiet. GKE charges for the nodes in the cluster whenever they run, busy or not, so idle capacity is pure cost but dense, steady packing is cheap per workload. The result is a clean rule: low duty cycle, spiky, and bursty services are cheaper on Cloud Run, while dense, steady, always on fleets are cheaper on a well packed GKE cluster covered by committed use discounts and Spot. The mistake is forcing every container onto one platform.
Pick the platform by the shape of the load, not by team preference. Here is how each one bills and where the crossover sits.
How does each platform bill?
Cloud Run bills the allocated CPU and memory for the duration of each request, plus a small per request charge, and when no requests arrive it scales to zero and bills nothing for compute. That makes its cost track traffic directly: a service used a few hours a day costs a fraction of one used constantly. GKE bills for the node virtual machines in the cluster for as long as they run, independent of how busy the pods on them are, so its cost tracks provisioned capacity, not traffic. An underused GKE node is paying for air; a fully packed one spreads its fixed cost across many workloads. The two billing models reward opposite usage patterns.
Where is the crossover point?
The crossover is duty cycle and density. A single low traffic service that would keep a GKE node only a fraction busy is far cheaper on Cloud Run, because Cloud Run charges nothing for the idle time the node would still bill. As you add more steady services that can share nodes, GKE utilization rises and its per workload cost falls, until a densely packed cluster of always on services beats per request billing, especially once committed use discounts and Spot cut the node rate. The table summarizes which side common workload shapes fall on.
| Workload shape | Cheaper platform | Why |
|---|---|---|
| Spiky or low traffic web service or API | Cloud Run | Scales to zero, bills only while serving |
| Event driven and bursty jobs | Cloud Run | No idle node cost between bursts |
| Many dense, steady, always on services | GKE | Fixed node cost spread across busy pods, plus CUDs |
| Specialized hardware or custom networking | GKE | Node level control Cloud Run does not expose |
| Fault tolerant batch at scale | GKE on Spot | Deep Spot discount on interruptible nodes |
Many estates are cheapest with both: Cloud Run for the long tail of spiky services and a packed GKE cluster for the steady core. Splitting by shape, not standardizing on one, is the lower bill.
How do you cut cost on each one?
On Cloud Run, the biggest lever is concurrency: letting each instance serve many requests at once means fewer instances for the same traffic, so raise it as high as the service tolerates. Then tune minimum instances down so you are not paying for warm idle capacity, and right size the CPU and memory allocation to what the service actually uses. On GKE, the levers are the familiar Kubernetes ones: right size pod requests so the scheduler packs nodes tightly, enable cluster and node autoscaling to remove idle nodes, run fault tolerant work on Spot, and cover the steady node baseline with committed use discounts. Both platforms reward removing capacity that is reserved but not used.
A worked platform split
A European SaaS company ran everything on one GKE cluster, including dozens of low traffic internal services that kept nodes mostly idle overnight and at weekends. We moved the spiky and low duty cycle services to Cloud Run with high concurrency so they scaled to zero off hours, kept the dense always on core on GKE, right sized its pod requests, and covered the steady nodes with committed use discounts plus Spot for batch. Container compute cost fell sharply, driven mostly by no longer paying for idle nodes that served quiet services, and the figures are verified against billing data and anonymized.
Look at your GKE node utilization overnight. If nodes stay running to serve services that are quiet for most of the day, those services belong on Cloud Run, and the idle node hours are the saving.
Where this fits in the GCP estate
The GKE side of this decision connects to the broader container cost discipline. Cover steady nodes using the approach in Spot VMs and preemptible economics on GCP and split shared cluster cost with GCP cost allocation for GKE workloads. The cross cloud container view lives in the Kubernetes cost guide, and the full GCP picture in the GCP cost optimization guide.
Frequently asked questions
Is Cloud Run cheaper than GKE?
When does GKE beat Cloud Run on cost?
How do you cut cost on whichever you choose?
Get the buyer side container cost playbook
We place each workload on the cheaper of Cloud Run and GKE by its real duty cycle, then tune both so you stop paying for idle capacity. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.