GKE Autopilot vs Standard: Key Differences, Costs, and When to Use Each

Simple explanation

GKE Autopilot — Google manages the nodes. You deploy Pods, and GKE provisions the right virtual machine capacity automatically. Nodes are scaled, upgraded, and hardened by Google without any action from you. You are billed for what your Pods request, not for the underlying VMs.

GKE Standard — You manage the nodes. You create node pools, choose machine types, configure autoscaling, and handle upgrades. Google still manages the control plane (the API server, scheduler, and etcd), but the data plane is your responsibility. You are billed for the node VMs you provision.

How it works

In every GKE cluster, regardless of mode, Google manages the control plane: the Kubernetes API server, scheduler, controller manager, and etcd. You never provision or patch control plane VMs. This is the same in both modes.

Where Standard and Autopilot diverge is the data plane: the virtual machines where your Pods actually run.

In Standard mode, you are responsible for the data plane:

• You create node pools with specific machine types, disk sizes, and OS images.
• You configure the Cluster Autoscaler if you want nodes to scale automatically.
• You enable node auto-upgrade and auto-repair, and choose when upgrades happen.
• You ensure nodes are hardened to meet your security requirements.
• You pay for all provisioned node VMs, whether or not they are fully utilised.

In Autopilot mode, Google manages the data plane:

• You deploy Pods with CPU, memory, and storage requests.
• GKE automatically provisions node capacity that matches your Pod requirements; you never create or configure node pools.
• Nodes are scaled, upgraded, and repaired by Google with no action on your part.
• Security hardening, including enforcing Workload Identity, blocking privileged containers, and restricting hostPath volumes, is applied by default.
• You pay for the resources your Pods request, not for underlying VMs.

Scaling: In Standard, you configure both the Horizontal Pod Autoscaler (for Pods) and the Cluster Autoscaler (for nodes). In Autopilot, scaling is fully automated — GKE adjusts node capacity based on current Pod demand.

Upgrades: In Standard, you control the upgrade channel and maintenance windows. See upgrading GKE clusters safely for details. In Autopilot, upgrades are applied automatically and cannot be deferred indefinitely.

Creating each cluster type:

# Create an Autopilot cluster (always regional)
gcloud container clusters create-auto my-autopilot-cluster \
  --region=europe-west2 \
  --project=my-project

# Create a Standard cluster
gcloud container clusters create my-standard-cluster \
  --region=europe-west2 \
  --project=my-project \
  --num-nodes=3 \
  --machine-type=e2-standard-4 \
  --enable-autoscaling \
  --min-nodes=1 \
  --max-nodes=10

Note the command difference: Autopilot uses create-auto. Autopilot clusters are always regional; you cannot create a zonal Autopilot cluster.

GKE Autopilot vs Standard at a glance

Billing and cost differences

GKE Standard: per-node billing

In Standard mode, you pay for every node VM provisioned in your node pools, based on machine type, vCPU count, memory, disk size, and network egress. If you provision three e2-standard-4 nodes (4 vCPUs, 16 GB RAM each), you pay for all 48 GB of RAM and 12 vCPUs regardless of how much of that capacity your Pods are actually using. Idle capacity costs the same as utilised capacity.

GKE Autopilot: per-Pod billing

In Autopilot, you pay for the sum of resources requested by your running Pods:

• Per-vCPU-hour for CPU requests
• Per-GB-hour for memory requests
• Per-GB-hour for ephemeral storage requests

For broader GCP cost management guidance, see cost optimisation strategies.

When Autopilot is often more cost-effective#

• Bursty or variable workloads: Pods that run intermittently cost nothing when not running. You are not paying for idle node capacity overnight or between batch runs.
• High Pod density: When Pods pack nodes efficiently, Autopilot’s per-request billing avoids the wasted headroom common in under-utilised Standard clusters.
• Small or growing teams: Fewer Pods means less idle VM capacity to pay for, and Autopilot ensures capacity scales down when not needed.

When Standard can be more cost-effective#

