Cloud Run vs GKE vs Compute Engine: When to Use Each in Google Cloud

Quick answer

• Cloud Run is the default for stateless HTTP services, event-driven workloads, and scheduled jobs. Start here unless you have a reason not to.
• GKE is the right choice when you need Kubernetes features: StatefulSets, DaemonSets, CRDs, service meshes, or platform-level orchestration across many services.
• Compute Engine is the right choice when you need full VM control: custom OS, persistent local disk, legacy software that cannot be containerised, or network appliance workloads.
• All three connect through the same VPC. Using more than one is normal and expected in production.
• If you are unsure, start with Cloud Run. You can always move a workload to GKE or Compute Engine later.

Simple explanation

Cloud Run runs containers without you managing servers. You give it a container image and Google handles scaling, load balancing, TLS, and the underlying infrastructure. When nobody is calling your service, Cloud Run shuts it down and you pay nothing. When traffic arrives, it starts instances automatically.

GKE (Google Kubernetes Engine) runs containers on a Kubernetes cluster. You get the full Kubernetes API, meaning you control how containers are scheduled, scaled, networked, and stored. Google manages the Kubernetes control plane. You manage the workloads and (in Standard mode) the node VMs.

Compute Engine gives you full virtual machines. You choose the OS, configure the disk, install whatever software you want, and manage the machine directly. There is no container requirement.

Key terms if you are new to this

• Stateless: The service does not store data locally between requests. Any instance can handle any request. Most APIs and web servers are stateless.
• Stateful: The service keeps data in local memory or disk that must persist between requests. Databases, caches, and message brokers are stateful.
• Cluster: A group of machines (nodes) managed together. In GKE, the cluster runs your Kubernetes workloads.
• Node: A single machine (VM) in a cluster. GKE nodes are Compute Engine VMs under the hood.
• Service mesh: A networking layer that controls how services communicate, handling mutual TLS, retries, and traffic routing. Only available natively in Kubernetes environments.

How to choose: decision framework

Work through these questions in order. Stop at the first “yes.”

1. Do you need a full VM or OS-level control? Custom kernel, specific Linux distro, Windows Server, software that cannot run in a container, persistent local SSDs, or a network appliance? Choose Compute Engine.
2. Do you need Kubernetes-specific features? StatefulSets with persistent volumes, DaemonSets, Custom Resource Definitions, Operators, a service mesh (Istio/Anthos Service Mesh), namespace-level RBAC, or Pod Disruption Budgets? Choose GKE.
3. Is the workload stateless and driven by HTTP requests or events? REST APIs, GraphQL endpoints, webhook handlers, Pub/Sub consumers, or Cloud Scheduler jobs? Choose Cloud Run.
4. Is the workload always-on, long-running, or heavily customised? A background worker that does not respond to HTTP, a self-managed database, or a highly tuned application server? Evaluate whether GKE (as a Deployment) or Compute Engine (as a persistent VM) fits better based on whether you need Kubernetes features or raw VM control.
5. Are cost and minimal operations your top priorities? If the workload can be containerised and is not deeply stateful, Cloud Run almost always wins on both.

At-a-glance comparison table

When to use Cloud Run

Best-fit workloads

Cloud Run works best for stateless services that respond to HTTP requests or consume events. It handles scaling, TLS termination, load balancing, and deployment rollouts automatically.

Why it wins

• Zero infrastructure management. No servers, no clusters, no nodes.
• Scales to zero. You pay nothing when nobody is calling your service.
• Deploys in under a minute. One command to ship a new version.
• Built-in traffic splitting for canary and blue/green deployments.
• Connects to VPC resources through Direct VPC egress or Serverless VPC Access connectors.

When not to use it

• Deeply stateful workloads that need persistent local volumes.
• Workloads requiring Kubernetes-specific primitives (DaemonSets, CRDs, Operators).
• Workloads that need a service mesh for inter-service traffic management.
• Applications that require a custom OS, kernel, or non-container runtime.

Practical examples

• A REST API serving variable traffic from a mobile app.
• A webhook receiver that processes Pub/Sub messages and writes to Cloud SQL.
• A scheduled batch job that runs nightly via Cloud Scheduler and Cloud Run Jobs.
• A GPU-backed inference endpoint serving ML model predictions in a supported region.

When to use GKE

Best-fit workloads

GKE is the right choice when you need the Kubernetes API and the platform-level control it provides. This includes multi-service platforms, stateful container workloads, and organisations that have standardised on Kubernetes.

Why it wins

• Full Kubernetes API: Deployments, StatefulSets, DaemonSets, CRDs, Operators.
• Fine-grained networking with network policies, service meshes, and VPC-native clustering.
• Persistent storage via PersistentVolumeClaims for stateful workloads.
• GPU node pools for ML training and inference at scale.
• Autopilot mode reduces node management overhead while keeping the full Kubernetes API.

When not to use it

• Simple stateless HTTP services. Cloud Run handles these with far less overhead.
• Teams without Kubernetes expertise and no plan to build it.
• Low-traffic workloads where the baseline cluster cost is disproportionate.

Practical examples

• A microservices platform with 20+ services, shared service mesh, and namespace-based team isolation.
• A Redis or Kafka deployment using StatefulSets with persistent volumes.
• A GPU-backed ML training pipeline using node pools with NVIDIA GPUs or TPUs.
• An enterprise platform team providing a self-service container platform to application teams.

