Amazon EKS Auto Mode strips out the part of running Kubernetes on AWS that burns the most engineering hours: node group management. Instead of sizing instance types, patching AMIs, wiring up the AWS Load Balancer Controller, and installing the EBS CSI driver by hand, Auto Mode takes over compute, storage, and networking behind a single flag. AWS refreshed the feature twice in the back half of 2026 — cutting GPU management fees by up to 60% on July 1, then updating the Auto Mode documentation and onboarding flow on August 20 — which is why search interest in “eks auto mode” has climbed steadily this year. This tutorial walks through a full production-style setup: IAM roles, cluster creation, workload deployment, load balancing, storage, autoscaling, a custom NodePool for GPU or Spot capacity, a Terraform path, migration from an existing cluster, and a real cost breakdown, plus a complete working project you can deploy today.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is Amazon EKS Auto Mode?
Amazon EKS Auto Mode is a cluster configuration option that hands node provisioning, node scaling, AMI patching, load balancer creation, and block storage provisioning to AWS instead of leaving them to the cluster operator. Under the hood, Auto Mode runs a Karpenter-based provisioning engine, but you never install or configure Karpenter yourself — AWS manages the controller, the underlying compute fleet, and the node lifecycle as part of the EKS service. When a pod goes unschedulable, Auto Mode reads its CPU, memory, and GPU requests and launches a right-sized EC2 instance running Bottlerocket, AWS’s container-optimized operating system, joins it to the cluster, and terminates it again once it’s no longer needed.
The practical effect is that a Kubernetes Service of type LoadBalancer automatically provisions an Application or Network Load Balancer without a manually installed AWS Load Balancer Controller, and a PersistentVolumeClaim against the default storage class automatically provisions an EBS volume without a manually installed EBS CSI driver add-on. Two default node groupings — a system NodePool for cluster add-ons and a general-purpose NodePool for application workloads — exist from the moment the cluster comes up, and you can layer custom NodePools on top for GPU, Spot-only, or Graviton-only capacity.
The shift matters because node group maintenance has quietly become one of the biggest recurring line items in platform team backlogs. A traditional EKS setup means someone owns the AMI update cadence, tracks CVEs against the base image, tunes an Auto Scaling Group’s min/max/desired counts, and keeps the AWS Load Balancer Controller and EBS CSI driver add-ons patched on their own release schedule, all separate from the application code the cluster actually exists to run. Auto Mode collapses that surface area into a managed AWS service boundary, which is also why platform teams evaluating it tend to frame the decision less as “can we afford the management fee” and more as “what is an hour of platform engineering time worth relative to that fee.” For teams running dozens of clusters across environments, the fee scales linearly with usage while the operational savings scale with headcount, which tips the math toward Auto Mode faster than a single-cluster comparison suggests.
EKS Auto Mode vs Managed Node Groups vs Fargate vs Self-Hosted Karpenter
EKS gives you four realistic ways to run compute today, and they trade operational effort for cost and control in different amounts. The table below compares the options as they stand in September 2026.
| Compute option | Who patches nodes | Who installs LB controller / CSI driver | Scaling engine | Extra management fee |
|---|---|---|---|---|
| EKS Auto Mode | AWS | AWS (built in) | Managed Karpenter (AWS-run) | ~10–12% over EC2 On-Demand price |
| Managed Node Groups | You trigger, AWS executes rolling update | You install | Cluster Autoscaler or self-hosted Karpenter | $0 (EC2 price only) |
| Self-hosted Karpenter on EC2 | You (via AMI or Bottlerocket update) | You install | Karpenter (self-managed) | $0 (EC2 price only) |
| AWS Fargate for EKS | AWS (no visible nodes) | N/A, per-pod networking | N/A, one microVM per pod | Fargate vCPU/GB premium over EC2 |
Self-hosted Karpenter and Auto Mode share the same underlying scheduling logic — both read pending pod requests and pick instance types accordingly — but Auto Mode removes the step of installing, upgrading, and securing the Karpenter controller yourself. Teams that already run a self-hosted Karpenter deployment on EKS should weigh the ~10–12% management fee against the engineering time spent keeping that controller patched. For a broader comparison of the autoscaling engines available on Kubernetes generally, see how Karpenter, Cluster Autoscaler, and KEDA stack up outside the AWS-managed path, and for how EKS Auto Mode fits against Azure and Google’s managed Kubernetes offerings, see the EKS vs AKS vs GKE comparison.
In practice, most platform teams don’t pick one option cluster-wide — they mix them. A common pattern in 2026 is Auto Mode for the general-purpose general-purpose and system NodePools, Fargate for a handful of low-traffic internal tools where per-pod isolation matters more than density, and a self-hosted Karpenter NodePool reserved for one specialized workload class (large-memory batch jobs, for instance) where the team wants fine-grained control over consolidation timing that Auto Mode doesn’t expose. That mixed model is straightforward because Auto Mode NodePools and self-hosted Karpenter NodePools use the same CRDs and can coexist in the same cluster, as long as they aren’t both targeting the same pending pods (see Pitfall 2 below for what happens when they do).
Prerequisites: Tools, Versions, and IAM Access
Gather these before starting. Version numbers below are minimums; always pull the latest patch release of each tool.
- An AWS account with billing enabled and an IAM identity that can create IAM roles, EKS clusters, VPCs, and EC2 resources (AdministratorAccess is simplest for a first run; scope it down for production).
- AWS CLI v2, version 2.15 or newer, configured with
aws configureor an SSO profile. - kubectl matching the Kubernetes minor version your cluster will run (EKS defaults to the latest AWS-supported version unless you pin one with
--kubernetes-version). - eksctl, latest released version, if you want the CLI-driven path used in Steps 1–10 below.
- Terraform v1.9 or newer and the AWS provider, only needed for the Infrastructure-as-Code path in Step 11.
- An existing VPC with subnets across at least two Availability Zones, or let eksctl create one for you (the default in this tutorial).
- Helm v3.14 or newer, optional, only needed if you add extra cluster add-ons beyond what Auto Mode manages.
- Roughly 90 minutes and an AWS budget of a few dollars — you’ll tear the cluster down in the final step, but leaving it running overnight will accrue the standard $0.10/hour control plane fee plus node costs.
Step 1: Create the IAM Roles for the Cluster and Nodes
Auto Mode needs two IAM roles with a different policy set than a traditional EKS cluster, as detailed in AWS’s official Auto Mode getting-started guide: a cluster role that authorizes AWS to manage compute, storage, and networking on your behalf, and a node role that Auto Mode-provisioned EC2 instances assume when they join the cluster.
The Cluster Role
Beyond the standard AmazonEKSClusterPolicy, Auto Mode requires four additional managed policies attached to the cluster’s IAM role: AmazonEKSComputePolicy, AmazonEKSBlockStoragePolicy, AmazonEKSLoadBalancingPolicy, and AmazonEKSNetworkingPolicy. These grant EKS permission to launch and terminate EC2 instances, provision EBS volumes, and create Elastic Load Balancers automatically.
aws iam create-role --role-name eks-automode-cluster-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Service": "eks.amazonaws.com"},
"Action": "sts:AssumeRole"
}]
}'
for POLICY in AmazonEKSClusterPolicy AmazonEKSComputePolicy \
AmazonEKSBlockStoragePolicy AmazonEKSLoadBalancingPolicy \
AmazonEKSNetworkingPolicy; do
aws iam attach-role-policy \
--role-name eks-automode-cluster-role \
--policy-arn arn:aws:iam::aws:policy/$POLICY
doneThe Node Role
Auto Mode nodes use a minimal worker policy set — AmazonEKSWorkerNodeMinimalPolicy and AmazonEC2ContainerRegistryPullOnly — which is intentionally narrower than the policies attached to a traditional Managed Node Group role, since AWS itself handles the AMI lifecycle.
aws iam create-role --role-name eks-automode-node-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}]
}'
for POLICY in AmazonEKSWorkerNodeMinimalPolicy AmazonEC2ContainerRegistryPullOnly; do
aws iam attach-role-policy \
--role-name eks-automode-node-role \
--policy-arn arn:aws:iam::aws:policy/$POLICY
doneStep 2: Launch Your EKS Cluster With Auto Mode Enabled
Auto Mode is an opt-in flag at cluster creation. Using the AWS CLI directly, you enable it with three configuration blocks: --compute-config (turns on managed node provisioning), --storage-config (turns on managed EBS provisioning), and --kubernetes-network-config with elastic load balancing enabled (turns on managed ALB/NLB creation).
aws eks create-cluster \
--name automode-demo \
--role-arn arn:aws:iam::<ACCOUNT_ID>:role/eks-automode-cluster-role \
--resources-vpc-config subnetIds=subnet-aaa,subnet-bbb,subnet-ccc \
--compute-config enabled=true,nodeRoleArn=arn:aws:iam::<ACCOUNT_ID>:role/eks-automode-node-role,nodePools=system,general-purpose \
--storage-config blockStorage={enabled=true} \
--kubernetes-network-config elasticLoadBalancing={enabled=true} \
--access-config authenticationMode=API,bootstrapClusterCreatorAdminPermissions=trueIf you’d rather use eksctl, the equivalent is a ClusterConfig file with autoModeConfig.enabled: true:
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: automode-demo
region: us-east-1
autoModeConfig:
enabled: true
nodePools: ["system", "general-purpose"]Run it with eksctl create cluster -f cluster.yaml. Either path takes roughly 12–15 minutes to reach an ACTIVE state — the control plane provisioning time is unchanged from a traditional EKS cluster; Auto Mode only changes what happens to the data plane afterward.
Step 3: Connect kubectl and Verify Cluster Access
aws eks update-kubeconfig --name automode-demo --region us-east-1
kubectl get nodes
kubectl cluster-infoExpect an empty node list at this point — Auto Mode doesn’t pre-provision any EC2 capacity. Nodes only appear once a pod requests scheduling and there’s nothing available to run it on. That’s the core behavioral difference from Managed Node Groups, where you define a minimum node count up front.
Step 4: Inspect the Built-In NodeClass and NodePools
Auto Mode installs two Kubernetes custom resources automatically, using the same API groups as open-source Karpenter: NodePool objects (karpenter.sh/v1) that define which workloads can trigger scaling and what instance types are eligible, and a default NodeClass (eks.amazonaws.com/v1) that defines the AMI family, subnets, and security groups nodes use.
kubectl get nodepools
# NAME NODECLASS
# system default
# general-purpose default
kubectl get nodeclasses
# NAME AMI FAMILY ROLE
# default Bottlerocket eks-automode-node-role
kubectl describe nodepool general-purposeThe system NodePool is reserved for cluster-critical add-ons like CoreDNS and the Auto Mode controllers themselves; application workloads should target general-purpose or a custom NodePool you define later in Step 9.
Step 5: Deploy Your First Workload
Apply a standard Deployment. Nothing about the manifest itself changes for Auto Mode — the difference is entirely in what happens behind the scenes when the scheduler can’t place the pod.
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-api
spec:
replicas: 3
selector:
matchLabels: {app: demo-api}
template:
metadata:
labels: {app: demo-api}
spec:
containers:
- name: demo-api
image: public.ecr.aws/nginx/nginx:latest
resources:
requests: {cpu: "250m", memory: "256Mi"}
limits: {cpu: "500m", memory: "512Mi"}
ports:
- containerPort: 80kubectl apply -f demo-api.yaml
kubectl get pods -w
kubectl get nodes -wWatch both commands in separate terminals. Within roughly 60–90 seconds of applying the manifest, a new node running Bottlerocket appears, sized to fit the three replicas’ combined CPU and memory requests, and the pods transition from Pending to Running without you having touched an Auto Scaling Group.
Step 6: Expose the App With an Auto Mode-Managed Load Balancer
Because --kubernetes-network-config elasticLoadBalancing={enabled=true} was set at cluster creation, a Service of type LoadBalancer is enough — Auto Mode provisions the ALB or NLB itself.
apiVersion: v1
kind: Service
metadata:
name: demo-api-svc
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
spec:
type: LoadBalancer
selector: {app: demo-api}
ports:
- port: 80
targetPort: 80kubectl apply -f demo-api-svc.yaml
kubectl get svc demo-api-svc -w
# EXTERNAL-IP column populates with a *.elb.amazonaws.com hostname in 2-3 minutesNo AWS Load Balancer Controller pod, no IAM OIDC federation setup, no Helm chart — the controller logic runs as a managed part of the EKS control plane instead of as a pod inside your cluster.
Step 7: Add Persistent Storage
Auto Mode ships a default storage class, typically named auto-ebs-sc, backed by gp3 EBS volumes. A PersistentVolumeClaim against it triggers automatic volume provisioning without a manually installed EBS CSI driver add-on.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: demo-api-data
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: auto-ebs-sc
resources:
requests: {storage: 10Gi}Apply it, then confirm binding with kubectl get pvc demo-api-data — the status should move to Bound within seconds, and kubectl get pv will show a matching EBS-backed PersistentVolume.
Step 8: Test Autoscaling Under Load
Scale the Deployment up sharply and watch Auto Mode react in real time.
kubectl scale deployment demo-api --replicas=40
kubectl get nodes -w
kubectl top nodesAuto Mode’s Karpenter-based provisioner batches pending pods and launches the smallest set of instance types that satisfies them, rather than adding capacity one pod at a time. Scale back down (kubectl scale deployment demo-api --replicas=3) and idle nodes drain and terminate automatically after a short consolidation delay, typically within a few minutes, which is the mechanism that keeps Auto Mode cost-competitive against a statically sized Managed Node Group.
Step 9: Add a Custom NodePool for GPU or Spot Instances
The default general-purpose NodePool won’t schedule GPU workloads or use Spot capacity. Define a custom NodePool using the same Karpenter NodePool CRD already familiar to open-source Karpenter users, scoped to a specific capacity type and instance family.
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu-spot
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot"]
- key: node.kubernetes.io/instance-type
operator: In
values: ["g5.xlarge", "g5.2xlarge"]
limits:
cpu: "64"
disruption:
consolidationPolicy: WhenEmptyOrUnderutilizedApply it with kubectl apply -f gpu-spot-nodepool.yaml, then target it from a pod’s node selector (karpenter.sh/nodepool: gpu-spot) or a taint/toleration pair. Because Spot instances carry AWS’s standard interruption risk, pair this NodePool with a PodDisruptionBudget for anything beyond batch or stateless inference workloads.
Step 10: Migrate an Existing Cluster to Auto Mode
You cannot flip Auto Mode on for a cluster that was created without it via a single command — AWS requires the compute, storage, and networking config blocks to be set explicitly, either at creation or through an update API call on an existing cluster.
aws eks update-cluster-config \
--name existing-cluster \
--compute-config enabled=true,nodeRoleArn=arn:aws:iam::<ACCOUNT_ID>:role/eks-automode-node-role,nodePools=system,general-purpose \
--storage-config blockStorage={enabled=true} \
--kubernetes-network-config elasticLoadBalancing={enabled=true}Enabling Auto Mode on an existing cluster does not touch your current Managed Node Groups or self-hosted Karpenter setup — both continue running side by side with the new Auto Mode NodePools. The safe migration path is to cordon and drain existing nodes gradually (kubectl drain <node> --ignore-daemonsets) while new workloads land on Auto Mode capacity, then delete the old node groups once nothing is left scheduled on them. If your cluster already uses a self-hosted Karpenter install, uninstall its Helm release and delete its NodePool/NodeClass objects before Auto Mode takes over, to avoid two provisioners competing for the same pending pods.
Budget at least one full maintenance window per environment for this migration, and stage it lowest-risk-first: dev, then staging, then production, each separated by enough time to confirm the previous environment’s Auto Mode NodePools are consolidating correctly and the application’s readiness and liveness probes tolerate the new node churn pattern. Keep the old node group’s Auto Scaling Group at a minimum of one instance until the migration is fully validated in production — scaling it to zero immediately removes your rollback path if an Auto Mode NodePool misconfiguration surfaces under real traffic. Once you’re confident, delete the old node group with eksctl delete nodegroup (or the equivalent Terraform resource removal) and drop the now-unused node IAM role and its instance profile.
Step 11: Provision Everything With Terraform
For teams that manage infrastructure as code, the aws_eks_cluster resource accepts the same compute, storage, and networking configuration blocks as the CLI. This snippet builds on the pattern used in a standard Terraform-on-AWS setup.
resource "aws_eks_cluster" "automode_demo" {
name = "automode-demo"
role_arn = aws_iam_role.cluster_role.arn
version = "1.33"
vpc_config {
subnet_ids = var.subnet_ids
}
compute_config {
enabled = true
node_pools = ["system", "general-purpose"]
node_role_arn = aws_iam_role.node_role.arn
}
storage_config {
block_storage {
enabled = true
}
}
kubernetes_network_config {
elastic_load_balancing {
enabled = true
}
}
access_config {
authentication_mode = "API"
bootstrap_cluster_creator_admin_permissions = true
}
}Run terraform init, then terraform plan and terraform apply. Pin the Kubernetes version field explicitly in production — omitting it lets AWS default to whatever the current latest supported version is, which can shift between applies.
Step 12: Clean Up to Avoid Ongoing Charges
Delete workloads before deleting the cluster so Auto Mode terminates its provisioned nodes and load balancers cleanly, rather than leaving orphaned EC2 or ELB resources billing after the cluster is gone.
kubectl delete svc demo-api-svc
kubectl delete deployment demo-api
kubectl delete pvc demo-api-data
eksctl delete cluster --name automode-demo --region us-east-1
# or: aws eks delete-cluster --name automode-demoConfirm in the EC2 and EBS consoles that no volumes or instances tagged with the cluster name remain — Auto Mode generally cleans these up within a few minutes of the delete call, but it’s worth a manual check before closing the AWS Billing dashboard for the month.
Complete Working Project: A Node.js API End-to-End
Putting every step together, here’s a minimal but complete project layout you can adapt directly.
Project Structure
eks-automode-demo/
├── terraform/
│ ├── main.tf # aws_eks_cluster with Auto Mode config
│ ├── iam.tf # cluster + node IAM roles and policies
│ └── variables.tf
├── app/
│ ├── server.js # Express API, health check on /healthz
│ ├── package.json
│ └── Dockerfile
└── k8s/
├── deployment.yaml
├── service.yaml
├── pvc.yaml
└── gpu-spot-nodepool.yamlMinimal Express Server
const express = require("express");
const app = express();
app.get("/healthz", (req, res) => res.status(200).send("ok"));
app.get("/", (req, res) => res.json({ node: process.env.HOSTNAME }));
app.listen(80, () => console.log("listening on 80"));Build and push the image to Amazon ECR, swap the image: field in deployment.yaml from Step 5 to your ECR URI, then apply everything in order: terraform apply in terraform/, aws eks update-kubeconfig, and kubectl apply -f k8s/. Within a few minutes you have a load-balanced, autoscaling, persistently-storaged API running on infrastructure you never sized by hand.
A minimal Dockerfile keeps the image small enough that new Auto Mode nodes can pull and start it quickly, which matters more here than on a static node group since a slow image pull directly adds to the time a pod spends Pending while a fresh node boots:
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY server.js ./
EXPOSE 80
CMD ["node", "server.js"]Push it with docker build -t <ecr-repo-uri>:latest . && docker push <ecr-repo-uri>:latest, then wire the same URI into both deployment.yaml and any CI pipeline you later add on top. Because the whole stack — Terraform, Kubernetes manifests, and application code — lives in one repository, a single git clone is enough for a new engineer to reproduce the entire environment from scratch, which is the point of treating the cluster as a genuinely complete, reproducible project rather than a one-off console click-through.
Monitoring and Observability for Auto Mode Clusters
Because you can’t SSH into an Auto Mode node to check dmesg or a kubelet log by hand, observability tooling carries more of the debugging load than it does on a self-managed cluster. CloudWatch Container Insights is the fastest path to node- and pod-level metrics without deploying anything extra, and it understands Auto Mode’s managed NodePools out of the box.
aws eks update-cluster-config \
--name automode-demo \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
# Enable Container Insights (creates the CloudWatch agent + Fluent Bit DaemonSet)
aws eks create-addon --cluster-name automode-demo \
--addon-name amazon-cloudwatch-observabilityOnce enabled, CloudWatch surfaces per-NodePool CPU and memory utilization, which is the fastest way to confirm whether consolidation is actually happening or whether a stuck PodDisruptionBudget is holding idle nodes open (see the troubleshooting table below). For teams already standardized on Prometheus and Grafana, the managed Amazon Managed Service for Prometheus works the same way against Auto Mode nodes as it does against any other EKS compute mode — install the ADOT collector as a DaemonSet targeting the system NodePool specifically, since that’s the one guaranteed to stay running. Set a CloudWatch alarm on the count of nodes in the general-purpose NodePool over a rolling 24-hour window; a steadily climbing baseline, rather than a spiky one, is usually the earliest signal that consolidation isn’t reclaiming capacity the way Step 8 described.
Understanding EKS Auto Mode Pricing (With a Real Cost Example)
Auto Mode compute is billed as the standard EC2 On-Demand (or Spot) rate for the instance type chosen, plus an Auto Mode management fee layered on top, plus the standard $0.10-per-hour EKS control plane fee that applies to every cluster regardless of compute mode. Both EC2 and the management fee are billed per second with a one-minute minimum, matching normal EC2 billing granularity.
According to a 2026 EKS pricing breakdown from CloudZero, the Auto Mode management charge runs roughly 10–12% on top of the underlying EC2 On-Demand price. For an m5.large in us-east-1 priced at $0.096/hour On-Demand, that works out to an Auto Mode fee of roughly $0.01152/hour — a small enough delta per instance that it’s easy to overlook until it’s multiplied across a large fleet. AWS also cut GPU-specific management fees on July 1, 2026: G-series Auto Mode fees dropped 35%, and P-series plus AWS Trainium fees dropped 60%, a meaningful discount for teams running ML inference or training on Auto Mode nodes.
| Instance family | EC2 On-Demand baseline | Auto Mode management fee | GPU fee change (from July 1, 2026) |
|---|---|---|---|
| General purpose (M, C, R series) | Standard On-Demand rate | ~10–12% of EC2 price | Not applicable |
| G-series GPU | Standard On-Demand rate | Reduced management fee | -35% |
| P-series GPU | Standard On-Demand rate | Reduced management fee | -60% |
| AWS Trainium | Standard On-Demand rate | Reduced management fee | -60% |
Cloudburn’s 2026 EKS pricing analysis flags a scenario where an unmonitored medium-size Auto Mode environment reached roughly $438 per month once control plane fees, the management surcharge, idle general-purpose nodes, and unattached EBS volumes from deleted PVCs were all added up — a reminder that Auto Mode’s convenience doesn’t remove the need for the cost-tracking practices covered in the Kubecost setup guide and general AWS Cost Explorer and budgets tutorial. Setting NodePool limits (as shown in Step 9) and enabling consolidation are the two levers with the biggest effect on the monthly bill.
6 Common Pitfalls When Adopting EKS Auto Mode
- Forgetting the extra cluster IAM policies. A cluster role with only
AmazonEKSClusterPolicyattached will fail to create an Auto Mode cluster or silently fail to provision nodes. All four Auto Mode-specific policies from Step 1 are required, not optional add-ons. - Running two provisioners at once during migration. Enabling Auto Mode on a cluster that still has a self-hosted Karpenter release installed causes both controllers to compete for the same pending pods, sometimes launching duplicate nodes. Remove the old provisioner before or immediately after enabling Auto Mode.
- Assuming Auto Mode nodes accept SSH or custom AMIs. Auto Mode nodes run a fixed Bottlerocket image managed by AWS; you cannot SSH in or swap the AMI the way you could with a self-managed node group. Debugging happens through
kubectl exec, container logs, and CloudWatch, not the node itself. - No NodePool
limitsset. Without a CPU or instance-count ceiling on a custom NodePool (see Step 9), a runaway Deployment or a misconfigured HPA can scale Auto Mode compute far beyond what was intended, and the bill follows. - Leaving PVCs behind after deleting workloads. The default reclaim policy on Auto Mode’s
auto-ebs-scstorage class deletes the underlying EBS volume when the PVC is deleted, but volumes tied to PVCs that were never deleted keep billing indefinitely — check for orphaned volumes as part of the cleanup step, not just orphaned nodes. - Skipping resource requests on pods. Auto Mode’s provisioner sizes nodes based on the CPU and memory a pod requests, not what it actually uses. A Deployment with no
resources.requestsblock gets treated as effectively weightless for scheduling purposes, which either crowds too many pods onto one node (causing throttling) or, if a default LimitRange forces a high request, wastes capacity on an oversized node. Set requests deliberately for every workload before relying on Auto Mode’s bin-packing.
Troubleshooting: 8 Common Issues and Fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Cluster creation fails with an IAM permissions error | Missing one of the four Auto Mode cluster policies | Re-run the attach-role-policy loop from Step 1 and confirm with aws iam list-attached-role-policies |
Pods stay Pending indefinitely | No NodePool matches the pod’s requirements, or a NodePool limits ceiling was reached | Run kubectl describe pod to read scheduling events, then check kubectl get nodepool -o yaml for hit limits |
LoadBalancer Service never gets an EXTERNAL-IP | Elastic load balancing was not enabled in kubernetes_network_config at cluster creation | Run the update-cluster-config command from Step 10 to enable it retroactively |
PVC stuck in Pending | Storage config wasn’t enabled, or the wrong storageClassName was used | Confirm with kubectl get storageclass that auto-ebs-sc exists, and reference it exactly in the PVC spec |
| Nodes never scale down after traffic drops | Consolidation policy left at default, or a PodDisruptionBudget is blocking eviction | Set consolidationPolicy: WhenEmptyOrUnderutilized on the NodePool and review PDB minAvailable values |
| GPU pods fail to schedule | No custom NodePool targets GPU instance types (the default general-purpose pool excludes them) | Apply a NodePool like the one in Step 9 scoped to g5.* or similar GPU families |
| Duplicate nodes appear for one pending pod | Self-hosted Karpenter and Auto Mode running simultaneously | Uninstall the self-hosted Karpenter Helm release and delete its NodePool/NodeClass CRDs |
| Monthly bill higher than expected | Idle nodes not consolidating, or orphaned EBS volumes from deleted PVCs | Audit with Cost Explorer or Kubecost, and confirm PVC reclaim policy is Delete |
Advanced Tips for Production Clusters
Separate NodePools by workload tier rather than relying solely on the default general-purpose pool — a dedicated NodePool with a taint for latency-sensitive services keeps batch jobs from ever landing on the same instances and causing noisy-neighbor CPU contention. Combine Spot-backed NodePools with On-Demand fallback by defining two NodePools with different capacity-type requirements and weighting your Deployment’s pod anti-affinity rules toward the Spot pool first; Auto Mode’s provisioner respects the ordering the same way self-hosted Karpenter does.
For clusters running mixed CPU architectures, add a kubernetes.io/arch requirement to a custom NodePool to steer specific workloads toward Graviton-based instance types, which typically undercut equivalent x86 instances on price — a pattern that pairs naturally with the strategy covered in the Graviton5 migration guide. Finally, treat Auto Mode’s IAM roles the same way you’d treat any privileged service role: scope the node role down further with a permissions boundary if your compliance posture requires it, and review the hardening practices in the Kubernetes security hardening tutorial, since Auto Mode changes who patches the OS but doesn’t change your responsibility for workload-level RBAC, network policies, and secrets management.
Kubernetes version upgrades behave differently under Auto Mode, too. Because AWS controls the node AMI, upgrading a cluster’s Kubernetes version no longer requires you to also cut a new node group with an updated AMI and roll traffic over manually — Auto Mode replaces nodes with new Bottlerocket images matching the upgraded control plane automatically during the standard aws eks update-cluster-version flow. That said, still stagger control-plane upgrades across environments and watch the node replacement process closely the first time, since a Bottlerocket image change can occasionally surface container runtime behavior differences (cgroup v2 defaults, for example) that a prior AMI masked. Finally, set resource requests deliberately rather than leaving them unset — Auto Mode’s bin-packing decisions are only as good as the numbers pods report, and unset requests push the provisioner toward oversized nodes as a safety margin.
Frequently Asked Questions
Is EKS Auto Mode more expensive than self-hosted Karpenter?
Per instance-hour, yes — Auto Mode adds a management fee of roughly 10–12% over the EC2 On-Demand price, while self-hosted Karpenter has no comparable surcharge beyond the EC2 cost itself. The trade-off is engineering time: self-hosted Karpenter requires you to install, upgrade, and secure the controller, plus separately install the AWS Load Balancer Controller and EBS CSI driver, all of which Auto Mode bundles in.
Can I SSH into an EKS Auto Mode node?
No. Auto Mode nodes run a fixed Bottlerocket AMI managed entirely by AWS, with no SSH access exposed. Debugging happens through kubectl exec into containers, container logs, and CloudWatch rather than direct node access.
Does EKS Auto Mode support GPU workloads?
Yes, but not through the default general-purpose NodePool. You need a custom NodePool that explicitly lists GPU instance types, as shown in Step 9. AWS reduced Auto Mode’s GPU management fees on July 1, 2026 — G-series by 35% and P-series plus Trainium by 60% — making GPU workloads on Auto Mode meaningfully cheaper than they were previously.
Can I enable Auto Mode on a cluster I already created without it?
Yes, using aws eks update-cluster-config with the compute, storage, and networking blocks set, as shown in Step 10. Existing Managed Node Groups keep running alongside the new Auto Mode NodePools; you migrate workloads over by draining old nodes gradually.
What operating system do Auto Mode nodes run?
Bottlerocket, AWS’s minimal, container-optimized Linux distribution. It has no package manager and no shell access by design, which is part of why Auto Mode can patch and rotate nodes automatically without breaking custom configuration you might otherwise have layered onto a general-purpose AMI. See AWS’s core EKS documentation for how this fits into the broader EKS architecture.
Does Auto Mode work with Terraform, or only the AWS CLI and eksctl?
Terraform’s aws_eks_cluster resource supports the same compute_config, storage_config, and kubernetes_network_config blocks used by the CLI, as shown in Step 11. All three interfaces call the same underlying EKS API, so the resulting cluster behaves identically regardless of which tool created it.
Will Auto Mode nodes scale to zero when there’s no traffic?
Application nodes in a custom or general-purpose NodePool can scale to zero once no pods require them, provided consolidationPolicy is set to allow it. The system NodePool that runs cluster-critical add-ons like CoreDNS will not scale to zero, since the cluster needs it running at all times.
How is Auto Mode different from AWS Fargate for EKS?
Fargate runs each pod in its own isolated microVM with no visible EC2 node at all, billed per vCPU and GB of memory requested by the pod. Auto Mode still runs pods on shared EC2 instances — you can see and describe the nodes — but AWS handles provisioning, patching, and scaling of those instances instead of you managing an Auto Scaling Group. Fargate tends to suit spiky, low-density workloads; Auto Mode suits general-purpose fleets where bin-packing multiple pods per node meaningfully reduces cost.
Can I use Kubecost or third-party FinOps tools with Auto Mode?
Yes. Auto Mode nodes still appear as standard EC2 instances tagged with cluster and NodePool metadata, so cost-allocation tools that read EC2 tags and the Kubernetes API — including Kubecost — attribute Auto Mode spend the same way they would attribute Managed Node Group spend. The one addition worth tracking separately is the Auto Mode management fee line item itself, which shows up in Cost Explorer under the EKS service rather than under EC2, so a cost dashboard built purely around EC2 tags can undercount total Auto Mode spend unless it’s configured to include that line.
Does EKS Auto Mode support Windows containers?
No. Auto Mode’s built-in NodeClass provisions Bottlerocket nodes, which run Linux containers only. Clusters that need Windows node support still require a traditional Windows-based Managed Node Group running alongside Auto Mode’s Linux NodePools; the two can coexist in the same cluster, but Windows workloads won’t benefit from Auto Mode’s automated provisioning and patching.
Related Coverage
- Kubernetes on AWS EKS Setup: 12 Steps, 100 Min [2026]
- How to Set Up Karpenter for EKS Autoscaling: 12 Steps [2026]
- AWS Systems Manager Azure Setup: 12 Steps, 90 Min [2026]
- Migrate AWS App Runner to ECS Express Mode: 12 Steps [2026]
- AWS CloudFormation Express Mode: 12 Steps, 4x Faster [2026]
