Coûts de transert data entre VPCs AWS qui explosent

yo t'as des NAT Gateway dans tes VPCs ? si tes instances communiquent via NAT Gateway au lieu de passer par le peering direct, ça peut générer du coût inter-AZ et inter-VPC même si elles sont dans la même région. vérifie tes tables de routage

ouaip la nat gateway c un piège. si tu as des sous-réseaux privés qui veulent aller vers d'autres vpcs peerés mais que leur route par défaut pointe vers la nat gateway, c direct la douille financière. la route pour le vpc peeré doit être plus spécifique

on a des NAT Gateway oui pour l'internet sortant mais j'ai des routes spécifiques pour les peerings. genre 10.1.0.0/16 via pcx-xxxxxx dans le VPC A. c'est ce que je comprends pas

même avec une route spécifique il faut que l'instance ait bien un chemin direct. si t'as des security groups trop restrictifs qui bloquent le trafic direct sur le peering et forcent un fallback (genre proxy ou autre qui lui passerait par la NAT), ça peut aussi créer du détournement

et t'es sûr que t'as pas des services de type endpoint (VPC Endpoints) qui sont mal configurés et forcent le trafic vers S3 ou DynamoDB via l'internet gateway ou la NAT ? ça arrive si tu oublies d'attacher la policy de l'endpoint

autre point t'utilises des load balancers ? si un ALB ou NLB est configuré dans un VPC et ses targets sont dans un VPC peeré, le trafic entre le LB et les targets est aussi facturé. et si le LB est public et les targets privées ça double le transfert

ah les load balancers ! on a un nouveau service qui est déployé avec un ALB dans VPC A et des targets dans VPC B. je pensais que c'était transparent via le peering

non le trafic entre un ALB et ses cibles est facturé même s'ils sont dans le même VPC si c'est inter-AZ. et si c'est inter-VPC (même peeré) c'est encore pire. c'est la "cross-AZ data transfer" et "inter-VPC data transfer" qui se cumulent

le meilleur moyen de réduire ça c'est de mettre le LB et les targets dans le même VPC si possible et dans la même AZ. ou si vraiment tu peux pas grouper les VPCs essaye de voir si un Transit Gateway serait pas plus avantageux sur le long terme que des peerings multiples, parfois ça consolide mieux les coûts

ok je crois que j'ai trouvé le coupable alors. l'ALB et les targets. on va essayer de regrouper les cibles dans le même VPC que l'ALB et si possible dans les mêmes AZs pour minimiser. thx pour les infos c'est super utile !

je vais aussi re-auditer toutes les tables de routage et les security groups pour s'assurer que rien ne passe par les NAT Gateways inutilement. le transit gateway on y pense pour l'avenir mais là c'est du court terme qui me fallait. encore merci !