EKS Auto Mode in 2026: A Decision Grid

This article was originally published in French on the Seven Mile blog.

On October 8, I had the chance to give a talk at KubeAuto Day Paris, organized by Cast AI at La Bellevilloise: “EKS Auto Mode: Is It Still Worth Making the Move?”. Thanks again to Cast AI for the organization, and to everyone who came by the Seven Mile booth. On stage, I promised to publish the full decision grid, with the sources. Here it is.

In December 2024, at re:Invent, AWS announced EKS Auto Mode, and I wrote an article that very week. Almost two years later, the question I get is no longer “what is it”. Several times, customers and other consultants have asked me: is it worth it today? Can I do this with Auto Mode? That’s why I decided to do this analysis, to guide those who are asking themselves the question.

Auto Mode in one picture

On standard EKS, AWS runs the control plane, and that’s it. In your account, you have your EC2 nodes, your pods, and everything you deploy yourself: Karpenter, the add-ons, the AMI.

Auto Mode changes three things:

1. Karpenter is now managed by AWS. You no longer deploy it and you no longer pick its version. You do, however, keep managing NodePools and NodeClasses.
2. The add-ons (VPC CNI, CoreDNS, kube-proxy, EBS CSI, Load Balancer Controller, Pod Identity) also run outside the cluster. Nothing left to upgrade on your side, they’re managed by AWS as well.
3. The node lifecycle: the Bottlerocket AMI is mandatory, refreshed roughly every week, with automatic rotation and repair mechanisms.

What stays with you: NodePools and NodeClasses, PDBs and disruption budgets, triggering control plane upgrades, and your own add-ons and DaemonSets. All of this comes at a price, though: a per-instance fee, on top of what you already pay for your EC2 instances. If you know Karpenter, you already know 80% of Auto Mode.

“Which one is better?” is the wrong question

The question I get most often is “self-managed Karpenter or Auto Mode, which one is better?”. In 2026, the feature lists are almost at parity, and they keep moving every month. The right way to decide is to go through three questions that can block you outright, then make two trade-offs. And you’ll see that the biggest trade-off isn’t technical: it’s how you buy your compute.

What you still can’t do

First thing to look at, what remains impossible with Auto Mode:

• a third-party CNI (Cilium, Calico): not supported, and no chaining either (running several CNIs side by side), since the managed VPC CNI runs outside the cluster;
• Security Groups per Pod: security groups are defined at the NodeClass level, so all pods on a node share the same ones. The request is open, and AWS says it’s working on it for 2026, without committing to a date;
• Windows nodes (issue open since January 2025);
• a pod CIDR outside the VPC;
• a custom AMI: Bottlerocket is mandatory, always up to date, with no way to pin a version;
• SSH or SSM on the node: debugging goes through NodeDiagnostic (logs and tcpdump sent to S3) or kubectl debug node.

This gives the first two questions of the grid.

Question 1: do you need a third-party CNI, Security Groups per Pod, a pod CIDR outside the VPC or Windows? If so, it’s self-managed Karpenter, and the rest doesn’t concern you.

Question 2: does a mandatory agent in your company, for security or compliance, need a kernel module, SSH or a mutable host? If so, same answer.

Other limits are worth knowing, without being blockers for most teams: IMDS with a hop limit of 1 that can’t be changed (which breaks some older SDKs), no Gateway API in the managed Load Balancer Controller, no DRA, and a cap of 110 pods per node.

Nodes replaced every 14 to 21 days

Third blocking question. In Auto Mode, a node lives 14 days by default and 21 days at most (expireAfter defaults to 336h), then it’s replaced. It’s the same mechanism for a new Kubernetes version, a new AMI (roughly one a week) or a faulty node.

You control the when: PDBs, the karpenter.sh/do-not-disrupt annotation on a pod or a node, and NodePool disruption budgets with a cron, for example “no replacement outside Monday 6pm-8pm”. You don’t control the if.

Question 3: can each of your workloads handle a node replacement every 14 to 21 days? If a workload must live longer on the same node, a long fine-tuning job or a sensitive stateful workload for example, Auto Mode isn’t a fit: either go self-managed, or isolate it somewhere else. For everything else, a well-built cluster with PDBs already handles it.

The fees are fixed, your discount isn’t