• Very low Pod density: A small number of Pods spread across large nodes means your effective per-Pod cost in Standard can be lower than Autopilot’s per-request rates.
• Spot VM node pools: Standard supports Spot VMs as node pool VM types, which cost 60–91% less than standard VMs. This can significantly undercut Autopilot pricing for fault-tolerant workloads.
• Sustained, predictable workloads: If your cluster runs near-full utilisation around the clock, committed use discounts on Standard nodes can reduce costs significantly.

The honest answer is that neither mode is universally cheaper. Model your actual workload shape (expected Pod count, resource requests, and utilisation patterns) before drawing conclusions.

Performance, flexibility, and operational trade-offs

What Standard gives you

Standard mode offers full control over the data plane. You can:

• Choose any machine type, from small e2-micro instances to high-memory n2-highmem-96 nodes.
• Create multiple node pools with different machine types, labels, and taints in one cluster. For example, a lightweight pool for web services, a high-memory pool for data processing, and a GPU pool for ML inference, all running together.
• Use Spot VMs to reduce cost on fault-tolerant workloads.
• Build private clusters with highly customised networking configurations.
• Deploy custom DaemonSets for log shipping, security agents, or node monitoring.
• Access nodes via SSH for debugging, compliance evidence collection, or custom tooling.
• Use the full range of NVIDIA GPU types (L4, T4, A100, H100) with specific driver versions and GPU time-slicing.

What Autopilot trades away for simplicity

Autopilot removes most of this flexibility by design. The trade-offs are deliberate:

• No custom DaemonSets. If your monitoring or security tooling requires per-node agents, you must refactor or use Standard.
• No SSH node access. Debugging must happen through kubectl exec, kubectl logs, and ephemeral debug containers.
• No hostPath volumes or host networking. Workloads requiring host-level access are incompatible with Autopilot.
• Limited GPU types. Autopilot supports a subset of the GPU types available in Standard.
• No control over node VM types, OS images, or kernel parameters.

This is not a flaw. It is the deliberate design. Autopilot’s restrictions allow Google to guarantee security defaults, automate operations reliably, and bill accurately per Pod.

The security upside of Autopilot

Autopilot enforces security configurations that many teams would struggle to apply consistently in Standard. Workload Identity is enabled and the metadata server is restricted by default. Privileged containers are blocked. Container-Optimised OS (COS) is used for all nodes. These defaults align Autopilot with the GKE hardening recommendations that Standard clusters require you to implement manually.

When to use Autopilot

Autopilot is the right default for most new clusters, especially when:

• Your team is small or lacks deep Kubernetes expertise. You get a production-ready, secure cluster without needing to learn node pool management, upgrade windows, or node-level hardening.
• You are building web apps, APIs, or internal tools. Standard web workloads, including stateless Deployments, Services, and Ingress, run without modification on Autopilot.
• Your workloads are bursty or variable. Batch jobs, event-driven processing, or anything that scales to zero benefits from Autopilot’s per-Pod billing.
• You want strong security defaults out of the box. Autopilot’s enforced policies (blocked privileged containers, enforced Workload Identity, no node SSH) reduce the attack surface without manual configuration.
• You are starting a new cluster from scratch with no dependency on DaemonSets, hostPath volumes, or custom node images.

Example: a small engineering team deploying a suite of web services and background jobs, using Cloud SQL and Pub/Sub. No custom node requirements, no DaemonSets, and a team that would rather focus on application code than cluster maintenance. Autopilot handles everything at the infrastructure layer.

When to use Standard

Standard is appropriate when your workload has specific requirements that Autopilot cannot satisfy:

• You need custom DaemonSets. Per-node agents for log shipping (such as Fluentd or Fluent Bit), security monitoring (such as Falco), or network policy enforcement require Standard mode.
• Your debugging workflow requires SSH node access. Some teams need to inspect node-level processes, review kernel logs, or collect compliance evidence from individual nodes.
• You need GPU node pools with full flexibility. ML training workloads requiring H100s, specific NVIDIA driver versions, or GPU time-slicing configurations are better served by Standard mode.
• Your Pods need host-level access. Workloads using hostPath volumes, hostNetwork, or hostPID are incompatible with Autopilot’s security model.
• You need Spot VM cost savings at scale. Standard supports Spot VM node pools, which can deliver 60–91% cost reduction for fault-tolerant workloads.
• You are running a regulated workload that requires evidence of specific node configurations, custom OS images, or audit trails for node-level changes.

