Facturer les adresses IPv4 : Un Nouveau Business Model pour AWS
La Facture IPv4 : Ce Que Ça Change Concrètement
Le 1er février 2024, AWS a commencé à facturer chaque adresse IPv4 publique à 0,005 dollar de l'heure, soit environ 3,60 dollars par mois par IP. Ça semble dérisoire, mais chez mes clients, l'impact est loin d'être négligeable.
L'Impact Sur Mes Clients
Le Client Avec 50 IPs Oubliées
Lors d'un audit AWS chez un éditeur de logiciels, j'ai découvert 50 Elastic IPs qui n'étaient attachées à aucune instance. Des reliquats d'anciens déploiements jamais nettoyés. Avant février 2024, AWS facturait déjà les EIPs non attachées (0,005$/h), mais pas les IPs publiques des instances en fonctionnement. Avec la nouvelle tarification, même les IPs actives coûtent.
Sur ce client, nous avons identifié que 30% des IPs publiques n'avaient aucune raison d'exister. Des instances dans des subnets privés qui avaient une IP publique par défaut, des load balancers de test jamais supprimés, des NAT gateways redondants. Nettoyage fait, économie immédiate.
L'Impact EKS
Le plus insidieux : chaque noeud EKS dans un subnet public a une IP publique. Sur un cluster de 10 noeuds, ça fait 36 dollars par mois juste pour les IPs. Multipliez par 3 environnements (dev, staging, prod), c'est plus de 100 dollars par mois pour... rien d'utile.
La solution que j'applique systématiquement : placer les noeuds EKS dans des subnets privés avec un NAT gateway pour l'accès sortant. Non seulement vous éliminez le coût des IPs publiques, mais vous renforcez la sécurité en rendant les noeuds inaccessibles directement depuis Internet.
Pourquoi AWS Fait Ça
La justification officielle est la pénurie d'adresses IPv4. Le coût d'acquisition d'un bloc IPv4 a explosé de plus de 300% en 5 ans. AWS, qui détient l'un des plus gros pools IPv4 au monde, monétise désormais cette ressource rare.
Mais soyons réalistes : avec un potentiel estimé entre 400 millions et 1 milliard de dollars de revenus annuels supplémentaires, c'est aussi un excellent business model.
La Transition IPv6 : Plus Facile à Dire Qu'à Faire
AWS encourage la transition vers IPv6, et c'est la direction logique. Mais en pratique, passer une infrastructure existante en IPv6 n'est pas trivial :
- Tous les services AWS ne supportent pas encore le dual-stack
- Les applications legacy peuvent ne pas gérer l'IPv6
- Les security groups et les NACLs doivent être revus
- Certains partenaires et clients ne supportent que l'IPv4
Mon approche : dual-stack pour les nouvelles architectures, et migration progressive pour l'existant.
Mes Recommandations Concrètes
- Auditer vos IPs publiques : utilisez AWS Cost Explorer avec le filtre "Public IPv4" pour identifier les coûts
- Supprimer les EIPs non utilisées : c'est la victoire rapide
- Passer les noeuds K8s en subnets privés : sécurité + économie
- Utiliser des endpoints VPC pour accéder aux services AWS (S3, ECR, STS) sans passer par Internet
- Consolider les NAT gateways : un par AZ suffit dans la plupart des cas
Chez un de mes clients, l'ensemble de ces optimisations a réduit la facture IPv4 de 75%. Ce n'est pas énorme en valeur absolue, mais c'est représentatif d'une hygiène de gestion cloud que trop d'entreprises négligent.