Un retour d’expérience chiffre l’économie d’un EKS IPv6-first : 143 $ par mois et par environnement
Le 14 août 2026, un membre RIPE NCC publie le retour d’expérience d’un EKS déployé en IPv6-first sur AWS : environ 143 $ par mois et par environnement économisés, contre une liste datée de dépendances encore bloquées en IPv4. Les équipes qui montent un cluster neuf ont un critère objectif pour trancher entre IPv6-first et dual-stack.
1er février 2024. AWS facture 0,005 $ par heure chaque adresse IPv4 publique, soit environ 3,65 $ par mois. 14 août 2026. Spiro Stathakis, fondateur du LIR isp6, publie sur RIPE Labs le retour d’expérience de son EKS déployé en IPv6-first. 14 juillet 2026. Il vérifie ses dépendances externes et constate que api.stripe.com et github.com n’ont toujours pas d’enregistrement AAAA.
Le constat tient en une phrase : sur AWS, l’IPv4 est devenu une taxe silencieuse, et un cluster neuf peut s’en affranchir presque entièrement — à condition d’accepter que la panne, quand il y en a une, ne fait aucun bruit.
L’IPv4 est une taxe silencieuse
Depuis le 1er février 2024, la tarification des adresses IPv4 publiques change l’arithmétique. Un EKS classique sur trois zones de disponibilité accumule sans qu’on y pense des NAT gateway, des adresses IP élastiques, du trafic NAT facturé au gigaoctet et des IPv4 publiques sur les ALB.
Le retour d’expérience pose les chiffres sur la table, aux prix us-east-1 sur un mois de 730 heures. Trois NAT gateway à 0,045 $/h : 98,55 $. Trois EIP de NAT à 0,005 $/h : 10,95 $. Le traitement NAT d’environ 500 Go à 0,045 $ : 22,50 $. Les IPv4 publiques des ALB : 10,95 $. Total : environ 143 $ par mois et par environnement.
En IPv6-first, ce poste tombe à zéro, ou presque. Le cluster sort par une egress-only Internet Gateway, gratuite, sans SNAT, et chaque pod garde sa propre adresse. La seule dépense résiduelle — de 0 à 11 $ — est le choix délibéré de garder des IPv4 publiques en bordure pour joindre les clients encore en IPv4. L’économie est réelle, mais elle n’est pas automatique : elle dépend de votre capacité à vous passer des dépendances qui « traînent » l’IPv4 derrière elles.
Ce qui casse encore, avec dates
La thèse du billet est brutale : vous n’êtes jamais plus IPv6 que votre dépendance la moins capable. Rien ne casse bruyamment ; une dépendance refuse simplement de parler autre chose qu’IPv4, et pour l’atteindre vous gardez une NAT gateway — donc des routes, des adresses et sa facture.
Le premier piège est structurel. Un EKS en ipFamily: ipv6 donne des pods et services IPv6-only, mais les nœuds restent en dual-stack et chaque sous-réseau doit porter un CIDR IPv4. Le choix est irréversible à la création du cluster : instances Nitro uniquement, pas de pods Windows, pas d’Outposts, pas de FSx for Lustre, pas de réseau personnalisé.
La VPC CNI enchaîne un plugin host-local qui attribue à chaque pod une adresse IPv4 non routable en 169.254.172.0/22, puis la SNAT vers l’IPv4 du nœud dès qu’un pod parle à une destination IPv4-only. C’est ce « shim » d’interopérabilité qui fait que l’IPv6 « marche » — et qui vous empêche de voir l’IPv4 résiduel ailleurs que dans les flow logs.
Le reste est une liste datée, précieuse parce que plusieurs verrous ont sauté en cours de route. RDS ne peut toujours pas tourner sans IPv4 : les sous-réseaux IPv6-only sont non supportés, et le dual-stack exige un CIDR IPv4 partout. Les progrès sont lents — bases publiques dual-stack le 31 octobre 2025, IPv6 sur les endpoints VPC des API RDS le 30 janvier 2026. ECR a été IPv4-only des années : endpoints dual-stack le 2 mai 2025, PrivateLink le 21 novembre 2025. CloudFront sait récupérer en IPv6 depuis le 8 septembre 2025, mais en excluant les origines S3 et VPC.
Le piège le plus sournois est le DNS par défaut d’AWS. Vérifié en juillet 2026 : sts.eu-west-1.amazonaws.com n’a pas d’enregistrement AAAA, alors que sts.eu-west-1.api.aws en a un. Les SDK utilisent la première forme par défaut, et AWS_USE_DUALSTACK_ENDPOINT n’est pas actif d’office. Sans bascule explicite, les appels API de votre workload « IPv6 » passent en IPv4.
Le piège : la panne est silencieuse
C’est la leçon la plus utile du retour d’expérience. Sur l’IPv6, rien ne casse fort ; tout échoue en silence. Une dépendance prend la NAT, un endpoint résout en A plutôt qu’en AAAA, un client Happy Eyeballs choisit l’IPv4 sans prévenir — et vous ne le découvrez que dans les flow logs, pas dans une trace de pile.
Deux exemples le montrent. Les /28 n’ont pas survécu : un /28 ne laisse que 11 adresses utilisables après les cinq réservées par AWS, et les ENI des endpoints dual-stack plus les ENI primaires des nœuds les ont épuisées. L’équipe est passée à du /27 public et /26 privé, à contrecœur. Autre cas : les endpoints dual-stack résolvent en A et AAAA, et les clients Happy Eyeballs prennent volontiers le A. La parade tient au security group : ingress IPv6-only sur le 443, pour que toute tentative IPv4 échoue fermée au lieu de réussir en douce.
La longue traîne, enfin, est là où le rêve meurt. Vérifiées le 14 juillet 2026 : api.stripe.com sans AAAA, github.com sans AAAA, une passerelle SMS et deux fournisseurs d’identité sans AAAA. À l’inverse, gitlab.com et Docker Hub résolvent très bien en AAAA. Chaque nom de cette liste est une raison pour laquelle l’unique NAT gateway subsiste.
Verdict
Si vous montez un cluster neuf, sur Linux et Nitro, natif Kubernetes, avec une base qui parle IPv6 ou cachée derrière PrivateLink, l’IPv6-first est le bon défaut en 2026. La liste des verrous est finie, documentée, et visiblement en rétrécissement : ECR, les origines CloudFront, le RDS public et ses API ont tous bougé récemment.
Si vous dépendez d’un maillon IPv4-only — un RDS exposé, Stripe, GitHub, un partenaire d’identité — gardez exactement une NAT gateway comme passif résiduel, pas trois, et traitez-la comme une dette qui rétrécit à mesure que vos fournisseurs ajoutent un AAAA.
Dans tous les cas, instrumentez les flow logs au premier jour. Le mode de défaillance de tout ce qui précède est le silence, pas l’erreur : c’est dans les flow logs NAT que vous verrez quelles dépendances roulent encore en IPv4 à votre insu.