Choosing a Compute Service

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Commands below target the gcloud CLI (release 586.0.0, 2026-09-22 line) and use us-central1 as a placeholder region; run gcloud <group> <command> --help to re-verify flags before relying on them. Product availability, launch stages and dated changes on this page were checked against the official documentation on 2026-09-30 and change over time, so read the release notes of a service before committing to it. Official documentation lives on docs.cloud.google.com; older cloud.google.com links redirect there.

Google Cloud offers a spectrum of places to run code, from raw virtual machines to fully managed functions. Picking one is mostly a question of how much of the stack you want to own: the further you move from Compute Engine towards Cloud Run, the less you configure and patch, and the fewer knobs you have. This page walks through the official guidance, gives a short summary of the options that do not get a dedicated hands-on page in this section (App Engine, Batch, VMware Engine), compares everything in one table, and then places the running Bookshelf scenario (a static front end, catalog-api, orders-api and the notifier worker) on these services. The detailed pages are Compute Engine, Cloud Run, Cloud Run scaling, traffic and jobs, Cloud Run functions and events and GKE clusters. The same exercise for the other clouds is on AWS: Choosing a compute service and Azure: Choosing a compute service.

The official guidance

Google’s "choose a compute option" documentation frames the choice by how much infrastructure you manage rather than by product name. In rough order from most control to least:

  • Compute Engine (infrastructure as a service): virtual machines you configure, patch and scale yourself.

  • Google Kubernetes Engine (container orchestration): the Kubernetes API with Google running the control plane. In Autopilot mode Google also manages nodes and bills per Pod; in Standard mode you manage node pools.

  • Cloud Run (serverless containers, functions and jobs): you provide a container image, source code or a function, and Google handles servers, scaling and, by default, scale to zero.

  • App Engine (platform as a service): the original serverless product, still supported, but Google recommends Cloud Run for new users.

  • Specialised services: Batch for queued finite jobs, and Google Cloud VMware Engine for running existing VMware workloads unchanged.

The recommended default for a new stateless HTTP service is Cloud Run. Move to GKE when you need the Kubernetes API, custom controllers or operators, or a platform shared by many teams; move to Compute Engine when you need OS or kernel control, specialised hardware or a lift-and-shift. The flowchart below condenses those criteria into the options this section documents. It is a starting point, not a substitute for the official guide, and every box can legitimately be overridden by existing team skills or a compliance requirement.

flowchart TD Start["Need to run code on Google Cloud"] VMware{"Existing VMware workloads to move unchanged?"} FullOS{"Need full OS or kernel control, special hardware or a lift-and-shift?"} Batch{"Queued, finite batch jobs that run to completion on many VMs?"} Legacy{"Existing App Engine app?"} K8s{"Need the Kubernetes API, CRDs, operators or a shared platform?"} Event{"Small event-driven function?"} Container{"Stateless HTTP service, container or source?"} Start --> VMware VMware -- Yes --> VMWE["Google Cloud VMware Engine"] VMware -- No --> FullOS FullOS -- Yes --> GCE["Compute Engine and managed instance groups"] FullOS -- No --> Batch Batch -- Yes --> BATCH["Batch"] Batch -- No --> Legacy Legacy -- Yes --> AE["Keep on App Engine, plan migration to Cloud Run"] Legacy -- No --> K8s K8s -- Yes --> GKE["GKE, Autopilot first"] K8s -- No --> Event Event -- Yes --> CRF["Cloud Run functions"] Event -- No --> Container Container -- Yes --> CR["Cloud Run services"] Container -- No --> GKE

References: Choose a compute option, Application hosting options, What is Cloud Run.

Current status of retired and changed services

Older tutorials and books still recommend services or workflows whose status has changed. As of 2026-09-30:

  • App Engine is still available, but Google recommends Cloud Run for new users. The legacy first-generation standard runtimes (for example Python 2.7, Java 8, Go 1.11 and PHP 5.5) are decommissioned on 2027-01-31. The gcloud beta app migrate-to-run assistant is in Preview.

  • Cloud Functions was renamed Cloud Run functions on 2024-08-22. Since 2025-02-19 functions can be deployed directly as Cloud Run services. First-generation functions remain supported with no shutdown date announced; see Cloud Run Functions and Events.

  • Container Registry (gcr.io) was shut down on 2025-03-18; images live in Artifact Registry. See Container Registry and Builds.

  • The container startup agent for Compute Engine (konlet) and gcloud compute instances create-with-container were deprecated on 2025-07-21. Since 2026-07-31 you cannot create VMs or managed instance groups with them, and support for the agent ends on 2027-07-31. Run Docker from a startup script or cloud-init, or move to Cloud Run, GKE or Batch.

  • Cloud Run for Anthos is now Knative serving on GKE and is not covered here.

  • The GKE Enterprise features (fleets, Config Sync, Policy Controller) were folded into GKE on 2025-09-02, so there is a single GKE offering rather than a separate enterprise tier.