Example: a platform engineering team running a shared infrastructure cluster. They need custom DaemonSets for security monitoring (Falco), multiple GPU node pools for ML workloads, and Spot VMs for cost efficiency on batch processing. Standard mode is the right choice.

Migrating between GKE Standard and Autopilot

There is no in-place mode switch. The cluster mode is set permanently at creation time. Migration means creating a new cluster and moving your workloads across.

Full pre-migration checklist:

• Custom DaemonSets: must be refactored or the migration is not viable.
• Pods using hostPath, hostNetwork, or hostPID: blocked in Autopilot.
• Privileged containers: blocked in Autopilot.
• Containers without resource requests: the Autopilot webhook will mutate these, potentially inflating cost.
• GPU requirements: confirm your GPU types are supported by Autopilot.

Migration steps:

1. Create a new Autopilot cluster in the same region.
2. Get credentials for both clusters (gcloud container clusters get-credentials) and switch between them with kubectl config use-context.
3. Update manifests to remove Autopilot-restricted features.
4. Add explicit resources.requests to all containers.
5. Deploy workloads to the Autopilot cluster and validate functionality.
6. Migrate stateful data: take PersistentDisk snapshots and restore them in the new cluster.
7. Shift traffic by updating DNS or load balancer backends to point at the new cluster.
8. Run both clusters in parallel for several days to confirm stability.
9. Decommission the Standard cluster once traffic has fully shifted.

If you are new to creating GKE clusters, creating your first GKE cluster walks through both Autopilot and Standard cluster setup step by step.

Frequently asked questions

What is the difference between GKE Autopilot and Standard?

GKE Autopilot has Google manage the data plane (nodes, scaling, upgrades, and security hardening) on your behalf. You deploy Pods and GKE provisions capacity automatically. GKE Standard gives you full control over node pools: you choose machine types, manage upgrades, configure autoscaling, and are responsible for node security. Billing also differs: Autopilot charges per Pod resource request, Standard charges per provisioned node VM.

Is GKE Autopilot cheaper than Standard?

It depends on workload shape. Autopilot bills only for CPU, memory, and storage requested by running Pods. At high Pod density or with bursty workloads, this is often more cost-effective. Standard bills for entire node VMs, so idle capacity wastes money. At very low Pod density, Standard can be cheaper. See cost optimisation strategies for guidance on modelling both options.

Can I migrate a Standard cluster to Autopilot?

There is no in-place migration. You create a new Autopilot cluster, update your manifests to remove restricted features (custom DaemonSets, hostPath volumes, privileged containers), add resource requests, and move workloads to the new cluster. The migration section above covers the full step-by-step process.

Does Autopilot support GPUs?

Yes. You request GPUs in your Pod spec using the nvidia.com/gpu resource and GKE provisions compatible capacity automatically. Autopilot supports common types such as NVIDIA T4 and L4. For the full range of GPU types, specific driver versions, or GPU time-slicing, Standard mode is more flexible.

Which GKE mode is better for beginners?

GKE Autopilot is generally better for beginners. Google manages node provisioning, upgrades, security hardening, and scaling automatically. You focus on deploying Pods without needing deep knowledge of node pool management. If your workload eventually requires DaemonSets, host-level access, or specific GPU configurations, that is the right time to evaluate Standard mode.

Final takeaway

Choose Autopilot if you want to minimise operational overhead, get strong security defaults without manual hardening, and pay for what your Pods use rather than for provisioned capacity. It is the right starting point for most teams and most workloads.

Choose Standard when you have a specific need for node-level control: custom DaemonSets, SSH access, the full GPU range, host-level access, or Spot VM cost savings at a scale that Autopilot cannot match.

If you are not sure which applies to you, start with Autopilot. The constraints are well-documented, and most workloads do not hit them. If you eventually need Standard’s capabilities, the migration path is well-defined even if it requires creating a new cluster.

Not sure whether GKE is the right choice at all? See GKE vs Cloud Run and choosing between Cloud Run, GKE, and Compute Engine to compare your options.