Running EKS well has always meant running a lot of things besides your applications: node groups and their AMIs, a cluster autoscaler or Karpenter, the VPC CNI, CoreDNS, kube-proxy, the EBS CSI driver, the AWS Load Balancer Controller, and keeping all of them compatible through Kubernetes upgrades. EKS Auto Mode, generally available since December 2024, moves most of that list to AWS.

We migrated two production clusters to Auto Mode this year. This post describes what Auto Mode actually manages, what changes for the people operating the cluster, and the migration path that worked for us.

What Auto Mode manages

Area Without Auto Mode With Auto Mode
Compute Managed node groups or self-managed Karpenter, AMIs, patching AWS-managed Karpenter-based provisioning, AWS-managed node AMIs
Networking VPC CNI add-on, kube-proxy, CoreDNS add-ons Built into managed nodes
Load balancing AWS Load Balancer Controller installed by you Built-in controller for Services and Ingress
Block storage EBS CSI driver add-on Built-in EBS provisioner
Pod identity Pod Identity agent add-on Built in
Node lifecycle Your patching and replacement process Nodes have a maximum lifetime (21 days) and are replaced automatically

The managed components run outside your cluster, in AWS's control, so they do not appear as pods you can inspect or configure freely.

The building blocks you still configure

Auto Mode uses Karpenter concepts. You keep control through two resources:

  • NodePool (karpenter.sh/v1): which workloads land where, instance requirements, limits, disruption settings.
  • NodeClass (eks.amazonaws.com/v1): AWS-specific node settings such as subnets, security groups, ephemeral storage and network policy behaviour. It replaces Karpenter's EC2NodeClass.

Auto Mode ships with built-in NodePools (general-purpose and system). We disabled the built-in general pool and defined our own, to keep our instance families and capacity type choices:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: private-nodes
spec:
  subnetSelectorTerms:
    - tags:
        kubernetes.io/role/internal-elb: "1"
  securityGroupSelectorTerms:
    - tags:
        eks-node-sg: "prod"
  ephemeralStorage:
    size: 80Gi
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: private-nodes
      requirements:
        - key: eks.amazonaws.com/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand", "spot"]
  limits:
    cpu: "800"
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 10m
    budgets:
      - nodes: "10%"

Note the label prefix: Auto Mode uses eks.amazonaws.com/... labels for instance attributes where self-managed Karpenter on AWS uses karpenter.k8s.aws/.... Workloads with node selectors or affinities on the old labels need updating.

What changes for operators

You cannot log in to nodes

Auto Mode nodes run a locked-down operating system without SSH or SSM shell access. Debugging moves to kubectl debug node/... and node logs collection through the NodeDiagnostic resource or the console. For teams used to SSHing into nodes, this is the biggest cultural change.

Nodes are replaced regularly

Nodes have a maximum lifetime and are replaced with updated images automatically. That is good for security patching, but every workload must tolerate node replacement: PodDisruptionBudgets, graceful shutdown and enough replicas are no longer optional.

Fewer knobs

You cannot install a custom CNI, change kube-proxy mode, or run DaemonSets that require specific host access in all cases. Custom AMIs are not supported. Some advanced VPC CNI settings, such as custom networking with secondary CIDRs, are configured through the NodeClass instead, and not every option of the self-managed add-ons exists there.

Load balancer controller differences

The built-in load balancing uses its own IngressClass and Service annotations. Load balancers created by a self-managed AWS Load Balancer Controller are not adopted automatically. That has consequences for migration, below.

Pricing

Auto Mode adds a management fee on top of the EC2 price for instances it manages. For our clusters, the fee was roughly offset by removing the engineering time spent on node and add-on maintenance, but it is a real line item to evaluate.

How we migrated

Auto Mode can be enabled on an existing cluster, and Auto Mode nodes can run alongside managed node groups. That makes a gradual migration possible.

  1. Upgrade the cluster to a version supported by Auto Mode and update kubectl and eksctl or Terraform modules.
  2. Enable Auto Mode on the cluster with the compute, storage and load balancing capabilities, and the required IAM roles for the cluster and nodes.
  3. Create NodeClasses and NodePools matching existing node groups' constraints (subnets, security groups, instance families). Fix node selectors that use old labels.
  4. Move workloads by tainting and draining managed node groups one at a time. Pods reschedule onto Auto Mode nodes provisioned by the new NodePools. PDBs keep services available.
  5. Storage: new volumes need a StorageClass that uses the Auto Mode provisioner (ebs.csi.eks.amazonaws.com). Existing volumes created by the self-managed EBS CSI driver keep working while that driver is installed; we migrated stateful workloads by snapshot and restore into new PVCs during maintenance windows.
  6. Load balancers: for each Service or Ingress, we created a parallel one on the Auto Mode IngressClass, tested it, switched DNS with a low TTL, then removed the old one and finally the self-managed controller.
  7. Remove add-ons that Auto Mode replaces (VPC CNI, kube-proxy, CoreDNS, EBS CSI driver, Load Balancer Controller, Karpenter) once nothing depends on them.

The two clusters took four and six weeks of elapsed time, mostly spent on steps 5 and 6.

Who should consider it

Auto Mode fits teams that want Kubernetes but do not want to operate the plumbing, clusters with standard networking, and organisations that struggle to keep nodes patched. It fits less well where you need custom AMIs, kernel tuning, special CNIs, direct node access for compliance tooling, or very fine control of DaemonSets on the host.

Common mistakes

Mistake Effect Do this instead
Keeping node selectors on karpenter.k8s.aws/* labels Pods stay Pending on Auto Mode nodes Switch to eks.amazonaws.com/* labels
No PDBs before enabling Auto Mode Node replacements cause outages Add PDBs and graceful shutdown first
Expecting existing load balancers to be adopted Duplicate or orphaned load balancers Create new ones, switch DNS, delete old
Forgetting the StorageClass provisioner New PVCs never bind Use the Auto Mode EBS provisioner
Relying on SSH for debugging No access during incidents Practise kubectl debug node and node diagnostics

Key takeaways

  • Auto Mode moves node provisioning, core networking, load balancing and EBS storage to AWS.
  • You still control placement and node settings with NodePools and NodeClasses, using eks.amazonaws.com labels.
  • Nodes are locked down and replaced regularly, so workloads must tolerate disruption and debugging changes.
  • Load balancers and volumes are not adopted automatically; plan parallel creation and cutover.
  • Evaluate the management fee against the operational work it removes.

References