References: App Engine runtime support schedule, Cloud Run release notes, Container startup agent deprecation, Container Registry deprecation.

Compute Engine

Compute Engine is the IaaS baseline: virtual machines on Google hardware. You choose an image, a machine family and type (E2, N4, C4, C4A Arm and others), disks (Persistent Disk or Hyperdisk) and a network placement, and you own everything above the hypervisor: patching, runtime, process supervision and scaling. Reach for it when you need OS or kernel control, GPUs or other specialised hardware, licensing tied to a machine image, a lift-and-shift of an existing server, or the lowest unit cost for steady workloads. Compute Engine is also the capacity under GKE Standard and Batch. Pricing is per second while an instance runs (with a one-minute minimum), with sustained-use and committed-use discounts and Spot VMs as cost levers; there is a small Always Free allowance on one small instance type in selected US regions. The full hands-on treatment is on Compute Engine.

References: Compute Engine overview, Compute Engine pricing.

Cloud Run

Cloud Run runs containers on Google’s scalable infrastructure with no cluster to manage. It has four workload types:

  • Services respond to HTTP, HTTP/2, WebSocket or gRPC requests, scale automatically with traffic and can scale to zero. Each deployment creates an immutable revision, and traffic can be split between revisions.

  • Jobs run a container to completion, optionally as many parallel tasks (up to 10,000 tasks, with task timeouts up to 168 hours), triggered manually or by Cloud Scheduler.

  • Worker pools (GA 2026-04-14) run pull-based consumers such as a Pub/Sub pull subscriber or a Kafka consumer, with no inbound HTTP endpoint.

  • Functions (formerly Cloud Functions) deploy a single function from source with the Functions Framework, built and served as a Cloud Run service.

You can deploy from a container image, directly from source (Google Cloud buildpacks or a Dockerfile), or from a YAML file. Instances can have up to 8 vCPU and 32 GiB, requests can last up to 60 minutes, and the default maximum is 100 instances per service (adjustable by quota). Billing is request-based (CPU billed only while handling requests) or instance-based (CPU always allocated), plus a monthly free tier; always-warm minimum instances cost money while idle. Cloud Run is the recommended default for stateless services and APIs. Limits: no local persistent disk (mount Cloud Storage or NFS volumes instead), no privileged containers, and one container port. Details are on Cloud Run and Cloud Run scaling, traffic and jobs.

References: What is Cloud Run, Cloud Run quotas and limits, Cloud Run pricing.

Cloud Run functions

Cloud Run functions is the function-as-a-service layer: you write a function (Java, Node.js, Python, Go and other runtimes), and Google builds and runs it on Cloud Run, triggered by HTTP or by events delivered through Eventarc (Pub/Sub, Cloud Storage, Audit Logs, Firestore and more). It suits glue code and small event handlers like the notifier that reacts to messages on the orders topic. Once a function grows into a service with several routes, packaging it as a normal Cloud Run service is usually simpler. Pricing follows Cloud Run. See Cloud Run functions and events and, for the Quarkus extensions, Serverless and Cloud Functions.

References: Cloud Run functions version comparison, Cloud Run functions overview.

Google Kubernetes Engine

GKE is managed Kubernetes. Choose it when you need the Kubernetes API and ecosystem (operators, custom resource definitions, service meshes, Helm charts), want one platform for many teams, or want portability. Two modes exist:

  • Autopilot is the recommended mode: Google manages nodes, scaling and hardening, you declare Pods with resource requests, and you are billed per Pod resource request. Autopilot compute classes can also run in qualifying Standard clusters.

  • Standard gives you node pools, machine types, custom images and node-level settings, billed per node.

Clusters can be zonal or regional (a regional control plane is recommended for production) and follow release channels (the Regular channel was on Kubernetes 1.35 when verified). There is a cluster management fee with a monthly free-tier credit. GKE does not scale to zero in the way Cloud Run does, and you take on Kubernetes upgrade cadence and manifest complexity. See GKE clusters, GKE microservices and, for the generic Kubernetes concepts, Kubernetes and OpenShift.

References: Choose a GKE mode of operation, Autopilot overview, GKE pricing.

App Engine

App Engine is Google’s original platform as a service and remains supported. This section covers it briefly because many existing applications still run there; for a new workload use Cloud Run instead.

An App Engine application lives in one region per project (the region cannot be changed later) and is made of services, each with versions, deployed from source with an app.yaml file. There are two environments:

  • Standard runs your code in a sandbox on supported language runtimes (Java 17 and 21, Python 3, Node.js, Go, PHP, Ruby and others), starts quickly, scales to zero and has a free quota. The first-generation runtimes are being decommissioned (2027-01-31), as noted above.

  • Flexible runs your app in a Docker container on Compute Engine VMs, supports custom runtimes via a Dockerfile and background threads, but does not scale to zero and is billed for the VMs it uses.

