View a markdown version of this page

Amazon EKS Auto Mode (managed option) - AWS Prescriptive Guidance
When to use Amazon EKS Auto ModeWhen to use self-managed KarpenterMigrating an existing cluster to Amazon EKS Auto ModeValidation after migration

Amazon EKS Auto Mode (managed option)

Amazon EKS Auto Mode (launched December 2024) automates compute management entirely — no Karpenter installation, no NodePool configuration, no autoscaler upgrades. AWS handles instance selection, Spot/On-Demand mixing, consolidation, and node patching automatically. EKS Auto Mode is best suited for teams without dedicated platform engineering capacity, or for dev/test environments where operational simplicity outweighs fine-grained cost control. It does not support separate NodePool configurations, custom disruption budgets, workload-specific taints, or explicit Spot/On-Demand ratio control.

  • Greenfield clusters: Get cost-optimal node provisioning out of the box without upfront tuning effort.

  • Lean teams: Reduce the platform engineering burden by letting AWS manage node lifecycle, instance selection, and patching decisions.

  • Homogeneous workloads: Standard web services and APIs that don't need dedicated GPU, Spark, or high-isolation node pools.

  • Simplicity-first environments: Accept slightly less granular control in exchange for zero operational overhead on node management.

For sample commands, see this GitHub repository to create a new cluster with Auto Mode or enable it on an existing cluster.

When to use self-managed Karpenter

  • You need separate NodePools per workload type (PDB-protected, non-PDB, GPU, Spark) with distinct cost strategies for each.

  • You require explicit control over disruption budgets, expiry periods, and termination grace periods.

  • Your Spot/On-Demand ratio must be governed by specific policies (for example, minimum 20% On-Demand for production, 100% Spot for batch).

  • You run Spark or batch workloads needing consolidationPolicy: WhenEmpty to avoid disrupting in-progress jobs.

  • Regulatory or compliance requirements mandate explicit instance family selection and audit trails for node provisioning decisions.

Migrating an existing cluster to Amazon EKS Auto Mode

For clusters currently using self-managed Karpenter or Cluster Autoscaler, migration to Auto Mode is a phased process — enable Auto Mode first, let it provision new nodes, then drain the old ones. The migration script handles:

  • Enabling Auto Mode and waiting for new nodes to provision

  • Cordoning and draining old self-managed nodes gracefully

  • Verifying all pods are running on Auto Mode nodes

  • Removing old node groups, Karpenter, or Cluster Autoscaler

For complete migration script, see this GitHub repository

Validation after migration

Migration considerations:

  • PodDisruptionBudgets — Auto Mode respects PDBs during node rotation. Ensure PDBs are configured before draining.

  • DaemonSets — Auto Mode nodes run standard EKS-managed DaemonSets. Custom DaemonSets will be scheduled automatically.

  • Taints and tolerations — Review any custom taints on existing nodes. Auto Mode uses its own scheduling logic; workloads relying on custom taints may need toleration updates.

  • Spot interruption handling — Auto Mode manages Spot lifecycle internally. Remove any custom Spot interruption handlers (AWS Node Termination Handler) as they're no longer needed.

For the complete migration and validation scripts, see the 04-karpenter-cost-optimization folder in the code repository.

Key takeaway: EKS Auto Mode is ideal for teams that want zero operational overhead on node management. For clusters requiring workload-specific NodePools, custom disruption budgets, or explicit Spot/On-Demand control, continue with self-managed Karpenter as described in the sections below.