When to use Compute Engine

Best-fit workloads

Compute Engine is the right choice when you need direct control over the operating system, disk, networking, or hardware. It also serves as the foundation for lift-and-shift migrations where refactoring into containers is impractical.

Why it wins

• Full OS control. Choose any Linux distribution, Windows Server, or custom image.
• Direct access to local SSDs, persistent disks, and custom disk configurations.
• Widest selection of GPU and TPU accelerator types.
• SSH access for troubleshooting, profiling, and direct management.
• Lowest per-unit cost at sustained high scale with committed use discounts and Spot VMs.

When not to use it

• Stateless HTTP services. Cloud Run is simpler, cheaper at variable traffic, and requires no OS patching.
• Container-based platforms that need orchestration. GKE handles scheduling, scaling, and service discovery natively.
• Workloads where scaling speed matters. VM boot times are minutes, not seconds.

Practical examples

• A self-managed PostgreSQL or MySQL database on a high-memory VM with local SSDs.
• A legacy .NET Framework application that cannot be containerised.
• CI/CD build agents that need full OS access and high disk throughput.
• A network appliance (firewall, VPN gateway) that requires custom kernel modules.

Common real-world scenarios

Cloud Run vs GKE

This is the most common comparison because both run containers. The core trade-off is control versus simplicity.

Choose Cloud Run when the workload is stateless, responds to HTTP or events, and does not need Kubernetes primitives. Cloud Run eliminates cluster management, node upgrades, and manifest maintenance entirely. For a deeper comparison, see GKE vs Cloud Run.

Choose GKE when you need StatefulSets, DaemonSets, CRDs, a service mesh, namespace-level isolation, or when your team has already invested in Kubernetes tooling. GKE gives you control Cloud Run does not expose, but that control adds operational cost.

GKE Autopilot narrows the gap by removing node management, but you still maintain Kubernetes manifests, configure RBAC, and manage upgrades. Cloud Run removes all of that. See Kubernetes vs Serverless for the broader trade-off.

Cloud Run vs Compute Engine

These two sit at opposite ends of the abstraction spectrum.

Choose Cloud Run when you can package the workload as a container and it does not need persistent local storage, a custom OS, or always-on VM access. Cloud Run is cheaper at variable traffic, deploys faster, and requires no patching. For detailed cost modelling, see Cloud Run vs Compute Engine.

Choose Compute Engine when the workload needs a full VM: custom kernel, Windows Server, software that expects a traditional OS environment, or direct hardware access. Compute Engine also wins on per-unit cost at sustained high scale with committed use discounts.

GKE vs Compute Engine

Both require you to manage infrastructure, but at different levels.

Choose GKE when the workloads are containerised and you need orchestration: scheduling, scaling, service discovery, and rolling updates across multiple services. GKE handles these natively through the Kubernetes API. See Compute Engine vs GKE for a detailed comparison.

Choose Compute Engine when the workloads are not containerised, need a specific OS, or when adding a Kubernetes cluster would be overkill for a small number of VMs. Managed instance groups with autoscaling give you scaling without Kubernetes.

Cost and operational trade-offs

Cost depends on traffic pattern, instance shape, memory, region, egress, concurrency settings, and discount commitments. There is no single cheapest option. The right answer depends on your workload profile.

At idle or low traffic

Cloud Run wins. It scales to zero and costs nothing when idle. GKE Standard clusters have a baseline control plane and node cost even with no traffic. Compute Engine VMs bill per second regardless of utilisation. For cost strategies at low traffic, see Cloud Run Cost Optimisation.

At bursty or variable traffic

Cloud Run wins again. Per-request billing means you pay proportionally to actual traffic. GKE and Compute Engine autoscaling helps, but both have lag and minimum resource floors. Cloud Run scales in seconds.

At steady, moderate traffic

The gap narrows. A well-sized GKE Autopilot cluster or Compute Engine VM approaches Cloud Run’s effective cost. The operational cost of managing that infrastructure is the real differentiator at this tier.

At sustained high traffic

Compute Engine and GKE Standard with committed use discounts (1-year saves up to 37%, 3-year up to 55%) produce the lowest per-unit compute cost. Cloud Run per-request billing becomes more expensive relative to reserved capacity at this scale. See Compute Engine Cost Optimisation for discount strategies.

Operational cost is real cost

Cloud Run requires near-zero operational effort. GKE requires Kubernetes expertise, cluster upgrades, node pool management, and manifest maintenance. Compute Engine requires OS patching, disk management, and custom monitoring. Engineer time spent on infrastructure is a cost that does not appear on your GCP bill, but it affects your total spend.

Recommended starting path

If you are building a new project and are not sure where to start:

1. Deploy all HTTP services to Cloud Run. Zero operational overhead. Deploys in under a minute. Costs nothing at idle.
2. Use managed data services. Cloud SQL for relational data. Firestore for document data. Neither requires a GKE cluster or a self-managed VM.
3. Use Pub/Sub or Cloud Tasks for async work. Cloud Run handles both via push subscriptions and task handler endpoints. See Event-Driven Systems in GCP for patterns.
4. Add GKE when you hit a concrete Kubernetes requirement. StatefulSets, DaemonSets, CRDs, or a service mesh. Start with GKE Autopilot to avoid node management.
5. Add Compute Engine when you hit a concrete VM requirement. Legacy software, custom OS, specific hardware, or a self-managed database with local SSDs.