The Auto Mode fees published in the AWS price list are exactly 12% of the instance’s On-Demand price, for CPU instances. They’re fixed: AWS charges them regardless of how you buy, so you pay the same fees On-Demand, with Savings Plans or on Spot. So the better you buy, the more these fees weigh in proportion to what you actually pay.

To make it concrete, I reworked an example from the public AWS price list (version of 09/28/2026), with three instances in us-east-1 (m6i.xlarge, c6a.2xlarge, r6i.xlarge) over a 730-hour month:

On Spot, the fees represent about a quarter of what you pay, and with a well-committed Savings Plan, up to a third. It’s not a trap, it’s the model. The control plane doesn’t change: $0.10 per hour, $0.60 on extended support.

That’s the real trade-off: is the ops time you no longer spend on Karpenter, AMIs and add-ons worth fees that don’t go down? For a team that buys mostly On-Demand and has nobody to operate Karpenter, yes, easily. For a platform running 80% Spot with an infra team, the math is tighter…

Question 4: do you mostly buy Spot or long-term commitments? If so, do the math, and ask yourself whether the ops time saved is worth these fees.

What has changed since launch

Since Auto Mode came out, a lot has moved. I group the changes into three families, because they don’t weigh the same in the decision.

What removes a blocker.

• Static capacity (November 2025), with a fixed number of nodes per NodePool, and capacity reservations, ODCR and Capacity Blocks (June 2025). Stateful and reserved capacity are now in scope.
• The FIPS and GovCloud AMI (October 2025). Regulated workloads too.
• Tuning the kubelet, an allowlist of sysctls and hugepages directly in the NodeClass (advancedCompute, October 1, 2026), without a custom AMI.

What changes the cost. Since July 1, 2026, GPU fees have dropped: 7.8% on G instances, 4.8% on P and Trainium, versus 12% before. That’s almost half on G instances, and two and a half times less on P and Trainium. GPU is no longer a blocker cost-wise.

What reassures ops.

• Version rollback (July 2026): from N to N-1 within 7 days, nodes first then the control plane, at no extra cost.
• Automatic node repair, which since June 2026 also watches EC2 status checks and scheduled maintenance. It pauses itself when more than 20% of a NodePool’s nodes are unhealthy.
• Managed controller logs in CloudWatch (February 2026), which answer the number one complaint customers raised: “we can’t see the managed controllers’ logs!”

The first two families can change your answer to the grid. The third changes your day-to-day comfort, not your answer. If you said no to Auto Mode in 2025 for one of these reasons, run the grid again!

Other changes go in the same direction without changing the decision: node startup 39% faster according to the benchmark published by AWS, the Balanced consolidation policy (default from EKS 1.37), and Load Balancer Controller parity with v3.4.

The grid

Five questions, in this order.

1. Blocker. Do you need a third-party CNI, Security Groups per Pod, a pod CIDR outside the VPC or Windows? Yes: self-managed Karpenter.
2. Blocker. Does a mandatory agent need a kernel module, SSH or a mutable host? Yes: self-managed.
3. Blocker. Can each of your workloads handle a node replacement every 14 to 21 days? No: self-managed, or isolate the workload.
4. Trade-off. Do you mostly buy Spot or long-term commitments? Yes: the fees then weigh a quarter to a third of what you pay. Is the ops time saved worth it?
5. Trade-off. Do you want node upgrades, patching, repair and rollback without touching them, while accepting that you choose neither the AMI nor the controllers’ version? Yes: Auto Mode.

Where Auto Mode stops

Whatever you choose, Auto Mode manages your nodes, and it stops in three places.

1. Rightsizing. Auto Mode consolidates nodes, but it never touches your pods’ requests. Oversized requests stay oversized, just on fewer nodes.
2. Spot strategy. Spot is supported, but the instance family mix, diversification and On-Demand fallback are yours to design in your NodePools.
3. Cost beyond the fees. The fees are fixed and optimize nothing. Bin packing, purchasing strategy, Spot arbitrage and cost per pod remain your job, with or without Auto Mode.

For these three topics, your own tooling or a third-party tool takes over.

Wrapping up

In 2026, Auto Mode is no longer decided on a feature list, but on three blocking questions and on how you buy your compute. If none of the three questions blocks you, you mostly buy On-Demand and nobody in your team has time to operate Karpenter, Auto Mode is worth it. And since AWS keeps removing blockers, with Security Groups per Pod announced for 2026, run the grid again as soon as one of your answers changes!