Why GCP Compute Options Feel Overwhelming
When engineers first land in Google Cloud, the question that stops them is almost always the same: which compute service do I actually use? Compute Engine, GKE, GKE Autopilot, App Engine Standard, App Engine Flexible, Cloud Run, Cloud Functions — seven distinct options before you have written a single line of infrastructure code. The names blur together and the boundaries feel arbitrary, but two axes clarify the entire landscape immediately.
The first axis is control level: do you need to manage the operating system directly, or are you happy pushing code and letting Google handle the rest? The second axis is execution unit: are you spinning up a full virtual machine, running a container, or invoking a single function?
| Control Level | VM | Container | Function | |---|---|---|---| | High (self-managed) | Compute Engine | GKE Standard | — | | Medium (managed) | — | GKE Autopilot / App Engine Flex | — | | Low (serverless) | — | Cloud Run / App Engine Standard | Cloud Functions |
Memorise this table and everything else becomes a matter of filling in the details for each service. More than 80% of exam questions on this topic are derived from these two axes alone.
---
Compute Engine: The Full Power of IaaS
Compute Engine is the foundational IaaS offering in GCP. You get complete control over a virtual machine: OS selection, JVM version pinning, kernel parameter tuning, custom library installation, port binding — everything you can do on a physical on-premises server is available here.
Two signals in an exam question point directly to Compute Engine as the answer. The first is a Lift-and-Shift requirement: migrate without code changes. If a legacy Java application has hard dependencies on specific JVM flags (-Xms, -Xmx) and proprietary library versions, App Engine and Cloud Run impose runtime sandboxes that make migration impossible. Compute Engine is the only viable path. The second signal is physical isolation — a requirement for Sole-tenant Nodes to keep VM workloads off shared hardware.
Machine Type Selection Strategy
| Machine Family | Series Examples | Primary Use Cases | |---|---|---| | General-purpose | N2, E2, N1 | Web servers, dev environments, mid-size databases | | Compute-optimized | C2, C2D | High-performance computing, game servers, scientific simulations | | Memory-optimized | M2, M3 | SAP HANA, large in-memory databases | | Accelerator-optimized | A2, G2 | ML training, GPU inference, rendering | | Storage-optimized | Z3 | High-performance local SSD, Spanner, etc. |
Custom Machine Type is the right call when no predefined type matches your exact resource ratio. E2 scales in increments of 1 vCPU; N1 and N2 scale in increments of 2. Memory adjusts in 256 MB steps. If you need more memory per vCPU than the default ceiling allows, add the Extended Memory option.
Spot VM: The Cost Reduction Lever
Spot VM delivers up to 91% savings compared to on-demand pricing, with one trade-off: Google can reclaim the instance with 30 seconds of notice. This makes Spot VM ideal for workloads that support checkpoint-based restarts — batch processing, ML training, rendering pipelines. Committed Use Discounts (1- or 3-year commitments, 20–57% off) work best for always-on workloads and are inefficient for intermittent batch jobs.
Managed Instance Groups and Autoscaling
A Managed Instance Group (MIG) bundles multiple VMs built from the same instance template and scales the count automatically based on CPU utilisation or Cloud Pub/Sub subscription backlog. When request volumes spike into the hundreds of thousands, the recommended pattern is Pub/Sub absorbing messages durably (retained up to 7 days, never deleted before ACK) while the MIG scales VM count against the backlog metric. This decouples ingestion from processing and prevents message loss under load spikes.
---
Google Kubernetes Engine: The Standard for Container Orchestration
GKE delivers managed Kubernetes clusters on GCP. It is the most capable option for running containerised workloads at scale, and it carries proportionally higher operational complexity.
If your application is already containerised or follows a microservices architecture, GKE belongs in the conversation. If you are migrating a monolithic application without refactoring, Compute Engine avoids the containerisation overhead entirely.
GKE Standard is the right choice when you need direct control over node pools, DaemonSets, custom network policies, or other advanced Kubernetes primitives. GKE Autopilot removes node management from your responsibilities: you declare resource requirements at the Pod level and Google handles provisioning, scaling, and upgrades. Billing shifts from node VM hours to actual Pod resource requests, so you stop paying for idle node capacity.
One limitation of GKE to keep in mind: the Horizontal Pod Autoscaler (HPA) maintains a minimum of one Pod at all times. Even with zero traffic, you incur cost. If true scale-to-zero is required, Cloud Run is the answer.
---
App Engine and Cloud Run: Two Paths to Serverless Containers
Both App Engine and Cloud Run are PaaS serverless services. Developers supply code (App Engine) or a container image (Cloud Run) and skip OS patching, capacity planning, and server provisioning entirely. The difference in design philosophy is what drives the selection decision.
App Engine Standard vs App Engine Flexible
| Dimension | App Engine Standard | App Engine Flexible | |---|---|---| | Runtime | Constrained runtimes (Python, Java, Node.js, Go, PHP, Ruby) | Custom Docker container | | Scale-to-zero | Supported (zero instances when idle) | Not supported (minimum 1 instance) | | Cold start | Yes | No (always-on) | | Billing | Instance hours (free when idle) | VM hours (1-minute minimum) | | Network constraints | Some limitations | No restrictions | | Best fit | Intermittent traffic, standard runtimes | Custom binaries, always-on services |
The killer advantage of App Engine Standard is scale-to-zero: when there is no traffic, cost drops to zero. The constraint is the sandbox — custom JVM flags and proprietary native libraries are generally not supported.
Cloud Run: Core Characteristics
Cloud Run appears more often than any other service as the correct answer on GCP-ACE exam questions. Its defining characteristics are three: scale-to-zero, request-based billing at millisecond granularity, and container portability. It is the optimal choice for workloads with extreme traffic variability — think a ticket sales site that goes from idle to millions of requests within minutes of a major announcement. If cold starts are a concern, set min-instances to keep a warm pool ready. When choosing between Cloud Run and App Engine Standard, the clearest separator is the artifact: are you deploying a container image or raw source code?
---
Cloud Functions: Event-Driven Execution at Function Granularity
Cloud Functions is GCP's Functions-as-a-Service (FaaS) offering. You deploy individual functions, and they execute only in response to events. You pay based on invocation count and execution duration, with no charge for idle time.
Keywords that make Cloud Functions the right answer: no server management, pay-per-use pricing with zero idle cost, sporadic traffic, tasks completing within seconds, HTTP/Pub/Sub/Cloud Storage event triggers.
A practical example: partner order data arrives in bursts at certain hours of the day, and each record requires only a quick transformation before being forwarded downstream. Cloud Functions handles this pattern cleanly. App Engine Standard also supports scale-to-zero, but for single-function event handling, Cloud Functions offers more granular billing and lower operational surface.
Execution time limits matter. First-generation Cloud Functions cap at 9 minutes; second-generation supports up to 60 minutes. For long-running processes or sustained connections to on-premises databases, Cloud Functions is not the right fit. Share state between functions using external stores like Cloud Firestore or Cloud Memorystore — never rely on in-memory state between invocations.
---
Comparing All Five Options Side by Side
The table below consolidates billing model, scale-to-zero support, operational burden, and workload fit for each service.
| Service | Billing Basis | Scale-to-zero | Ops Burden | Best-fit Workloads | |---|---|---|---|---| | Compute Engine | Instance hours | No | High | Lift-and-Shift, legacy apps, custom runtimes | | GKE Standard | Node VM hours | No | High | Advanced K8s control, microservices | | GKE Autopilot | Pod resource requests | No | Low | Containers without K8s node management | | App Engine Standard | Instance hours | Yes | Low | Standard-runtime web apps, intermittent traffic | | App Engine Flexible | VM hours | No | Low | Custom runtimes, always-on services | | Cloud Run | Request processing time | Yes | Very low | Extreme variability, serverless containers | | Cloud Functions | Invocations + execution time | Yes | Minimal | Event-driven, sub-second to seconds tasks |
Stateless workloads pair naturally with Cloud Run, Cloud Functions, and App Engine Standard. Stateful workloads — those requiring session affinity, persistent local filesystem writes, or long-lived WebSocket connections — belong on Compute Engine or GKE.
!5 GCP compute options compared
Decision Scenarios That Trip Up Exam Candidates
Exam questions almost always ask for "the most appropriate service." Multiple services may be technically capable, but specific keywords in the scenario point to exactly one correct answer.
Scenario 1: "Minimise operational overhead" + "container-based"
GKE Standard is wrong here — node pool management, upgrades, and patching remain the team's responsibility. The correct candidates are Cloud Run or GKE Autopilot. If idle cost must be zero, choose Cloud Run. If the workload needs complex inter-service communi