Les frais de transfert de données représentent le troisième poste de dépense d’une facture AWS moyenne, après le calcul et le stockage. C’est aussi celui que presque personne n’arrive à expliquer. Le calcul correspond à des instances que l’on peut lister. Le stockage correspond à des volumes et des buckets que l’on peut voir. Mais les frais réseau se dispersent entre NAT Gateways, trafic inter-zones, sorties vers Internet et une douzaine de tarifs au gigaoctet qui s’accumulent d’une manière que la console ne présente jamais clairement. Le résultat : un montant opaque que les équipes finissent par traiter comme un coût fixe incompressible.
Il ne l’est pas. Une part significative de cette dépense provient d’un petit nombre de comportements récurrents : des ressources inactives qui continuent de facturer, des NAT Gateways qui font un travail qu’un endpoint gratuit pourrait assurer, du trafic qui traverse inutilement des zones de disponibilité. Cet article passe en revue six gains rapides réseau, dans l’ordre où nous les appliquons lors d’un audit, avec pour chacun le service concerné, la méthode de détection, l’ordre de grandeur des économies et le niveau de risque.
Aucun n’est complexe. Tous sont documentés par AWS. La difficulté, comme toujours, c’est que les coûts réseau sont la partie de la facture la plus difficile à lire. Personne n’ira chercher tant qu’on ne lui en donne pas la mission.
Six gains rapides réseau, dans l’ordre d’exécution. Libérer les Elastic IPs inactives (facturées environ 3,60 $/mois même lorsqu’elles ne sont pas utilisées), consolider les NAT Gateways en surnombre dans les VPC hors production, supprimer les load balancers abandonnés sans backend actif, ajouter des VPC endpoints pour router le trafic vers S3, DynamoDB et les API AWS en dehors du chemin NAT, corriger le trafic inter-zones dû à un placement inadapté, et placer les origines à forte sortie derrière CloudFront pour des transferts moins coûteux et le bénéfice du cache.
Les chiffres sont éloquents. Un NAT Gateway coûte environ 32 $/mois rien qu’à exister, plus 0,045 $/Go traité, qui s’ajoutent aux 0,09 $/Go de sortie Internet, soit un coût réel de 0,135 $/Go pour le trafic à destination d’Internet. Le trafic inter-zones ajoute 0,01 $/Go dans chaque sens. Les Gateway endpoints pour S3 et DynamoDB sont gratuits. Tous ces leviers s’actionnent avec les outils natifs (Cost Explorer, le rapport Cost and Usage, VPC Flow Logs, les métriques CloudWatch) et les trois premiers ne présentent aucun risque en production.
Chaque autre partie d’une facture AWS correspond à quelque chose que l’on peut montrer du doigt : une instance, un volume, un bucket. Les frais réseau ne fonctionnent pas ainsi. Un seul gigaoctet quittant un sous-réseau privé vers Internet peut cumuler un frais horaire de NAT Gateway, un frais de traitement des données NAT, un frais de transfert inter-zones et un frais de sortie Internet, chacun sur sa propre ligne, à son propre tarif. La console affiche les totaux, rarement l’histoire. La facture réseau devient ainsi la partie que tout le monde fait défiler rapidement : un grand chiffre sans prise en main évidente.
Le travail d’audit consiste à reconstituer cette histoire. On tire le rapport Cost and Usage, on regroupe par type d’usage et on remonte l’origine des frais au gigaoctet. Une fois le trafic cartographié, les corrections sont généralement évidentes. Plusieurs d’entre elles consistent simplement à supprimer des ressources qui n’auraient jamais dû continuer à facturer.
C’est le poste le plus petit de la liste, mais c’est la forme la plus pure de gaspillage : voilà pourquoi il vient en premier. Depuis février 2024, AWS facture environ 0,005 $/heure, soit environ 3,60 $/mois, pour chaque adresse IPv4 publique, y compris les Elastic IPs allouées mais non associées à quoi que ce soit. Une EIP réservée pour un projet qui n’a jamais vu le jour, ou laissée derrière lors de la résiliation d’une instance, facture chaque heure de son existence pour strictement aucun bénéfice.
La détection se fait en une commande : aws ec2 describe-addresses filtré sur les adresses sans association. La correction : les libérer. Il n’y a pas de fenêtre de maintenance, pas d’impact applicatif. Sur un compte qui a quelques dizaines d’EIPs abandonnées, cela représente facilement 100 à 200 $/mois effacés en dix minutes.
Les NAT Gateways facturent 0,045 $/heure, soit environ 32 $/mois, même si aucun octet ne les traverse. Les bonnes pratiques AWS d’une gateway par zone de disponibilité signifient qu’un VPC à trois zones commence à environ 97 $/mois rien qu’en frais horaires. C’est justifiable en production, où la haute disponibilité mérite d’être payée. C’est beaucoup plus difficile à défendre dans les VPC de pré-production, de staging et de sandbox, où les équipes font tourner trois NAT Gateways pour des environnements qui n’ont pas besoin d’une résilience par zone.
La correction en hors-production consiste à consolider sur une seule NAT Gateway, en acceptant que si sa zone tombe, l’environnement de développement perde la sortie Internet pendant un moment. C’est presque toujours un compromis acceptable. La détection passe par describe-nat-gateways croisé avec les tags d’environnement, et l’économie est d’environ 65 $/mois par VPC ramené de trois gateways à une. Sur un compte avec plusieurs VPC hors production, cela seul couvre souvent une part significative de l’audit.
Les load balancers de projets abandonnés continuent de facturer longtemps après la fin du projet. Un Application ou Network Load Balancer coûte au minimum environ 16 à 22 $/mois en frais horaires, plus son usage LCU, qu’il ait ou non des cibles saines derrière lui. Le cas classique : un load balancer qui pointe vers un target group dont les instances ont été résiliées des mois plus tôt, qui facture tranquillement pour un service qui n’existe plus.
Détection : lancez describe-target-health sur tous les target groups et identifiez ceux où aucune cible n’a été saine depuis plus de 30 jours, puis croisez avec les load balancers parents. Avant de supprimer, vérifiez qu’aucun enregistrement Route 53 ne pointe encore sur le load balancer. La suppression est permanente, mais le risque est très faible pour tout load balancer sans cible saine depuis des semaines. Sur un compte actif, trouver trois ou quatre de ces fantômes est courant.
Le trafic à destination des services AWS (S3, DynamoDB, ECR, CloudWatch et autres) qui transite par une NAT Gateway cumule le frais de traitement NAT de 0,045 $/Go et le frais de sortie Internet de 0,09 $/Go, soit 0,135 $/Go pour atteindre un service qui appartient lui-même à AWS. Les VPC Gateway endpoints pour S3 et DynamoDB ne coûtent absolument rien et routent ce trafic en dehors du chemin NAT. Aucun frais horaire, aucun frais de traitement des données : juste une entrée dans la table de routage. Pour les autres services, les Interface Endpoints entraînent un petit frais horaire par zone plus environ 0,01 $/Go, soit encore environ 78 % moins cher que le tarif NAT, et rentables pour les trafics importants comme les téléchargements d’images ECR ou l’ingestion de logs CloudWatch. La détection consiste à analyser ce que la NAT Gateway traite réellement via VPC Flow Logs, puis à ajouter des endpoints pour les destinations de services AWS les plus sollicitées. Le changement se fait dans la table de routage ou via l’endpoint, sans impact applicatif.
C’est le coût réseau caché le plus fréquent, et le plus facile à visualiser avec un exemple concret. Prenons une instance EC2 dans eu-west-3 qui parle à une base de données RDS également dans eu-west-3. Même région : la plupart des gens supposent que le trafic entre eux est gratuit. Il l’est seulement s’ils se trouvent dans la même zone de disponibilité. Si l’EC2 est en eu-west-3a et le RDS en eu-west-3b, chaque gigaoctet entre eux coûte 0,01 $ dans chaque sens, soit 0,02 $ aller-retour, uniquement parce qu’ils ont atterri dans des zones différentes au sein de la même région. Pour une application bavarde avec des lectures base de données constantes, ça s’accumule vite, et rien dans le schéma d’architecture ne le rend visible.
Le même mécanisme apparaît dans les architectures microservices et les clusters EKS, où des pods répartis sur plusieurs zones se parlent en permanence. Un cluster chargé qui génère 10 To/mois de trafic inter-zones paie environ 200 $/mois en frais de transfert uniquement, pour un schéma de routage que personne n’a délibérément choisi. La détection passe par VPC Flow Logs, en regroupant le trafic par zone source et destination pour identifier quelle part traverse inutilement les frontières.
La correction mérite un avertissement important. Pour les composants sans état, colocaliser les services bavards dans la même zone supprime proprement le frais. Mais pour le cas EC2 vers RDS spécifiquement, le tableau est plus subtil : un RDS Multi-AZ maintient délibérément son standby dans une seconde zone pour la résilience. Pointer l’application vers le primaire dans la même zone minimise les frais inter-zones en fonctionnement normal, mais lors d’un basculement le primaire se déplace dans l’autre zone et les frais inter-zones reviennent jusqu’au rééquilibrage. C’est le compromis : une partie du frais de données inter-zones est le prix de la disponibilité que l’on paie avec le Multi-AZ. La bonne approche est de minimiser le bavardage inter-zones évitable, pas de lutter contre la conception de résilience qui fait son travail.
La dernière action cible directement la sortie Internet. Les données servies directement depuis une instance EC2 ou un bucket S3 vers l’Internet public sont facturées au tarif standard de 0,09 $/Go pour les premiers 10 To/mois. Passer par CloudFront revient moins cher à chaque palier, et la couche de cache fait qu’une large part des requêtes n’atteint jamais l’origine, ce qui réduit à la fois la sortie et la charge sur l’origine.
Les meilleurs candidats sont les contenus statiques et semi-statiques avec des accès répétés : images, téléchargements, segments vidéo, réponses API tolérantes à de courtes fenêtres de cache. La détection consiste à identifier les origines à plus forte sortie dans le rapport Cost and Usage, puis à vérifier lesquelles servent du contenu cacheable. Placer CloudFront devant est un changement de configuration, pas une réécriture applicative. Sur une origine de contenu à fort trafic, cela réduit couramment la facture de sortie d’un tiers ou plus, tout en améliorant la latence pour les utilisateurs finaux via le réseau edge.
« La partie réseau de la facture AWS se cache en pleine vue. Même région ne signifie pas gratuit, un NAT Gateway vous facture trois fois, et une Elastic IP inactive tourne au compteur chaque heure pour rien. Rien de tout cela n’apparaît dans le schéma d’architecture. C’est précisément pourquoi ces coûts survivent pendant des années. »
Julien MAUCLAIR
CTO, Co-Foundeur Stralya
Les six gains rapides ci-dessus couvrent le gaspillage réseau qui résulte de la négligence et des comportements par défaut. Ils sont rapides, globalement sans risque, et correspondent à des lignes de facturation identifiables dès lors qu’on remonte le rapport Cost and Usage. Ils laissent de côté trois sujets réseau plus profonds qui méritent un traitement dédié, car ils touchent à l’architecture et nécessitent une coordination entre équipes.
Le premier est la topologie VPC et la conception du Transit Gateway. Beaucoup de comptes accumulent au fil du temps un enchevêtrement de peerings VPC et de chemins NAT redondants. Les rationaliser en une topologie hub-and-spoke propre avec un Transit Gateway peut réduire à la fois les coûts et la complexité opérationnelle. Mais c’est une refonte réseau, pas un nettoyage d’une semaine, et cela demande une planification soigneuse pour éviter les interruptions.
Le deuxième est l’architecture de sortie à grande échelle. Pour les charges de travail qui transfèrent de très grands volumes de données hors d’AWS, la réflexion va au-delà de CloudFront : Direct Connect, stratégies de sortie dédiées, et parfois des engagements renégociés avec AWS. Ces décisions ont un impact financier important et relèvent d’une planification capacitaire, pas d’un audit rapide.
Le troisième est le service mesh et le routage sensible aux zones pour les grandes architectures microservices. Des outils qui orientent préférentiellement le trafic vers des endpoints dans la même zone peuvent réduire systématiquement les frais inter-zones à l’échelle d’un cluster entier. Mais leur mise en place est un projet d’ingénierie plateforme avec sa propre courbe d’apprentissage opérationnelle.
Ces trois chantiers ont leur place dans une feuille de route d’optimisation sur trois à six mois, après les gains rapides. Repenser la topologie VPC d’un compte qui a encore des NAT Gateways inactifs et des Elastic IPs non associées, c’est commencer le marathon au dernier kilomètre.
Le réseau est la partie de la facture AWS sur laquelle les équipes abandonnent en premier, précisément parce qu’elle est la plus difficile à lire. Les frais sont éparpillés, les tarifs s’accumulent de façon invisible, et le schéma d’architecture ne montre jamais que deux services dans la même région paient silencieusement pour se parler à travers une frontière de zone de disponibilité. Cette opacité est exactement pourquoi les économies sont encore là, intactes, des années après qu’elles auraient pu être réalisées.
Sur un compte de taille significative, l’effet cumulé de ces six actions représente couramment 15 à 30 % de la facture réseau, avec les trois premières qui ne présentent aucun risque en production. Il faut quelqu’un qui accepte de tirer le rapport Cost and Usage, de regrouper par type d’usage et de remonter les frais au gigaoctet jusqu’à leur source. C’est tout le travail : rendre visible la facture invisible, puis supprimer ou reroutier ce qui n’aurait jamais dû facturer.
Retrouvez un PDF complet et détaillé concernant cet article pour avoir plus d’informations
By submitting your email you agree to receive this case study and occasional updates from Stralya. We don’t share your data — see our privacy policy.
Un projet, une infra qui dérive, une facture qui explose. Dites-nous ce qui vous bloque à Paris, on revient avec un plan.
