GKE cluster modes — Autopilot and Standard, who is responsible for what, and the billing dimension each uses
The first decision in any GKE design. What Autopilot manages and forbids, what Standard hands back to you, the two billing dimensions, and Google's own recommendation — with the one sentence that tells you when to override it.
markdownreferencev15XHJ-Y4R7stage: designtrust: officialfamily: computeservice: gkeinterface: anyGKEAutopilotStandardcluster modenode poolprivileged podsbin-packingkubernetes engineprovisioned compute
GKE cluster modes
1. The two modes
Autopilot is "a managed experience in which GKE handles most of your infrastructure for you so that you can focus on your applications."
Standard is the flexible mode: you control the node infrastructure and the autoscaling directly.
2. Who is responsible for what
| Autopilot | Standard | |
|---|---|---|
| cluster infrastructure | GKE | you |
| nodes and node pools | GKE | you — you configure node pools |
| scaling | GKE, with automatic bin-packing | you configure it |
| security posture | GKE applies constraints by default, and prevents privileged Pods | you set the policies |
| resource allocation | GKE | you |
3. What Autopilot will not run
Workloads that need special privileges, or granular infrastructure control that would violate Autopilot's constraints. "Prevents privileged Pods" is the clause to check a workload against first, because it rules out a recognisable class: node-level agents, some CSI and CNI add-ons, anything that wants host namespaces or host paths, and several third-party security and observability products.
The page describes the restriction at that level and does not enumerate every forbidden field. So the design step is: list the Pod specs that need privileges or host access, and check those against Autopilot's own constraints page before choosing.
4. Billing dimension (never a price)
| Mode | Metered on |
|---|---|
| Autopilot | the provisioned compute resources your workloads request |
| Standard | the node infrastructure you create |
This is the most consequential difference for a cost estimate, and it is a difference in what is counted, not
in rate. On Standard you pay for nodes whether or not Pods fill them, so idle headroom is yours to pay for and
yours to tune. On Autopilot you pay for what the workloads request, so over-requested Pod resources become a
direct bill — a requests block copied from an on-premises cluster with generous margins is a real cost on
Autopilot and invisible on Standard.
A lift-and-shift onto Autopilot should therefore be preceded by a pass over every resources.requests in the
manifests. That pass is usually the largest single saving available in a Kubernetes migration onto Google
Cloud.
5. Google's recommendation, and when to override it
"Use Autopilot for most workloads, unless your application requires privileges or configuration options that don't meet the Autopilot constraints."
Autopilot is labelled "recommended". The override condition is capability, not scale — nothing in the recommendation is about cluster size.
6. An absence, recorded
The Workload Identity Federation for GKE page does not state whether the feature is enabled by default on
Autopilot clusters, so this document does not say so either. Check the cluster's own configuration
(reference/identity/workload-identity-federation.md §5). The cluster's pool name is always
PROJECT_ID.svc.id.goog.
Next: guides/parity/compute.md compares both modes to EKS, EKS Auto Mode and AKS.