What EKS Auto Mode is
EKS Auto Mode, generally available on December 1, 2024 , shifts more Kubernetes infrastructure responsibility from you to AWS. You still run an EKS cluster in your AWS account, and your workloads still use the Kubernetes API, but AWS takes over much of the compute, storage, networking, node lifecycle, and core add-on management that platform teams usually wire together themselves.
For compute, Auto Mode uses Karpenter-style provisioning under the hood. When pods are unschedulable, Auto Mode provisions nodes that fit the workload’s requirements: instance family, size, architecture, capacity type, and availability zone. When capacity is no longer useful, it can consolidate and terminate nodes.
The important framing is this: Auto Mode is not “EKS without nodes.” It is EKS where AWS manages the node lifecycle more aggressively. You own the workloads, their scheduling requirements, their disruption behavior, and the operational consequences of those choices. AWS owns more of the infrastructure plumbing.
What it replaces
Before Auto Mode, running EKS in production usually meant choosing and operating several layers yourself:
Managed node groups: You chose instance types, defined scaling ranges, managed AMI updates, handled node draining, and configured Cluster Autoscaler or another scaling mechanism.
Self-managed Karpenter: More flexible than managed node groups, but you owned the Karpenter controller, IAM, NodePools, EC2NodeClasses, disruption settings, upgrades, and failure modes.
Fargate: AWS-managed compute per pod, with no node management, but no DaemonSets, a narrower workload compatibility envelope, and a different cost model.
EKS Auto Mode replaces a large part of that platform assembly with a managed model: declare workload intent and high-level compute constraints; AWS provisions and manages the EC2 instances behind it.
How it works in practice
You create or update an EKS cluster with Auto Mode enabled. The default setup can use AWS-managed built-in node pools. If you need more control, you create a NodeClass for Auto Mode infrastructure settings and a Karpenter NodePool for workload-facing scheduling constraints.
# NodeClass: EKS Auto Mode infrastructure settings for managed EC2 nodes.
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
aws:eks:cluster-name: prod-eks
ephemeralStorage:
size: "100Gi"# NodePool: workload-facing constraints for nodes that Auto Mode may provision.
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: general-purpose
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: private-compute
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["on-demand", "spot"]
- key: kubernetes.io/arch
operator: In
values: ["amd64", "arm64"]
- key: eks.amazonaws.com/instance-category
operator: In
values: ["c", "m", "r"]
limits:
cpu: "1000"
memory: 1000Gi
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 1mThose API groups are the Auto Mode-specific split documented by AWS: apiVersion: eks.amazonaws.com/v1, kind: NodeClass for Auto Mode node infrastructure, and apiVersion: karpenter.sh/v1, kind: NodePool for scheduling and capacity constraints.
The NodeClass is where you express AWS infrastructure placement and node-level defaults. The NodePool is where you express what kind of capacity is acceptable for workloads. Do not copy a self-managed Karpenter EC2NodeClass into Auto Mode; Auto Mode uses its own NodeClass API.
Auto Mode provisions nodes when pods are pending, consolidates when nodes are underutilized, and replaces nodes during maintenance or scale-down. AMI and node lifecycle updates are handled by AWS. AWS says Auto Mode AMIs are generally released weekly with CVE and security fixes, and Auto Mode nodes have a maximum lifetime of 21 days, which you can reduce. Your application still has to tolerate the disruption: a bad PodDisruptionBudget, strict affinity rule, or singleton stateful workload can still block or degrade a replacement.
Built-in components are managed differently than in a classic EKS build. AWS lists pod networking, service networking, cluster DNS, autoscaling, block storage, load balancer controller, Pod Identity agent, and node monitoring agent as Auto Mode capabilities. With Auto Mode compute, common add-ons such as Amazon VPC CNI, kube-proxy, CoreDNS, Amazon EBS CSI Driver, and EKS Pod Identity Agent become redundant for Auto Mode nodes, and the relevant controllers can run on AWS-owned infrastructure rather than as visible pods in your account. You can still install AWS Load Balancer Controller in an Auto Mode cluster when you need both models during migration, but AWS does not support directly migrating existing load balancers from AWS Load Balancer Controller to Auto Mode; use IngressClass or loadBalancerClass boundaries and plan blue-green migration. Treat this as a change in ownership, not as a reason to skip validation.
The workload support matrix is broader than Fargate, but not identical to self-managed nodes:
Capability Auto Mode status EC2 Spot Supported through karpenter.sh/capacity-type requirements such as spot, on-demand, and reserved Graviton / arm64 Supported through kubernetes.io/arch: arm64 and supported Graviton instance families GPU / accelerators Supported for documented accelerated families; Auto Mode manages NVIDIA, Trainium, and Inferentia drivers/device plugins for supported instance types Windows nodes Not supported DaemonSets Supported as Kubernetes DaemonSets, but host-level assumptions must be validated against locked-down managed nodes
What you gain
Reduced operational surface. Node group management, AMI lifecycle, Cluster Autoscaler tuning, Karpenter controller upgrades, and a chunk of add-on wiring move out of your day-to-day scope.
Better provisioning shape by default. Dynamic provisioning is usually a better fit than fixed node group shapes. You get nodes that more closely match actual pod requirements instead of trying to pre-plan a small set of instance types.
Automatic node patching. AWS manages the node image and replacement flow. That reduces toil, but it also means your workloads need disruption policies that let AWS replace nodes safely.
Faster cluster bootstrapping. A new Auto Mode cluster can get to a usable production baseline faster than a hand-assembled EKS cluster with node groups, autoscaling, networking add-ons, storage drivers, and load balancer controllers.
Native Spot integration. Auto Mode can use Spot capacity through NodePool requirements, but you still need workload-level interruption tolerance: replicas, budgets, graceful shutdown, and queue semantics where relevant.
What you give up
Node-level access. Auto Mode nodes are intentionally locked down compared with traditional self-managed nodes. If your incident response process assumes SSH, SSM, manual package inspection, or ad hoc host changes, it needs to change.
Custom AMIs. You cannot treat the node image as your own artifact. AWS determines the operating system and AMI for Auto Mode managed instances; you cannot directly access the instance or install software on it. If your organization requires internally built, hardened, or certified AMIs, Auto Mode is likely blocked.
Unrestricted host agents. Kubernetes DaemonSets are supported, but they are the sharp edge. Some node agents work; others do not. Anything that assumes privileged host access, custom kernel modules, hostPath writes, IMDS access without hostNetwork, or low-level runtime integration needs a proof of compatibility.
Less tuning surface. You give up direct control over kubelet flags, container runtime configuration, bootstrap scripts, and arbitrary node setup. That is the point of the product, but it is also the boundary.
Different cost visibility. Managed node groups make capacity easier to reason about because you chose it up front. Auto Mode changes capacity dynamically, so cost control moves toward budgets, labels, reports, and workload-level resource hygiene .
EKS Auto Mode vs managed node groups vs Fargate
Auto Mode Managed Node Groups Fargate Node management AWS manages node lifecycle Shared: AWS manages the group primitive, you manage capacity shape and many updates AWS-managed per-pod compute AMI updates Automatic through AWS-managed node replacement You schedule and operate rolling updates N/A Instance selection Dynamic through NodePools You choose instance types and scaling ranges Not exposed Custom AMIs No; AWS determines the AMI Yes No DaemonSets Supported, but validate host-access assumptions Yes No SSH / node access Restricted Usually available if you enable it No Spot support Yes, through capacity-type requirements Yes, with node group or Karpenter design No; Amazon EKS does not support Fargate Spot Cost model EKS control plane + EC2 + EKS Auto Mode fee EKS control plane + EC2 EKS control plane + Fargate pod pricing Operational burden Low for nodes, medium for workload compatibility Medium Low for nodes, medium for compatibility Right for Default candidate for teams that do not need node customization Regulated/custom node environments and mature platform teams Workloads that fit Fargate’s restrictions and want per-pod isolation Hidden constraints / gotchas AWS controls node image and lifecycle; DaemonSets, privileged pods, hostPath, PDBs, topology rules, and node agents can block migration You still own AMI drift, autoscaler tuning, disruption handling, and capacity fragmentation No DaemonSets, limited host-level integrations, different networking/storage constraints, and less flexibility for mixed workload shapes
The Auto Mode pricing
Do not model Auto Mode as “EC2 plus a generic percentage” unless you have pulled the actual rate for your region and instance mix. The official structure is:
Total EKS Auto Mode cluster cost =
EKS control plane cost
+ normal EC2 cost for instances launched and managed by Auto Mode
+ EKS Auto Mode management fee on those managed EC2 instances
+ normal surrounding AWS costs: EBS, load balancers, data transfer, CloudWatch, etc.
EKS Auto Mode management fee =
sum of Auto Mode-managed instance runtime
x the regional EKS Auto Mode management rate for each EC2 instance typeThe EKS Auto Mode fee is applied to the EC2 instances that Auto Mode launches and manages. It is billed in addition to the normal EC2 charge and in addition to the EKS control plane charge. AWS bills the Auto Mode fee per second with a one-minute minimum, and the charge is independent of whether the underlying EC2 capacity is On-Demand, Spot, covered by Reserved Instances, or covered by Compute Savings Plans.
Do not treat the fee as a contractual flat percentage. The official pricing page describes it as a management fee that varies by EC2 instance type, and AWS pricing data is regional. The public pricing example for US West (Oregon) shows c6a.2xlarge at $0.306/hour for EC2 plus $0.03672/hour for Auto Mode, c6a.4xlarge at $0.612/hour plus $0.07344/hour, m5a.2xlarge at $0.344/hour plus $0.04128/hour, and m5a.xlarge at $0.172/hour plus $0.02064/hour. Those examples equal 12% of the listed On-Demand EC2 rate, but the safe formula for real planning is: sum(instance-hours by instance type and region x published Auto Mode management rate).
The practical cost question is not “is there a premium?” There is. The useful question is whether the premium is lower than the engineering time, incident risk, and opportunity cost of operating node lifecycle yourself.
For small teams, the answer may be yes even if the raw bill increases. For high-scale, cost-sensitive platforms, the answer needs real data: compare current EC2 waste, bin-packing efficiency, Spot usage, interruption rate, and platform maintenance time against an Auto Mode pilot.
When to use EKS Auto Mode
Use Auto Mode if:
You run EKS on AWS and do not have a hard requirement to manage nodes yourself
You do not require custom AMIs or custom node bootstrap logic
You want to reduce the operations surface for node lifecycle management
You want Karpenter-like provisioning without operating Karpenter yourself
Your workloads are mostly stateless or disruption-tolerant
Your observability, security, and storage agents are compatible with Auto Mode
Stick with managed node groups if:
Your organization requires internally certified or hardened AMIs
You need specific kernel configuration, kubelet flags, bootstrap scripts, or host packages
You depend on privileged DaemonSets or host-level security tooling that Auto Mode cannot support
You are in a regulated environment where the node image supply chain must be owned internally
Your platform team already operates Karpenter well and values the extra control
Use Fargate if:
You specifically want per-pod compute isolation
Your workload does not need DaemonSets or host-level integrations
You accept Fargate’s scheduling, networking, storage, and observability constraints
You want to avoid managing EC2 capacity entirely for a narrow class of workloads
Migration from managed node groups
Migrating an existing cluster to Auto Mode is supported, but it is not a one-command operational migration. AWS supports enabling Auto Mode on existing clusters, but you must update the cluster IAM role permissions and trust policy, enable compute, block storage, and load balancing capabilities together, and meet required add-on versions when those add-ons are installed. AWS also calls out unsupported direct migrations for EBS volumes from the standard EBS CSI provisioner to the Auto Mode EBS CSI provisioner, existing load balancers from AWS Load Balancer Controller to Auto Mode, and clusters using alternative CNIs or other unsupported networking configurations. A conservative path looks like this:
Enable Auto Mode on a non-production cluster running Kubernetes 1.29 or greater.
Inventory workloads by scheduling assumptions: node selectors, affinities, tolerations, topology spread, PDBs, privileged mode, hostPath, local storage, and DaemonSet dependencies.
Create or select the relevant Auto Mode NodeClass and NodePool resources.
Move a low-risk namespace first by changing selectors, tolerations, or labels so pods land on Auto Mode nodes.
Watch scheduling, replacement, load balancer behavior, persistent volume provisioning, logging, metrics, and security events.
T
