cloudwebschool.com

---

Cloud Run vs GKE vs VMs: how to choose the right GCP compute option

Most teams do not need more compute options. They need a sane default.

On Google Cloud, the trap is usually the same: a workload gets containerised, somebody says "we should use Kubernetes", and the team quietly signs up for more operational complexity than the service actually needs.

Here is the simpler way to think about it:

• start with Cloud Run for new stateless HTTP or gRPC services
• move to GKE when you need Kubernetes features Cloud Run does not give you
• use Compute Engine VMs when the workload cannot sensibly live in either of those models

That framing will save you time, money, and a fair amount of unnecessary platform work.

The short version

Option	Best for	Ops overhead	Scales to zero	Stateful workloads
Cloud Run	Stateless HTTP/gRPC services	Very low	Yes	No
GKE	Kubernetes workloads needing more control	Medium to high	No	Yes
Compute Engine VMs	Legacy apps, custom OS needs, hardware-specific workloads	High	No	Yes

If you are building a normal API or internal service and it is stateless, Cloud Run is usually the right place to begin.

When Cloud Run is the right answer

Cloud Run is a strong default for:

• public or internal APIs with variable traffic
• microservices with bursts of usage and long idle periods
• containerised services that only need HTTP or gRPC
• teams that want container deployment without running Kubernetes

The main reason is not just convenience. It is fit.

Cloud Run gives you container-based deployment with very little platform overhead, and it scales to zero when nothing is hitting the service. That makes it a good match for new services where you want to ship fast and avoid paying for idle compute.

If the workload is stateless and request-driven, start here unless you have a specific reason not to.

When GKE starts to make sense

GKE becomes the better fit when the workload genuinely needs Kubernetes behaviour rather than just containers.

That usually means things like:

• multi-container pods
• sidecar patterns
• PersistentVolumes for stateful services
• service mesh requirements
• existing Kubernetes manifests and operating knowledge
• GPU node pools or more advanced node-level control

The important thing is to be honest about why you are choosing it.

GKE is powerful, but it comes with more to run: cluster upgrades, node pool sizing, Kubernetes networking, and Kubernetes security. That is a fair trade if the workload needs those capabilities. It is not a fair trade for a simple stateless web service that would run happily on Cloud Run.

When a VM is still the right tool

Compute Engine still matters.

A VM is the right choice when the workload does not fit neatly into the Cloud Run or GKE model, for example:

• legacy applications that cannot be containerised cleanly
• software with specific OS or kernel requirements
• Windows Server workloads
• applications that need direct hardware access
• lift-and-shift migrations that are not ready to be redesigned yet

Sometimes the right answer is not "modernise everything first". Sometimes it is "run it on a VM because that is the practical option right now".

A simple decision flow

When I need to make this call quickly, I use four questions:

1. Can the workload be containerised?
2. Is it stateless and driven by HTTP or gRPC?
3. Does it need Kubernetes features such as sidecars, PersistentVolumes, or service mesh?
4. Does it need specific OS, kernel, or hardware control?

That usually leads to a clean result:

• if it cannot be containerised, use a VM
• if it is stateless and HTTP/gRPC, start with Cloud Run
• if it needs Kubernetes features, use GKE
• if it needs low-level machine control, use a VM

If you are still unsure, Cloud Run is the safest default for a new stateless service. You can always move up to GKE or sideways to VMs later when you hit a real limitation.

A practical example

Take a simple internal API handling about 100,000 requests per day, with each request taking roughly 100 ms.

From the source guide, the trade-off looks like this:

• Cloud Run is billed only during request handling and can end up costing only a few dollars per month for a workload at this level
• GKE Autopilot is billed per pod resource request, and a two-replica deployment running all day to avoid cold starts will usually cost more than Cloud Run at low traffic
• Compute Engine on an e2-medium is billed continuously at roughly $25-35/month

That does not mean Cloud Run is always cheapest forever. The original guide makes the opposite point as well: at very high sustained traffic, the per-request model of Cloud Run can become less attractive than a well-sized VM.

But for low-traffic and variable-traffic APIs, Cloud Run is usually hard to beat on both cost and operational simplicity.

The mistakes I see most often

The biggest mistake is defaulting to GKE for every containerised workload.

Containers are not the same thing as Kubernetes requirements. A lot of teams pick GKE because it feels like the "serious" platform choice, when what they actually need is a straightforward way to run a stateless service.

The second mistake is keeping simple APIs on VMs out of habit. If the service is stateless and containerisable, a VM often means more patching, more idle cost, and more infrastructure work than necessary.

The third mistake is treating the first decision as permanent. Workloads change. A service that starts well on Cloud Run may eventually need GKE features. A VM-hosted workload may later become container-friendly. Revisit the choice when the requirements change.

What I would recommend

If you are choosing for a new service today:

• pick Cloud Run for stateless request-driven workloads
• pick GKE only when you can point to a Kubernetes-specific need
• pick Compute Engine when the application needs full machine-level control or cannot be containerised sensibly

Most real architectures end up using all three somewhere. The goal is not to choose one platform for everything. The goal is to use the simplest option that still fits the workload properly.

If you want the fuller breakdown, read the original Cloud Run vs GKE vs VMs guide.

If cost is part of the decision, it is worth checking the Cloud Run Cost Calculator before you compare Cloud Run against a fixed VM or GKE setup.