Petite devinette cloud : qu'est-ce qui est invisible, silencieux, et vide discrètement des dizaines (voire des centaines) de milliers de dollars de votre facture AWS chaque mois ?
Non, ce ne sont pas les volumes EBS inutilisés (même si, oui, il faut aussi faire le ménage).
Ce sont les transferts de données entre AZ, et ils sont bien plus sournois qu'il n'y paraît.
Le bavardage coûteux des AZ
Sur AWS, lorsque des données circulent entre des zones de disponibilité (AZ) d'une même région, elles sont facturées deux fois : une fois pour les données quittant l'AZ source, et une seconde fois pour celles entrant dans l'AZ de destination. Soit 2¢ par Go dans chaque sens, ce qui grimpe très vite à grande échelle.
Cela peut se justifier si vous exploitez des bases de données multi-AZ ou des architectures à haute disponibilité. Mais voici le hic : une part énorme du trafic inter-AZ est accidentelle, inutile, ou tout simplement mal comprise.
Raisons courantes de l'explosion du trafic entre AZ :
- Des microservices communiquent entre AZ sans que personne s'en aperçoive.
- Vos nœuds EKS sont répartis dans différentes AZ et utilisés indifféremment.
- Les load balancers routent le trafic entre zones de façon imprévisible.
- Les services stateful ne respectent pas l'affinité d'AZ.
- Vous avez hérité d'un fichier YAML datant de 2019 en priant pour qu'il fonctionne encore.
Dans cet excellent article, une équipe a découvert que plus de 80 % de son trafic inter-AZ était évitable — elle n'en avait tout simplement aucune visibilité avant de creuser le sujet en profondeur.
Mais pourquoi est-il si difficile de réduire ces coûts ?
Ces coûts apparaissent dans l'AWS Cost and Usage Report (CUR) sous des types d'usage comme :
- AWS:DataTransfer-Regional-Bytes
- AWS:DataTransfer-Regional-Bytes-Out
- BoxUsage:
:DataTransfer-Out-Bytes
Par exemple :
Mais voici le problème : même en fixant ces lignes dans un tableur, impossible de savoir ce qui les a réellement générées.
Vous obtiendrez peut-être des informations au niveau machine via les identifiants d'instances EC2, mais si vos workloads modernes tournent sur Kubernetes, bonne chance pour remonter jusqu'à un pod, un namespace ou un workload précis.
Certaines équipes tentent de combler ce vide avec les VPC Flow Logs, qui capturent les métadonnées de communication IP à IP. C'est utile, mais activer les Flow Logs en continu sur toute votre infrastructure coûte extrêmement cher, et paradoxalement, cela peut vous coûter plus que les transferts inter-AZ que vous cherchez à déboguer.
Et même en acceptant le coût des VPC Flow Logs, un autre problème se pose :
Les Flow Logs livrent des données réseau brutes, sans contexte. Voici un exemple de logs :
Vous vous retrouvez avec une montagne de données de trafic IP à IP. Sauf que c'est comme recevoir une boîte de puzzle sans l'image sur le couvercle. Il reste tout le gros du travail à faire : enrichir les logs, associer les IP aux instances, recouper avec l'inventaire cloud, identifier à quel workload ou conteneur appartient chaque IP, et ensuite tenter de décoder la logique métier derrière chaque flux.
Et dans un environnement Kubernetes, c'est encore pire. IP dynamiques, pods éphémères, groupes d'autoscaling, service meshes… c'est le chaos. Il vous faudra des heures (voire des jours) de travail d'ingénierie, une discipline de tagging rigoureuse entre équipes et un solide arsenal d'outils de corrélation de logs — rien que pour identifier le microservice qui bavarde entre les AZ.
Le temps d'avoir la réponse, votre facture cloud a déjà explosé.
Alors comment lutter contre un coût que vous ne pouvez même pas tracer ?
La solution d'Attribute™ : mettre en lumière les coûts cachés
Chez Attribute™, nous avons conçu une solution unique pour rendre visible ce qui ne l'est pas.
Notre sonde eBPF suit chaque octet quittant vos workloads — de l'IP source à l'IP de destination — pour reconstituer l'histoire derrière vos transferts de données. Et cela ne s'arrête pas là :
Un moteur intelligent de détection d'AZ
Nous n'observons pas seulement le trafic — nous le comprenons. Notre moteur corrèle chaque IP avec les tables de routage cloud pour déterminer si la communication a lieu :
- Au sein d'une même AZ
- Entre deux AZ d'une même région
- Entre régions différentes
- Ou directement vers Internet (bonjour les frais d'egress !)
Si vos données s'échappent via des NAT gateways, des ELB ou d'autres intermédiaires réseau, nous les repérons également.
En résumé : en combinant les données uniques de notre sonde eBPF avec les éléments de coût du CUR, nous obtenons un coût inter-AZ précis, au niveau du workload, par connexion et par IP.
De l'analyse à l'action
Une fois le problème visible, nous vous aidons à le résoudre. Nous vous accompagnons dans l'évaluation des alternatives : co-localiser les services dans une même AZ, ajuster vos règles d'affinité Kubernetes, ou repenser vos flux.
Avec Attribute™, vous disposez de la visibilité, de la clarté et du contrôle nécessaires pour réduire les coûts inter-AZ inutiles — souvent de 50 à 80 %.
Faites le premier pas
On ne peut pas corriger ce que l'on ne voit pas.
Commencez par découvrir où va réellement votre trafic inter-AZ et pourquoi, puis passez à l'action pour en réduire le coût. Attribute™ vous accompagne de A à Z.
Réservez une démo avec nous et commencez à parler le langage des coûts réseau.