AWS EKS Auto Mode: Simplifying Kubernetes Management in Production

What is EKS Auto Mode?

EKS Auto Mode is a feature launched by AWS in November 2024 that radically transforms how you manage a Kubernetes cluster in production. With Auto Mode enabled, AWS automatically handles:

• Node lifecycle: provisioning, AMI updates, security patches, replacement of failed nodes
• Node scaling: Karpenter is natively integrated, nodes are provisioned and deprovisioned based on actual demand
• Networking: VPC CNI managed by AWS, automatic updates
• Storage: EBS CSI Driver managed by AWS, pre-configured default StorageClass
• Core add-ons: CoreDNS, kube-proxy, aws-load-balancer-controller included and updated by AWS

In short: your team no longer needs to manage node groups, AMIs, or Kubernetes add-ons. AWS handles them as a managed service.

What You No Longer Manage with Auto Mode

Here is the list of responsibilities you delegate to AWS with EKS Auto Mode:

• Amazon Linux 2023 AMI updates (security patches, kernel updates)
• Configuration and scaling of node groups / Karpenter NodePools
• Installation and updates of VPC CNI, CoreDNS, kube-proxy
• Installation and updates of EBS CSI Driver
• Management of node Security Groups
• Configuration of the AWS Load Balancer Controller

You retain control over: your workloads (Deployments, StatefulSets), your namespaces, your custom CRDs, your Ingress/Gateway config, and the Kubernetes version of the control plane.

Enabling EKS Auto Mode with Terraform

resource "aws_eks_cluster" "main" {
  name     = "production-cluster"
  version  = "1.31"
  role_arn = aws_iam_role.eks_cluster.arn

  vpc_config {
    subnet_ids              = var.private_subnet_ids
    endpoint_private_access = true
    endpoint_public_access  = false
  }

  # Enable EKS Auto Mode
  compute_config {
    enabled       = true
    node_pools    = ["general-purpose", "system"]
    node_role_arn = aws_iam_role.eks_node.arn
  }

  kubernetes_network_config {
    elastic_load_balancing {
      enabled = true
    }
  }

  storage_config {
    block_storage {
      enabled = true
    }
  }

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

# With Auto Mode, no need to manage node groups manually
# AWS automatically creates and manages nodes via Karpenter

NodeClass and NodePool: Karpenter Under the Hood

EKS Auto Mode uses Karpenter internally. You can customise scaling behaviour via the NodeClass and NodePool CRDs:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: default
spec:
  # EBS root volume configuration
  ephemeralStorage:
    size: "80Gi"
    iops: 3000
    throughput: 125
  # Other parameters (AMI, SG, subnet) managed by EKS Auto Mode

---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-purpose
spec:
  template:
    metadata:
      labels:
        billing-team: platform
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["m5.large", "m5.xlarge", "m6i.large", "m6i.xlarge",
                   "c5.large", "c5.xlarge", "r5.large"]
  limits:
    cpu: 1000
    memory: 4000Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Cost Implications

EKS Auto Mode has an additional cost compared to standard EKS: $0.10/hour per cluster in Auto Mode (approximately $72/month). This cost must be weighed against operational savings:

• Elimination of engineering hours spent on AMI updates and patches
• Reduction of incidents caused by outdated or misconfigured nodes
• Automatic cost optimisation via Karpenter consolidation (underutilised nodes replaced by smaller ones)
• Automatic use of Spot Instances with on-demand fallback

For most teams, the engineering time savings far exceed the $72/month overhead.

Current EKS Auto Mode Limitations

In 2026, EKS Auto Mode still has some limitations to be aware of:

• No GPU support: GPU nodes (p3, g4, inf) are not available in Auto Mode — use separate managed node groups for ML workloads
• No custom AMIs: you cannot use your own AMIs with pre-installed agents (Datadog agent, etc.)
• No coexisting manual managed node groups: Auto Mode manages all nodes; you cannot have some nodes in Auto Mode and some self-managed
• Limited regions: available in most AWS regions but not all — check availability in eu-west-1, eu-central-1

When to Use Auto Mode vs Self-Managed Nodes

Auto Mode is recommended for:

• New clusters without custom AMI requirements
• DevOps teams that want to reduce Kubernetes operational burden
• Standard application workloads (web APIs, microservices, batch jobs)
• Homogeneous dev/staging/prod environments

Keep self-managed nodes for:

• GPU/ML workloads (until GPU support is added)
• Use cases requiring custom agents on nodes (compliance, DLP)
• Very specific network configurations (multus, SR-IOV)

Migration from an Existing EKS Cluster

Migration to EKS Auto Mode is not an in-place migration — it requires creating a new cluster. The recommended procedure:

1. Create a new EKS cluster with Auto Mode enabled
2. Progressively migrate workloads via blue/green namespaces or a migration load balancer
3. Validate performance and stability on the new cluster
4. Switch DNS and production traffic over
5. Decommission the old cluster after a stabilisation period

Conclusion

EKS Auto Mode represents a significant evolution in AWS's philosophy for Kubernetes: moving from an infrastructure service (you manage nodes) to an application service (you manage workloads, AWS manages infrastructure). For teams spending too much time on node and add-on maintenance, Auto Mode is an opportunity to refocus effort on business value. Current limitations (no GPU, no custom AMIs) will progressively disappear as the service is updated.