EKS Auto Mode en 2026 : une grille pour décider

Le 8 octobre, j'ai eu l'occasion de présenter un talk à KubeAuto Day Paris, organisé par Cast AI à La Bellevilloise : « EKS Auto Mode: Is It Still Worth Making the Move? ». Merci encore à Cast AI pour l'organisation, et à tous ceux qui sont passés nous voir sur le stand Seven Mile. J'avais promis sur scène de publier la grille de décision complète, avec les sources. La voici.

En décembre 2024, à re:Invent, AWS annonçait EKS Auto Mode, et j'avais écrit un article la semaine même. Presque deux ans plus tard, la question qu'on me pose n'est plus « c'est quoi ». Plusieurs fois, des clients mais aussi d'autres consultants m'ont demandé : est-ce qu'aujourd'hui, ça vaut le coup ? Est-ce que je peux faire ça avec Auto Mode ? C'est pour ça que j'ai décidé de faire cette analyse, pour aiguiller ceux qui se posent la question.

Auto Mode en une image

Sur EKS standard, AWS fait tourner le control plane, et c'est tout. Dans votre compte, vous avez vos nœuds EC2, vos pods, et tout ce que vous y déployez vous-même : Karpenter, les add-ons, l'AMI.

Auto Mode change trois choses :

1. Karpenter est désormais géré par AWS. Vous ne le déployez plus et vous ne choisissez plus sa version. Vous gardez cependant la gestion des NodePools et des NodeClasses.
2. Les add-ons (VPC CNI, CoreDNS, kube-proxy, EBS CSI, Load Balancer Controller, Pod Identity) tournent eux aussi hors du cluster. Plus rien à upgrader de votre côté, ils sont également gérés par AWS.
3. Le cycle de vie des nœuds : l'AMI Bottlerocket est imposée, rafraîchie à peu près chaque semaine, avec des mécanismes de rotation et réparation automatiques.

Ce qui reste chez vous : les NodePools et NodeClasses, les PDB et les disruption budget, le déclenchement des mises à jour du control plane, et vos propres add-ons et DaemonSets. Cependant tout ça a un prix : des frais par instance, en plus du prix que vous payez déjà pour vos EC2. Si vous connaissez Karpenter, vous connaissez déjà 80 % d'Auto Mode.

« Lequel est mieux ? » est la mauvaise question

La question qu'on me pose le plus souvent, c'est « Karpenter self-managed ou Auto Mode, lequel est mieux ? ». En 2026, la liste de features est quasiment à parité, et elle continue de bouger tous les mois. La bonne façon de décider, c'est de passer par trois questions qui peuvent vous bloquer directement, puis faire deux arbitrages. Et vous allez voir que le plus gros arbitrage n'est pas technique : c'est la façon dont vous achetez vos ressources de calcul.

Ce qu'on ne peut toujours pas faire

Première chose à regarder, ce qui reste impossible avec Auto Mode :

