Lesson 2: Choosing Compute Engine, GKE or Cloud Run

Why this decision is on the exam

Section 1.1 of Google's exam guide begins with "Choosing the appropriate platform based on the use case and requirements (e.g., Compute Engine, Google Kubernetes Engine, Cloud Run)". The same section also lists "Optimizing for cost and resource usage". The exam often puts these two items into one question: a scenario describes a workload and you pick where it runs. A reminder from Level 1: the exam guide belongs to Google and is free on its certification page. The exam lasts 2 hours, has 50–60 questions and costs $200. This course is independent of Google, is not endorsed by Google, and cannot promise you a pass.

Picture the three platforms as three ways to get a meal:

• Compute Engine: you rent a whole kitchen. You choose the oven, the knives and the recipe, and you also clean up afterwards. These are virtual machines. You manage the OS, patching and scaling yourself, or with managed instance groups.
• GKE (Google Kubernetes Engine): you run a restaurant kitchen with a standard layout. Kubernetes runs your containers. In Standard mode you still own the worker nodes. In Autopilot mode, as Google's documentation says, "Google manages your infrastructure configuration, including your nodes, scaling, security".
• Cloud Run: you order delivery. You hand over a container (or source code), Cloud Run gives you a URL, and instances scale with traffic, all the way down to zero.

Going down that list, you give up control and you get less operations work in return. That trade-off settles most exam questions.

Walkthrough: the same app, three ways

Take a stateless JSON API that gets busy during the day and is idle at night.

# Option 1: Cloud Run. One command; no cluster, no VMs.
gcloud run deploy orders-api \
  --image=europe-west1-docker.pkg.dev/my-proj/apps/orders-api:1.4 \
  --region=europe-west1 \
  --min-instances=0 \
  --max-instances=20 \
  --concurrency=80
# --min-instances=0  -> scales to zero at night (no idle instances to pay for)
# --max-instances=20 -> caps cost and protects the database behind it
# --concurrency=80   -> up to 80 requests share one instance (the maximum is 1,000)

# Option 2: GKE Autopilot. You get a full Kubernetes API, but Google runs the nodes.
gcloud container clusters create-auto shop-cluster --region=europe-west1
kubectl apply -f orders-deployment.yaml   # you still write Deployments, Services and so on

# Option 3: GKE Standard. You size and look after the node pools yourself.
gcloud container clusters create shop-std \
  --zone=europe-west1-b --num-nodes=3 --machine-type=e2-standard-4
# Those 3 VMs bill around the clock, whether pods use them or not.

# Option 4: Compute Engine. A raw VM; installing, patching and scaling are your job.
gcloud compute instances create orders-vm \
  --zone=europe-west1-b --machine-type=e2-standard-2
# Next: SSH in, install the runtime, set up a managed instance group for autoscaling...

All four will serve the API. Only the first matches "spiky, stateless, small team, minimise cost" without adding work nobody asked for.

How the money actually works

Cloud Run offers two billing settings:

• Request-based billing (the default): instances are billed only while they start, handle requests and shut down. With --min-instances=0, a service with no traffic costs nothing for compute.
• Instance-based billing: instances are billed for their entire lifetime, idle time included. Choose this when the container does background work between requests (gcloud run deploy ... --no-cpu-throttling).

Gotcha: cold starts. Scaling to zero means the first request after a quiet spell waits for a new instance to start. For latency-sensitive services, set --min-instances=1 or higher. With request-based billing, idle minimum instances are charged at a lower rate. They are not free.

GKE charges a flat cluster management fee of $0.10 per cluster per hour for every cluster, whatever the mode. The GKE free tier gives $74.40 a month per billing account, which covers the fee for one Autopilot or zonal Standard cluster. It does not cover compute. On top of that fee:

• Autopilot mostly uses pod-based billing: you pay for the CPU, memory and ephemeral storage your scheduled pods request. Unused node capacity is not your bill. (Pods that pick specific hardware, such as GPUs or a particular machine series, switch to node-based billing.)
• Standard bills you for the node VMs. A half-empty node is money wasted, so packing pods efficiently becomes your responsibility.

Compute Engine bills the VM for as long as it is running, busy or idle.

A quick worked example: suppose your API handles traffic about 8 hours a day. On Cloud Run with request-based billing, you pay roughly for those busy hours plus a little for startup. An always-on VM or node pool bills all 24 hours, so about two thirds of what you pay for goes to idle time.

A decision checklist you can run in your head

1. Does it need a specific OS or kernel, software licensed per VM, or a lift-and-shift with no containers? Use Compute Engine.
2. Is it containerised and stateless, driven by HTTP or events, and should it scale to zero with little ops work? Use Cloud Run.
3. Does it need Kubernetes itself (existing manifests, Helm charts, many services that talk to each other, Kubernetes-native tooling)? Use GKE:
   • Use Autopilot if you don't want to manage nodes. It is the sensible default.
   • Use Standard only if the scenario needs node-level control, for example custom node pool configuration.

Pitfall seen in production: teams pick GKE Standard "for flexibility", then spend their sprints on node upgrades and bin-packing for three stateless services that Cloud Run would have hosted for free overnight.

What the exam asks about this

• Most questions are scenarios. Look for phrases such as "minimise operational overhead", "unpredictable or spiky traffic", "cost-effective when idle", "existing Kubernetes manifests" or "requires a custom OS/kernel".
• Distractors usually offer more control than the scenario needs. If GKE Standard or Compute Engine appears as an answer to a stateless web API with no special requirements, it is almost always wrong. A scenario that names a hard requirement only a VM can meet is the reverse case: Cloud Run is the distractor there.
• Expect questions on the cost levers: scale-to-zero, min instances versus cold starts, the two billing settings, and pod-based versus node-based billing.

Key takeaways

• Going from Compute Engine to GKE Standard, GKE Autopilot and then Cloud Run, you give up control and do less operations work.
• Cloud Run's default request-based billing and scale-to-zero make it the cheapest home for spiky, stateless containers.
• Setting min instances above zero removes cold starts, but idle instances then cost money (at a lower rate with request-based billing).
• Every GKE cluster pays $0.10/hour. Autopilot then bills mostly by pod requests, and Standard bills by node VMs.
• Pick the platform with the least control that still meets every stated requirement.