In the Google Cloud console

  1. Open the console, select the project in the project picker and open App Engine.

  2. Choose Create application the first time, pick the region and the default service account.

  3. Deploy from Cloud Shell or a local terminal (the console has no source-upload flow for App Engine); then use Versions to split traffic between versions and Settings → Custom domains to add a domain and a Google-managed certificate.

With the gcloud CLI

gcloud services enable appengine.googleapis.com cloudbuild.googleapis.com
gcloud app create --region=us-central
cat > app.yaml <<'EOF'
runtime: java21
service: default
instance_class: F2
automatic_scaling:
  min_instances: 0
  max_instances: 5
EOF
gcloud app deploy app.yaml --version=v1 --no-promote
gcloud app services set-traffic default --splits=v1=1

References: gcloud app deploy, gcloud app create, app.yaml reference.

Traffic can be split between versions by IP address, cookie or randomly:

gcloud app services set-traffic default --splits=v1=0.9,v2=0.1 --split-by=random

References: gcloud app services set-traffic, Splitting traffic.

Older guides show enabling "debug mode" on Flexible instances through Cloud Debugger tooling. Cloud Debugger was shut down on 2023-05-31 and Snapshot Debugger was archived on 2023-09-07; the current approach is Cloud Logging, Error Reporting, Cloud Trace and Cloud Profiler, covered in Monitoring and Observability. Protecting an App Engine app with Identity-Aware Proxy is covered in Identity and Access.

Migrating to Cloud Run

Google publishes migration guides for both the standard and the flexible environment. The practical path is:

  • Containerize the app (a Dockerfile, or deploy from source with buildpacks), keeping the same runtime language.

  • Replace App Engine-only APIs (the first-generation bundled services such as Memcache and Task Queues) with Memorystore, Cloud Tasks or Pub/Sub equivalents.

  • Move app.yaml settings to Cloud Run flags: automatic_scaling.max_instances becomes --max-instances, min_instances becomes --min-instances, environment variables become --set-env-vars, and handlers for static files move to Cloud Storage with a CDN or into the container.

  • Move custom domains to a global external Application Load Balancer with a serverless network endpoint group, since Cloud Run domain mapping is still in Preview.

  • Shift traffic gradually using Cloud Run revisions.

A Preview assistant automates part of the first steps:

gcloud components install beta
gcloud beta app migrate-to-run --help

References: Migrate from App Engine to Cloud Run, gcloud beta app migrate-to-run.

App Engine pricing is per instance-hour (standard, with a free daily quota) or per vCPU, memory and disk (flexible), plus network egress and optional services. See the App Engine pricing page for current figures.

Batch

Batch is a fully managed service to schedule, queue and run batch processing workloads on Compute Engine. You describe a job (a script or container, how many tasks, parallelism, machine type and optionally Spot VMs) and Batch provisions the VMs, runs the tasks, retries failures and deletes the VMs afterwards. Use it for HPC, rendering, machine learning pre-processing and large data conversions, particularly if a Cloud Run job’s limits (task timeout, 8 vCPU / 32 GiB) are too small or you need GPUs, big machine types or custom VM images. There is no extra charge for Batch itself: you pay for the Compute Engine, storage, GPU and logging resources used.

Batch needs the Batch API, the Compute Engine API and the Cloud Logging API enabled. The submitting principal needs roles such as Batch Job Editor (roles/batch.jobsEditor) and Service Account User (roles/iam.serviceAccountUser); the job’s service account needs Batch Agent Reporter (roles/batch.agentReporter) and Logs Writer (roles/logging.logWriter).

gcloud services enable batch.googleapis.com compute.googleapis.com logging.googleapis.com
cat > job.json <<'EOF'
{
  "taskGroups": [{
    "taskCount": 4,
    "parallelism": 2,
    "taskSpec": {
      "runnables": [{
        "script": { "text": "echo task $BATCH_TASK_INDEX of $BATCH_TASK_COUNT" }
      }],
      "computeResource": { "cpuMilli": 1000, "memoryMib": 512 }
    }
  }],
  "allocationPolicy": {
    "instances": [{ "policy": { "provisioningModel": "SPOT", "machineType": "e2-standard-2" } }]
  },
  "logsPolicy": { "destination": "CLOUD_LOGGING" }
}
EOF
gcloud batch jobs submit bookshelf-report --location=us-central1 --config=job.json
gcloud batch jobs describe bookshelf-report --location=us-central1 --format="value(status.state)"

References: Batch get started, gcloud batch jobs submit, Batch jobs REST reference.

