Les clients d’AWS ne peuvent pas échapper à l’IPv4

• AWS a annoncé qu’à partir de février 2024, des frais seraient facturés pour les adresses IPv4 publiques. À raison de 0,005 $ par heure, cela représente plus de 4 $ par mois ou plus de 40 $ par an.
• Ces frais affecteront des services comme les Elastic Load Balancers, les instances EC2, les Elastic IPs, les tâches ECS Fargate disposant d’une IP publique, les IPs de Global Accelerator, les IPs de VPN site-à-site et les Managed NAT Gateways. Les adresses IPv4 partagées et les adresses IPv4 publiques utilisées par les fonctions Lambda hors VPC ne seront pas concernées.
• Cette annonce a été bien accueillie par beaucoup, car elle devrait encourager l’adoption de l’IPv6, mais l’auteur affirme que ces frais n’auront pas d’effet majeur sur son adoption en raison du manque de prise en charge de l’IPv6 dans de nombreux services AWS.
• L’auteur souligne que des schémas inefficaces, comme le fait d’avoir plusieurs Load Balancers par VPC ou d’attribuer volontairement des IPv4 publiques aux instances EC2 et aux tâches Fargate pour éviter les Managed NAT Gateways, seront fortement touchés par cette nouvelle tarification.
• Selon l’auteur, il est pratiquement impossible d’exécuter uniquement de l’IPv6 sur AWS, car des services clés comme API Gateway, Lambda, ECS et App Runner ne prennent pas suffisamment en charge l’IPv6. Même en faisant tourner l’infrastructure interne en double pile, la plupart des services AWS ne peuvent se connecter qu’à des cibles IPv4.
• L’auteur critique la manière dont AWS présente cette nouvelle tarification comme un moyen d’encourager l’adoption de l’IPv6, affirmant qu’il n’existe en réalité aucun moyen d’éviter ces frais, AWS ayant largement ignoré l’IPv6 pendant des années.
• L’auteur conclut que, compte tenu de la hausse récente du coût d’acquisition des IPv4, cette tarification est peut-être nécessaire, mais qu’elle ne favorisera pas l’adoption de l’IPv6 et risque au contraire de freiner l’innovation tout en rendant moins attractif le fait de posséder un compte AWS personnel.
• Il s’agit de la première partie d’une série d’articles de blog. Les prochains billets approfondiront les options liées à l’adoption de l’IPv6 sur AWS concernant l’ingress et le trafic intra-VPC, le trafic egress ainsi que les problèmes de programmation applicative.

[GN⁺]

Avis Hacker News

• Amazon mène un vaste projet visant à scinder tous les systèmes internes en versions régionales en raison de l’épuisement des adresses IPv4 internes
• Une migration vers IPv6 est impossible, car de nombreux équipements réseau internes ne prennent pas en charge IPv6
• Comme les outils d’AWS recommandent fortement de construire des réseaux en adressant de façon ambiguë les réseaux 10.x RFC1918, AWS n’a guère d’incitation à fournir une prise en charge v6 qui fonctionne réellement
• Un problème majeur avec un usage exclusivement IPv6 sur AWS est qu’une grande partie des logiciels cherchant à accéder à GitHub ne prennent toujours pas en charge IPv6
• Certains clients d’AWS expriment le souhait de se débarrasser totalement des IP en raison de la complexité de gestion de ces systèmes réseau
• Le fait que des services comme Lambda et S3 ne prennent pas en charge IPv6 est un problème important, et AWS aurait dû les rendre accessibles en dual-stack via IPv6 avant de modifier sa tarification
• La principale prise en charge d’IPv6 par AWS est en partie due à l’injonction faite par le gouvernement américain de lancer la migration
• Le fait que CloudFront ne prenne pas en charge IPv6 pour les origines personnalisées pose problème à ceux qui exécutent de nombreux conteneurs Fargate distincts comme origines
• Le manque de concurrence entre les FAI aux États-Unis freine l’adoption d’IPv6
• Configurer un VPC IPv6-only sur AWS peut casser beaucoup de choses, depuis divers services AWS jusqu’aux dépôts de paquets
• Comme IPv6 n’a pas de concept d’adresse privée, il faudrait dire adieu à Managed NAT Gateway et à sa tarification