• un CNI tiers (Cilium, Calico) : non supporté, et pas de chaining non plus (c'est-à-dire faire cohabiter plusieurs CNI en même temps), puisque le VPC CNI managé tourne hors du cluster ;
• Security Groups per Pod : les security groups se définissent au niveau de la NodeClass, donc tous les pods d'un nœud partagent les mêmes. La demande est ouverte, et AWS indique y travailler pour 2026, sans s'engager sur une date ;
• des nœuds Windows (issue ouverte depuis janvier 2025) ;
• un pod CIDR hors du VPC ;
• une AMI custom : Bottlerocket est imposé, toujours à jour, sans possibilité de fixer une version ;
• SSH ou SSM sur le nœud : le debug passe par NodeDiagnostic (logs et tcpdump envoyés vers S3) ou par kubectl debug node.

Ça donne les deux premières questions de la grille.

Question 1 : avez-vous besoin d'un CNI tiers, de Security Groups per Pod, d'un pod CIDR hors VPC ou de Windows ? Si oui, c'est Karpenter self-managed, et la suite ne vous concerne pas.

Question 2 : est-ce qu'un agent obligatoire chez vous, de sécurité ou de conformité, a besoin d'un module noyau, de SSH ou d'un hôte mutable ? Si oui, même réponse.

D'autres limites méritent d'être connues, sans être bloquantes pour la plupart des équipes : IMDS en hop limit 1 non modifiable (ce qui casse certains SDK anciens), pas de Gateway API dans le Load Balancer Controller managé, pas de DRA, et un plafond de 110 pods par nœud.

Des nœuds remplacés tous les 14 à 21 jours

Troisième question bloquante. En Auto Mode, un nœud vit 14 jours par défaut et 21 jours au maximum (expireAfter vaut 336 h par défaut), puis il est remplacé. C'est le même mécanisme pour une nouvelle version de Kubernetes, une nouvelle AMI (à peu près une par semaine) ou un nœud défaillant.

Vous avez la main sur le quand : les PDB, l'annotation karpenter.sh/do-not-disrupt sur un pod ou un nœud, et les disruption budgets du NodePool avec un cron, par exemple « aucun remplacement en dehors du lundi 18h-20h ». Vous n'avez pas la main sur le si.

Question 3 : est-ce que chacun de vos workloads supporte un remplacement de nœud tous les 14 à 21 jours ? Si un workload doit vivre plus longtemps sur le même nœud, un fine-tuning long ou un stateful sensible par exemple, là ce n'est pas adapté et il faut soit faire du self-managed, ou vous l'isolez ailleurs. Pour tout le reste, un cluster bien fait, avec des PDB, le supporte déjà.

Les frais sont fixes, votre remise ne l'est pas

Les frais Auto Mode publiés dans la price list AWS représentent exactement 12 % du prix On-Demand de l'instance, pour les instances CPU. Ils sont fixes : AWS les facture indépendamment de comment vous les achetez, donc vous payez les mêmes frais en On-Demand, en Savings Plans ou en Spot. Donc plus vous achetez bien, plus ces frais pèsent en proportion de ce que vous payez réellement.

Pour le rendre concret, j'ai refait un exemple à partir de la price list publique AWS (version du 28/09/2026), avec trois instances en us-east-1 (m6i.xlarge, c6a.2xlarge, r6i.xlarge) sur un mois de 730 heures :

Mode d'achat	EC2 payé	Frais Auto Mode	Frais en % du payé
On-Demand	547,50 $	65,70 $	12,0 %
Spot (remises moyennes du Spot Advisor sur 30 jours)	247,08 $	65,70 $	26,6 %
Compute Savings Plan, remise maximale de 66 %	186,15 $	65,70 $	35,3 %

En Spot, les frais représentent environ un quart de ce que vous payez, et avec un Savings Plan bien engagé, jusqu'à un tiers. Ce n'est pas un piège, c'est le modèle. Le control plane, lui, ne change pas : 0,10 $ de l'heure, 0,60 $ en extended support.

C'est là le vrai arbitrage : le temps d'ops que vous ne passez plus sur Karpenter, les AMI et les add-ons vaut-il des frais qui ne réduisent pas ? Pour une équipe qui achète surtout en On-Demand et n'a personne pour opérer Karpenter, oui, facilement. Pour une plateforme à 80 % Spot avec une équipe infra, le calcul est plus serré...

Question 4 : achetez-vous majoritairement en Spot ou avec des engagements longs ? Si oui, faites le calcul, et demandez-vous si le temps d'ops économisé vaut ces frais.

Ce qui a changé depuis le lancement

Depuis la sortie d'Auto Mode, beaucoup de choses ont bougé. Je les classe en trois familles, parce qu'elles ne pèsent pas pareil dans la décision.

Ce qui lève un bloqueur.

• La capacité statique (novembre 2025), avec un nombre fixe de nœuds par NodePool, et les réservations de capacité, ODCR et Capacity Blocks (juin 2025). Le stateful et le réservé sont entrés dans le périmètre.
• L'AMI FIPS et GovCloud (octobre 2025). Le régulé aussi.
• Le réglage du kubelet, d'une liste blanche de sysctls et des hugepages directement dans la NodeClass (advancedCompute, 1er octobre 2026), sans AMI custom.

Ce qui change le coût. Depuis le 1er juillet 2026, les frais GPU ont baissé : 7,8 % sur les instances G, 4,8 % sur les P et Trainium, contre 12 % avant. C'est presque divisé par deux sur les G, et par deux et demi sur les P et Trainium. Le GPU n'est plus un bloqueur en termes de coût.

Ce qui rassure l'ops.

• Le rollback de version (juillet 2026) : de N vers N-1 dans les 7 jours, les nœuds d'abord puis le control plane, sans surcoût.
• La réparation automatique des nœuds, qui surveille aussi depuis juin 2026 les status checks EC2 et les maintenances planifiées. Elle se suspend d'elle-même quand plus de 20 % des nœuds d'un NodePool sont dans un mauvais état.
• Les logs des contrôleurs managés dans CloudWatch (février 2026), qui répondent à la critique numéro un que les clients relevaient : « on ne voit pas les logs des contrôleurs managés ! »

Les deux premières familles peuvent changer votre réponse à la grille. La troisième change votre confort au quotidien, pas votre réponse. Si vous avez dit non à Auto Mode en 2025 pour une de ces raisons, rejouez la grille !

D'autres évolutions vont dans le même sens, sans changer la décision : un démarrage de nœud 39 % plus rapide d'après le benchmark publié par AWS, la politique de consolidation Balanced (par défaut à partir d'EKS 1.37), et la parité du Load Balancer Controller avec la v3.4.

La grille

Cinq questions, dans cet ordre.

1. Bloquant. Avez-vous besoin d'un CNI tiers, de Security Groups per Pod, d'un pod CIDR hors VPC ou de Windows ? Oui : Karpenter self-managed.
2. Bloquant. Un agent obligatoire a-t-il besoin d'un module noyau, de SSH ou d'un hôte mutable ? Oui : self-managed.
3. Bloquant. Chacun de vos workloads supporte-t-il un remplacement de nœud tous les 14 à 21 jours ? Non : self-managed, ou isolez le workload.
4. Arbitrage. Achetez-vous majoritairement en Spot ou avec des engagements longs ? Oui : les frais pèsent alors d'un quart à un tiers de ce que vous payez. Le temps d'ops économisé le vaut-il ?
5. Arbitrage. Voulez-vous des upgrades, des patchs, la réparation et le rollback des nœuds sans y toucher, en acceptant de ne choisir ni l'AMI ni la version des contrôleurs ? Oui : Auto Mode.

Là où Auto Mode s'arrête

Quel que soit votre choix, Auto Mode gère vos nœuds, et il s'arrête à trois endroits.

1. Le rightsizing. Auto Mode consolide les nœuds, mais il ne touche jamais aux requests de vos pods. Des requests surdimensionnées restent surdimensionnées, simplement sur moins de nœuds.
2. La stratégie Spot. Spot est supporté, mais le mix de familles d'instances, la diversification et le repli sur l'On-Demand, c'est vous qui les concevez dans vos NodePools.
3. Le coût au-delà des frais. Les frais sont fixes et n'optimisent rien. Le bin packing, la stratégie d'achat, l'arbitrage Spot et le coût par pod restent votre travail, avec ou sans Auto Mode.

Pour ces trois sujets, c'est votre propre outillage, ou un outil tiers qui prend le relais.

Pour conclure

En 2026, Auto Mode ne se décide plus sur une liste de features, mais sur trois questions bloquantes et sur la façon dont vous achetez votre compute. Si aucune des trois questions ne vous bloque, que vous achetez surtout en On-Demand et que personne chez vous n'a le temps d'opérer Karpenter, Auto Mode vaut le coup. Et comme AWS continue de lever des bloqueurs, les Security Groups per Pod étant annoncés pour 2026, rejouez la grille dès qu'une de vos réponses change !