Google Cloud VMware Engine

Google Cloud VMware Engine runs a dedicated VMware vSphere, vCenter, vSAN and NSX environment on Google Cloud bare-metal nodes. It exists for one purpose: moving existing VMware workloads to Google Cloud without re-platforming them, keeping the same tooling and skills, and then modernising piece by piece. It is billed per node, is not a general-purpose compute choice for new applications, and is not covered further in this section.

References: Google Cloud VMware Engine overview.

Comparison

Compute Engine GKE Standard GKE Autopilot Cloud Run App Engine

Unit you deploy

VM image, startup script

Pods on node pools

Pods (per-Pod resources)

Container, source or function

Source plus app.yaml (container on Flexible)

Control

Highest: OS, kernel, hardware

High: nodes and Kubernetes API

Kubernetes API, Google-managed nodes

Per-service settings only

Runtime and instance class

Scale to zero

No (instance groups can scale to one or more)

Node pools can scale down, the control plane remains

Workloads can, but the cluster remains

Yes for services, jobs and worker pools

Yes on Standard, no on Flexible

Scaling

Managed instance group autoscaler

HPA, VPA and cluster autoscaler

HPA, VPA and Google-managed nodes

Request-driven, concurrency based

Automatic, basic or manual

Networking

Full VPC control

VPC-native, Gateway API

VPC-native, Gateway API

Ingress settings, Direct VPC egress

Serverless VPC Access, firewall rules

Pricing model

Per second per VM and disks

Cluster fee plus per-node

Cluster fee plus per-Pod requests

Per request or per instance time, free tier

Instance hours (Standard) or VM resources (Flexible)

Best for

Legacy servers, special hardware

Platform teams needing node control

Microservices on Kubernetes

Stateless APIs, jobs, functions

Existing apps; new apps should use Cloud Run

Batch (queued finite jobs, no extra charge beyond the resources used) and VMware Engine (per-node VMware environments) fit their own niches and are summarised above rather than in the table.

References: Choose a compute option, Google Cloud pricing calculator.

Placing Bookshelf

Component Service Why

Static front end

Cloud Storage bucket behind a global external Application Load Balancer and Cloud CDN

No compute needed; see the storage and CDN pages.

catalog-api

Cloud Run service

Stateless Spring Boot API, spiky traffic, scale to zero between peaks.

orders-api

Cloud Run service (or GKE if the team already runs a cluster)

Same profile; the only difference is a private Cloud SQL or Firestore connection.

notifier

Cloud Run function triggered by Eventarc on the orders Pub/Sub topic

Small event handler that sends the confirmation email.

Nightly report

Cloud Run job started by Cloud Scheduler (Batch if it outgrows the job limits)

Finite run-to-completion work.

Bastion or legacy tooling

Compute Engine VM with no external IP, reached through IAP TCP forwarding

Needs a full OS; see the Compute Engine page.

The quickest path from nothing to a running service, using a source deploy, looks like this:

PROJECT_ID=$(gcloud config get-value project)
REGION=us-central1
gcloud services enable run.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com
gcloud run deploy catalog-api --source . --region="$REGION" --allow-unauthenticated
gcloud run services describe catalog-api --region="$REGION" --format="value(status.url)"

References: Deploy services from source code, gcloud run deploy.

The same service in the console is Cloud Run → Deploy container → Service, then pick a container image or connect a repository for continuous deployment. The authentication choice (allow public access or require authentication) is part of the same form; the resulting IAM binding is explained in Cloud Run.

Pricing and cost drivers

Every option bills for the resources it consumes, not for the product itself, except GKE’s cluster management fee. Compute Engine and GKE Standard cost money whenever instances are running, so idle capacity is the main waste. Cloud Run and App Engine Standard scale to zero and have monthly free tiers, so a quiet service costs almost nothing, but setting a minimum instance count or instance-based billing makes idle time billable. Long-running steady workloads are often cheaper on VMs with committed-use discounts than on request-billed serverless. Network egress is charged separately everywhere. Use the pricing calculator for an estimate, then set budget alerts as described in Cost Management and Billing.

References: Google Cloud pricing, Pricing calculator.

Clean up

Delete what the examples above created, in dependency order, to stop charges. App Engine applications cannot be deleted, only disabled or the project deleted; stop serving versions and delete old ones instead.

gcloud run services delete catalog-api --region=us-central1 --quiet
gcloud batch jobs delete bookshelf-report --location=us-central1
gcloud app versions list --service=default
gcloud app versions delete v1 --service=default --quiet

For a throwaway project, gcloud projects delete my-project-id removes everything at once (the project enters a 30-day pending-deletion period).

References: gcloud run services delete, gcloud batch jobs delete, gcloud app versions delete, Shutting down projects.

Related pages

References