4.1 Choosing the Right Compute Option: GCE vs. GKE vs. Cloud Run vs. Cloud Functions
Key Takeaways
- Compute Engine (IaaS VMs) is billed per second for provisioned resources regardless of use; it is the right choice for legacy OS/kernel/licensing constraints.
- GKE is a managed Kubernetes control plane; choose it for multi-service, orchestration-heavy, or hybrid/multi-cloud container workloads.
- Cloud Run is serverless container hosting for stateless HTTP(S) services, billed per request, with request timeouts up to 3,600 seconds (60 minutes).
- Cloud Run functions is Google Cloud's FaaS product for single-purpose event/HTTP handlers, capped at 9 minutes for event triggers and 60 minutes for HTTP triggers.
- The ACE exam tests this choice as a repeated scenario pattern: match workload shape (VM/container/function) and orchestration need to the simplest product that satisfies the constraints.
Why This Section Matters
The official ACE exam guide lists "Planning and configuring a cloud solution" as its own 17.5%-weighted section, and the very first bullet under it is selecting appropriate compute choices for a given workload. In practice this means the exam constantly hands you a one- or two-sentence scenario — a legacy Windows app, a stateless REST API, a Kubernetes-native microservice mesh, a function that resizes an uploaded image — and asks which Google Cloud compute product you would deploy it on. Getting this decision right (and fast) is one of the highest-leverage skills you can build for the ACE exam, because the same reasoning reappears throughout Domain 3 (deploying) and Domain 4 (operating) questions later in this guide.
The Four Core Compute Products
Compute Engine (GCE) is Google Cloud's Infrastructure-as-a-Service (IaaS) offering: virtual machines (VMs) you fully control, down to the kernel, OS image, and installed software. You are billed per second for the VM's provisioned vCPUs and memory whether or not the VM is actively doing work.
Google Kubernetes Engine (GKE) is a managed Kubernetes control plane and node-pool service. Kubernetes is a container-orchestration system that schedules, scales, and self-heals groups of containers (Pods). GKE is the right call when a workload is genuinely container-native, has multiple interacting services, needs advanced scheduling (affinity rules, DaemonSets, StatefulSets), or must run identically across on-premises, other clouds, and Google Cloud.
Cloud Run is a fully managed, serverless platform for stateless HTTP(S) containers. You supply any container image built from any language or runtime, and Cloud Run handles provisioning, scaling (including scale-to-zero when idle), and load balancing. Cloud Run is billed per request/per 100ms of CPU and memory actually used, not per provisioned instance-hour.
Cloud Run functions (the current name for what was previously branded Cloud Functions 2nd gen) is Google Cloud's Function-as-a-Service (FaaS) product: you write a single function and Google Cloud builds and runs the container for you, triggered by an HTTP request or an event (a new object in a Cloud Storage bucket, a Pub/Sub message, a Firestore write). It is built on the same underlying infrastructure as Cloud Run but optimized for single-purpose, short-lived, event-reactive code rather than general-purpose services.
Comparison Table
| Dimension | Compute Engine | GKE | Cloud Run | Cloud Run functions |
|---|---|---|---|---|
| Abstraction level | Full VM (IaaS) | Managed Kubernetes | Serverless container | Serverless single function |
| You manage | OS, patching, scaling | Workload manifests (Autopilot also hides nodes) | Container image only | Function code only |
| Billing model | Per-second, resource-based | Per-node (Standard) or per-Pod (Autopilot) | Per-request / CPU-time used | Per-invocation / execution time |
| Scale to zero | No | No (Standard); yes for Pods on some setups | Yes | Yes |
| Best for | Legacy apps, custom kernels, licensing tied to hardware, sole-tenant needs | Multi-service container platforms, hybrid/multi-cloud portability | Stateless HTTP APIs and web front ends | Single-purpose event handlers |
| Max request/timeout | N/A (always-on) | N/A (app-defined) | Up to 3,600 seconds (60 min) per request | 60 min (HTTP triggers) / 9 min (event triggers) |
A Simple Decision Framework
Work through these questions in order, and the right product usually falls out immediately:
- Is the workload one small, single-purpose piece of code reacting to an event or a simple HTTP call, with no need to manage a container image yourself? Choose Cloud Run functions.
- Is it a containerized, stateless HTTP(S) service (an API, a web app, a webhook receiver)? Choose Cloud Run — you get autoscaling and scale-to-zero without managing servers or a cluster.
- Does the workload need multiple coordinated containers, custom scheduling, StatefulSets, GPUs/TPUs at fleet scale, service mesh, or the ability to run identically on-prem or in another cloud? Choose GKE.
- Does it require full OS-level control, a specific kernel module, legacy or hardware-bound software licensing, or sustained, predictable throughput with no cold starts? Choose Compute Engine.
Realistic Exam Scenario
A company runs a monolithic .NET Framework application that checks a hardware dongle for its license and must run on a specific Windows Server build. It needs no autoscaling and runs 24/7. The correct answer is Compute Engine — the licensing and OS constraints rule out every serverless option, and there is no meaningful container-orchestration need that would justify GKE's operational overhead.
Contrast that with: "A team wants to run 12 microservices that must scale independently, communicate over gRPC, and eventually also run on AWS for disaster recovery." That combination — multiple services, advanced networking, multi-cloud portability — points straight at GKE, not Cloud Run, because Cloud Run does not give you the fine-grained scheduling or hybrid-cloud consistency Kubernetes manifests provide.
Common Traps
- Assuming "serverless" always means Cloud Run functions. Cloud Run (the container product) is also serverless — the distinguishing question is single-function code versus a full container image.
- Choosing GKE by default because it "can run anything." GKE is correct only when the scenario mentions genuine orchestration needs (multiple services, custom scheduling, hybrid/multi-cloud). If the scenario only describes one stateless container, Cloud Run is simpler and is very likely the intended answer.
- Forgetting that Cloud Run functions event triggers cap out at 9 minutes — a scenario describing a long-running batch job (say, 30 minutes) triggered by a file upload is not a fit for an event-triggered function and should push you toward Cloud Run (up to 60 minutes) or a Compute Engine/Dataflow job instead.
A retailer needs a small piece of code that resizes any image uploaded to a Cloud Storage bucket into a thumbnail, runs in under 60 seconds, and should not require managing a container image. Which compute option best fits this requirement?
A team is migrating 15 interdependent microservices that require custom Pod scheduling, GPU node pools for a subset of services, and eventual portability to an on-premises Kubernetes cluster for disaster recovery. Which compute option should they plan around?