Les clients d’AWS ne peuvent pas se passer d’IPv4
(tty.neveragain.de)- Depuis février 2024, AWS facture 0,005 $ par heure pour chaque adresse IPv4 publique dédiée, mais les limitations des services AWS empêchent souvent les clients d’éviter ce coût en passant à IPv6
- La facturation couvre un large éventail de ressources, dont Elastic Load Balancer, EC2/Elastic IP, les tâches ECS Fargate avec IP publique, Global Accelerator, les VPN site-à-site, RDS et Managed NAT Gateway
- EC2, VPN, Transit Gateway, Direct Connect et Network Firewall fonctionnent avec IPv6, mais des services clés comme API Gateway, Lambda, ECS et App Runner refusent les sous-réseaux IPv6-only ou les prennent mal en charge
- Même avec une architecture dual-stack en interne, plus de 90 % des endpoints d’API de services ne prennent pas en charge IPv6, ce qui rend difficile l’usage de S3, Systems Manager ou SQS dans un VPC sans IPv4 publique
- Pour les grands clients, cela représente souvent moins de 1 % de la facture, donc peu d’incitation à migrer ; pour les PME, les hobbyistes et les startups, la hausse peut atteindre 10 à 30 %, ce qui pèse davantage
Facturation des IPv4 publiques dédiées depuis février 2024
- Depuis février 2024, AWS facture 0,005 $ par heure pour chaque adresse IPv4 publique dédiée
- Cela représente presque 4 $ par mois et plus de 40 $ par an
- Cela s’applique aux IP appartenant à AWS ; les adresses BYOIP, où le client apporte son propre bloc IPv4 public routable, ne sont pas facturées
- La facturation concerne l’ensemble des principales ressources qui utilisent directement une IPv4 publique
- Elastic Load Balancer
- Utilise une adresse par zone de disponibilité
- Au moins 2 sont nécessaires et il est impossible de désactiver IPv4
- Instances EC2 et Elastic IP
- Tâches ECS Fargate avec IP publique configurée
- IP de Global Accelerator
- IP de VPN site-à-site
- RDS
- Managed NAT Gateway
- Elastic Load Balancer
- Les adresses IPv4 partagées sont exclues
- Les adresses partagées utilisées par les distributions CloudFront ou les endpoints API Gateway ne sont pas facturées
- Les adresses IPv4 publiques utilisées par des fonctions Lambda hors VPC sont également exclues
Configurations où les coûts augmentent fortement
- Un Elastic Load Balancer public déployé sur 3 zones de disponibilité voit son prix de base augmenter de plus de 50 %
- Managed NAT Gateway voit son prix de base augmenter d’environ 10 %
- NAT Gateway n’offre pas de redondance par zone de disponibilité
- Si la connectivité sortante est critique, il faut un NAT Gateway par zone de disponibilité
- Deux schémas particulièrement gourmands en adresses sont fortement touchés
- Une architecture avec plusieurs Load Balancer par VPC
- Cela se produit lorsqu’on combine plusieurs templates CloudFormation ou modules Terraform, ou quand un contrôleur d’ingress Kubernetes crée un Load Balancer par service
- Un seul Load Balancer peut pourtant gérer plusieurs URL et services
- Une architecture qui évite Managed NAT Gateway en attribuant volontairement des IPv4 publiques aux instances EC2 et aux tâches Fargate
- Ironiquement, cette approche reste moins chère tant qu’on n’atteint pas environ 10 adresses IPv4 publiques par zone de disponibilité
- Une architecture avec plusieurs Load Balancer par VPC
Comment vérifier l’usage actuel
- L’utilisation des adresses IPv4 publiques est déjà agrégée dans le compte
- Pour l’instant elle apparaît à 0 $, mais depuis février 2024 elle est facturée 0,005 $ par heure
- Les chemins de vérification sont les suivants
- Billing Dashboard > Bills
- Dans la section Virtual Private Cloud, cela apparaît sous
PublicIPv4:InUseAddress
- Dans la section Virtual Private Cloud, cela apparaît sous
- Cost Explorer
- En filtrant uniquement sur
PublicIPv4:InUseAddress, on peut voir l’usage par jour ou par heure - Il est aussi possible de regrouper par compte membre
- En filtrant uniquement sur
- VPC > VPC IP Address Manager > Public IP insights
- On peut y voir un aperçu de l’usage des IPv4 publiques
- Cette partie d’IPAM est gratuite
- Les données ne sont affichées qu’au niveau compte et région, et restent incomplètes car les adresses utilisées temporairement peuvent ne pas être captées
- Billing Dashboard > Bills
Deux façons d’adopter IPv6
- Comme les adresses IPv4 sont payantes et les adresses IPv6 gratuites, migrer vers IPv6 semble à première vue être un choix naturel
- Avec IPv6, il n’existe pas de notion d’adresse privée, ce qui permet d’éviter Managed NAT Gateway et son coût
- Il existe essentiellement deux approches pour adopter IPv6
- Dual-stack
- Tous les systèmes reçoivent à la fois une adresse IPv4 et une adresse IPv6
- IPv6-only en interne
- L’interne n’utilise qu’IPv6, et seule la périphérie ou le CDN en contact avec les utilisateurs finaux fournit encore de la connectivité IPv4
- Dual-stack
- Un mémorandum de la Maison-Blanche explique que l’exploitation en dual-stack est devenue inutilement complexe à maintenir, et que les organismes de normalisation comme les grandes entreprises technologiques commencent à passer à des déploiements IPv6-only
- Le support réseau IPv6 de base d’AWS est lui-même relativement solide
- Il est possible de configurer des instances EC2 IPv6-only dans des sous-réseaux IPv6-only
- Le DNS local, le service de temps, la configuration des hôtes, la sécurité et les fonctions attendues sur un réseau IPv6 fonctionnent
- VPN, Transit Gateway, Direct Connect et Network Firewall prennent aussi en charge IPv6
IPv6 se heurte à un blocage au moment d’utiliser les services AWS
- Le goulot d’étranglement apparaît moins au niveau du réseau lui-même qu’au moment de se connecter aux autres services AWS
- Des services clés comme API Gateway, Lambda, ECS et App Runner refusent les configurations en sous-réseau IPv6-only ou renvoient des erreurs
- Elastic Load Balancer peut renvoyer des erreurs comme
Not enough IP space available
- Elastic Load Balancer peut renvoyer des erreurs comme
- Même une architecture dual-stack en interne ne suffit pas
- De nombreux services ignorent la présence d’IPv6 même lorsque le sous-réseau en est équipé
- Ils ne peuvent souvent se connecter qu’à des cibles IPv4
- Dans de nombreux cas, utiliser les API de services depuis un VPC sans adresse IPv4 publique est difficile, voire impossible
- Exécuter
aws s3 lsdepuis une instance EC2 échoue - Systems Manager, la méthode recommandée pour se connecter aux instances et les administrer, ne fonctionne pas
- Une tâche ECS ne peut pas accéder à SQS
- Exécuter
- Selon l’état du support IPv6 chez AWS, plus de 90 % des endpoints d’API de services ne prennent pas en charge IPv6
- Les endpoints SES SMTP et de repository ECR ne fonctionnent pas non plus, et CloudFront ne peut pas se connecter à une origin IPv6
- On ne peut donc pas démarrer de tâche ECS à partir d’ECR, alors que c’est possible avec Docker Hub, qui prend en charge IPv6
- Docker Hub applique toutefois une rate limit sur les pulls
PrivateLink est une alternative, mais son coût limite son usage
- Beaucoup de services peuvent être joints via PrivateLink
- Cela connecte directement le VPC du client, sans nécessiter d’adresse IP publique
- Tous les services ne sont pas pris en charge
- PrivateLink est facturé par service et par zone de disponibilité
- Cela revient à environ 9 $ par mois et par endpoint
- Par exemple, connecter Secrets Manager, EC2, SSM et SSM-Messages sur 3 zones de disponibilité dépasse 1 200 $ par an et par VPC
- Des frais de trafic supplémentaires s’ajoutent aussi
Pourquoi la facturation d’IPv4 a peu de chances d’accélérer la migration vers IPv6
- Pour les clients de grande taille, la facturation d’IPv4 représente généralement moins de 1 % de la facture, et n’est donc pas perçue comme un changement majeur
- Ce coût seul déclenche difficilement un investissement d’ingénierie significatif
- Pour les PME, les hobbyistes et les startups, la facture peut augmenter de 10 à 30 %
- Ils ont donc une forte incitation à adopter IPv6 pour éviter ce coût
- Mais les lacunes du support IPv6 des services AWS limitent fortement les moyens d’échapper au coût d’IPv4
- Compte tenu du coût récent d’acquisition des IPv4, faire payer les adresses IPv4 peut se justifier
- Si le support d’IPv6 était plus mature dans l’ensemble des services AWS, davantage de clients pourraient migrer vers des environnements IPv6-only
- Aujourd’hui, il est difficile de considérer IPv6 comme un citoyen de première classe chez AWS, et dans ce contexte la facturation d’IPv4 rend l’usage d’AWS moins attractif pour les comptes personnels, l’apprentissage, la préparation aux certifications et le soutien à l’open source
1 commentaires
Avis sur Hacker News
Il y a longtemps, quand j’étais développeur junior chez Amazon, il y avait un grand projet interne visant à découper tous les systèmes internes en versions par région, et à n’autoriser les appels entre régions que via des passerelles limitées
La raison était l’épuisement des adresses IPv4 internes
À la question « pourquoi ne pas simplement passer à IPv6 ? », le Principal PM responsable avait répondu en gros que trop d’équipements réseau internes existants ne prenaient pas en charge IPv6, et que les remplacer aurait nécessité d’acheter et d’installer une quantité d’équipements proche de la production annuelle mondiale
Il est facile de voir Amazon comme agissant de façon malveillante sur IPv4, mais vu l’échelle des systèmes AWS, il est aussi tout à fait crédible que remplacer tout le vieux matériel réseau ait été un projet beaucoup trop vaste à mener en peu de temps
J’ai le soupçon que c’était un peu du baratin, ou au moins une présentation créative des faits. Par exemple, il est possible qu’en réalité tout ait bien eu une prise en charge IPv6, mais que des ingénieurs réseau pleins de peur, d’incertitude et de doute n’aient pas voulu l’activer
La plupart des équipements réseau que j’ai vus étaient dual stack bien avant qu’IPv6 soit réellement utilisé autour d’eux, et j’ai toujours pensé que c’était dû aux exigences du gouvernement ou de l’armée américaine
Je ne me souviens pas de qui était le PM du projet, mais c’est à ce moment-là que j’ai vraiment appris à respecter la valeur qu’un TPM peut apporter
Il est exact que le coût et la nécessité de remplacer des équipements réseau faisaient partie des raisons fortes de ne pas passer à IPv6. Pour plusieurs raisons, Amazon utilisait des équipements réseau conçus et fabriqués en interne, et c’est probablement encore le cas aujourd’hui
Tous ces équipements avaient une capacité mémoire fixe, donc pour augmenter la mémoire afin de gérer les tables de routage IPv6, etc., il fallait les remplacer. Même en choisissant uniquement IPv6, le matériel existant n’aurait pas suffi, et de toute façon il aurait été difficile de faire passer quoi que ce soit sans dual stack IPv4/IPv6
Elle semble toujours travailler sur des projets d’une ampleur énorme, et IPv4 en est désormais l’un des petits volets. Je ne peux malheureusement pas partager certains des grands projets sur lesquels elle travaille actuellement
Elle m’a accordé du temps à plusieurs reprises et m’a donné des conseils avisés, ce dont je lui suis reconnaissant
Ils ont sûrement déjà lancé le processus
N’est-ce pas ? J’ai du mal à imaginer qu’AWS fasse l’autruche et ignore le sujet
Fournir un IPv6 qui fonctionne correctement semble clairement aller à l’encontre des incitations d’AWS. Les outils d’influence d’AWS, comme les critères Well-Architected ou les certifications, poussent fortement à créer un labyrinthe de réseaux 10.x RFC1918 à l’adressage ambigu, plutôt qu’une architecture de type Internet avec adressage de bout en bout
Dans le monde des recommandations AWS, la notion même d’« adresse IP publique » est un signal d’alerte, et AWS recommande même des outils payants supplémentaires pour afficher et « atténuer » ces adresses
Faire consacrer aux clients des efforts à construire une infrastructure complexe au nom de la sécurité crée un fort effet de verrouillage. Et ce, même si en réalité cela nuit à la sécurité par une complexité inutile, une ambiguïté d’adressage, etc.
On ne compte plus les produits comme « Private Endpoints », « Private Links », « Service Endpoints », « Private Resolvers » ou « Virtual WAN », et tous servent à faire fonctionner IPv4 à grande échelle
Si IPv6 fonctionnait correctement, littéralement aucun de ces produits ne serait nécessaire
À la place, Azure fait aussi du NAT avec IPv6, donc on ne peut même pas utiliser IPv6 pour éviter le NAT imposé par IPv4. En 2023, ils sortent encore de nouveaux produits qui ne prennent pas en charge IPv6 et qui ne le feront probablement pas à l’avenir
La documentation contient encore une page entière de limitations : https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
Si l’on imagine que cette transition était celle d’IPX vers IPv4, on voit à quel point c’est absurde. Ce serait comme si cette page indiquait : « Limitations IPv4 : toutes les VM doivent inclure au moins une adresse IPX »
Cela ne paraît-il pas étrange ? En 1999, on migrait des clients d’IPX vers IPv4, et la prise en charge d’IPv6 est apparue vers 2001-2003. Des décennies plus tard, on a encore l’impression d’être à l’époque précédant la migration de Novell NetWare, quand on disait : « tout ne prend pas encore en charge IPv4, donc il faut IPX+IPv4 »
Cette liste n’est absolument pas exhaustive. Comme la plupart des produits PaaS ne prennent pas en charge IPv6, une solution IaaS+PaaS doit finalement utiliser majoritairement IPv4
Je ne comprends pas pourquoi, mais tant qu’une grande entreprise tech ne poussera pas l’adressage de bout en bout comme bonne pratique, on n’a pas d’autre choix que de suivre la doctrine existante pour éviter de créer des signaux d’alerte
Les clients veulent leur propre réseau privé, même sur des machines qu’ils ne possèdent pas, afin d’empêcher les intrusions et les fuites de données. Plus encore, ils veulent aussi placer dans ce réseau des services PaaS bien intégrés, « batteries incluses »
Mon hypothèse est plus banale : compte tenu du nombre de services d’AWS, la prise en charge d’IPv4 est simplement plus facile
En tant que client AWS, j’aimerais m’affranchir d’IP lui-même. Gérer des systèmes réseau complexes composés de vieux protocoles comme IP, BGP et DNS, c’est une perte de temps
Il suffirait d’associer une identité forte aux workloads, et de me laisser appliquer par politique quels workloads peuvent échanger des données avec quels autres
La façon dont les données vont d’un workload à un autre ne devrait pas être mon problème ; ça devrait simplement fonctionner
Au lieu de tomber dans un datacenter virtualisé, c’est-à-dire un zoo de composants de réseau imité, on abstrait tout
Dans la réalité, ça n’a jamais vraiment fonctionné et ça ne pourra pas fonctionner. Il y a trop de nuances et de détails à prendre en compte pour exécuter et optimiser de vrais workloads
D’après mon expérience, le plus gros problème quand on passe au tout IPv6 sur AWS, c’est que GitHub ne sait toujours pas faire d’IPv6. Beaucoup de logiciels supposent qu’ils peuvent se connecter à GitHub pour récupérer quelque chose
On peut utiliser des services NAT64 publics, mais ce n’est pas vraiment fiable pour un usage sérieux : https://nat64.xyz/
AWS facture très cher le trafic des NAT Gateway, et je ne sais même pas s’il est possible de les configurer pour n’intercepter que le trafic à destination d’hôtes uniquement IPv4. Si je me trompe, je veux bien qu’on me corrige
À part ça, utiliser AWS en IPv6 uniquement fonctionne impeccablement et coûte moins cher. La passerelle d’egress pour les réseaux privés est gratuite. À condition, bien sûr, de ne pas se soucier d’IPv4
À mon avis, le vrai problème est que Lambda et S3 ne prennent pas en charge IPv6, et AWS aurait d’abord dû les rendre dual-stack et accessibles en IPv6 avant de changer les tarifs
Techniquement, S3 dispose bien d’un endpoint dual-stack séparé, mais cela n’aide pas beaucoup, puisqu’il faut de toute façon modifier la configuration de l’application pour s’adapter à ce changement
La moitié de la raison pour laquelle AWS est en avance sur la prise en charge d’IPv6 tient d’abord à l’obligation réglementaire imposée par le gouvernement américain de commencer la migration
Du point de vue des coûts, il est vrai que les nouveaux frais sont négligeables pour les gros clients, mais il ne faut pas sous-estimer le poids des obligations réglementaires qui pèsent sur les plus grands clients. La seule menace de créer leurs propres alternatives pour rester conformes peut finir par pousser AWS à relever la priorité de ce support
Côté client, c’est-à-dire côté utilisateurs finaux, les choses semblent bien avancer. Google indique ces temps-ci près de 50 % de trafic IPv6 des utilisateurs finaux
Personnellement, ce qu’il y a de pire, c’est que CloudFront ne prend pas en charge l’IPv6 pour les origines personnalisées
Si vous faites tourner beaucoup de conteneurs Fargate séparés comme origines, vous devez activer des adresses IPv4 publiques, et le coût des petits conteneurs va bientôt doubler
Amazon devrait faire en sorte que sa propre infrastructure prenne réellement en charge IPv6 avant de facturer un supplément pour l’usage legacy d’IPv4
Je sais qu’Amazon a construit un monstre gigantesque et que déployer IPv6 sur toute une multitude de services est un travail énorme, mais je ne vois aucune raison pour que CloudFront ne prenne pas en charge les origines IPv6 dès maintenant — ou plutôt depuis hier
Ça ne paraît pas si difficile relativement au reste, et cela pourrait être un bon outil pour contourner d’autres limitations
Honnêtement, jusque-là, j’avais le sentiment que les décisions d’Amazon étaient, au bout du compte, prises dans le meilleur intérêt des clients. Ce n’est plus le cas. J’y vois un mauvais signal pour la suite
Une vraie concurrence entre ISP aux États-Unis aurait beaucoup aidé
Là où je loue, en banlieue près de Seattle, il n’y a pourtant qu’un seul véritable ISP haut débit. Ce n’est rural selon aucune définition, mais Comcast est la seule option. Les prix et le service reflètent exactement cette réalité
Ce n’est pas “par hasard” qu’il n’y a que Comcast : c’est devenu “Comcast seulement” à cause de la réglementation
Ce qui est amusant quand on se plaint de Comcast, c’est que lorsque j’étais chez eux, j’avais de l’IPv6 natif. Mon fournisseur actuel ne propose de l’IPv6 que via NAT46
Il y a des inconvénients, comme la dégradation des performances sous de fortes pluies, mais j’ai vu quelques retours positifs
La plupart des gens ignorent qu’il existe aujourd’hui deux Internets IPv6. Il y a le côté Cogent et le côté Hurricane Electric ; ils sont de taille comparable et refusent de s’interconnecter. Il faut donc le savoir et acheter du transit auprès des deux, ou auprès d’un réseau qui achète du transit auprès des deux
Au moins un grand opérateur que je connais fait encore passer v6 dans des tunnels. Dans beaucoup d’endroits, le trafic v6 emprunte des routes non optimales ; les réseaux d’entreprise peuvent avoir une connectivité v4 dans chaque datacenter, mais envoyer tout le v6 vers “la boîte sous le bureau de Dave”
Et malgré tout, on mesure l’adoption de v6 chez Google ou Cloudflare, où des équipes dédiées garantissent l’arrivée des paquets, puis on s’autocongratule
L’expression « impossible de se passer d’IPv4 » est appropriée. On peut bien créer un VPC IPv6 uniquement, mais trop de choses cassent, depuis de nombreux services AWS jusqu’aux dépôts de paquets : https://blog.devopstom.com/ipv6-only-ec2/
Au final, il faut soit activer IPv4, soit exploiter soi-même une passerelle NAT64, soit faire confiance à un NAT64 opéré par quelqu’un d’autre : https://nat64.net et http://v4-frontend.netiter.com
Dire que « comme IPv6 n’a pas de notion d’adresses privées, adieu le Managed NAT Gateway et ses tarifs grandioses » peut être vrai au sein d’AWS, mais IPv6 dispose bien des adresses IPv6 locales uniques en fc00::/7, et si l’on aime vraiment NAT, il existe aussi NAT66
Cela dit, les ULA sont rarement recommandées, et NAT66… c’est juste non
D’après ce que j’ai entendu récemment, Microsoft aurait conçu tout l’IPv6 d’Azure autour de NAT. C’est vraiment étrange