La première fois qu'un client m'a demandé de regarder sa facture AWS, j'ai foncé sur les suspects habituels. Lambdas qui s'emballent, RDS surdimensionnées, volumes EBS oubliés. J'ai trouvé quelques petites choses. La facture n'a pas bougé.
L'argent se cachait dans trois endroits que personne n'avait pris la peine de lire. J'ai vu ce schéma sur assez de factures pour parier que je trouverai au moins deux de ces trois lignes dans n'importe quel compte AWS au-dessus de 20 k$ par mois. Les voici.
1. Le transfert de données NAT Gateway
Le NAT Gateway a l'air innocent à 0,045 $ de l'heure. De la menue monnaie. Le piège, ce sont les 0,045 $ par gigaoctet traité par-dessus, qui scale linéairement avec le trafic et écrase silencieusement le coût horaire dès que vos sous-réseaux privés font quoi que ce soit.
Chaque sous-réseau privé qui tire des images Docker depuis ECR via l'endpoint public, chaque cron qui frappe une API externe, chaque microservice qui appelle S3 par fainéantise : tout cela accumule des frais au Go. Un seul NAT qui déplace 10 Go par jour coûte 13,50 $ par mois rien qu'en transfert, plus le forfait horaire. Multipliez par le trafic. Multipliez par les environnements. Multipliez par les AZ (parce qu'il en faut un par AZ pour la HA). La facture grossit là où personne ne regarde.
La tactique est mécanique : des VPC endpoints pour S3, ECR, DynamoDB et Secrets Manager. Les endpoints de type gateway sont gratuits. Ceux de type interface ont un coût horaire mais se remboursent vite sur du trafic réel. J'ai eu un client dont les seuls pulls ECR justifiaient la migration en huit jours.
2. ECS et EC2 inactifs
Toutes les organisations en ont. Le cluster « staging » d'un projet livré il y a deux ans. Le capacity provider avec un minimum de trois tâches que personne ne baisse. L'environnement dev monté pour une démo en 2023 et oublié.
ECS ne vous facture pas les tâches. Il vous facture l'EC2 sur lequel elles tournent, 24h/24, qu'on s'en serve ou pas. J'ai vu un client payer 1 800 $ par mois pour un cluster staging inactif qui n'avait pas reçu de déploiement depuis onze mois. Personne ne l'avait remarqué parce que la facture grossissait lentement.
La tactique : taguez chaque cluster avec un owner et un expires-on, faites tourner une Lambda hebdomadaire qui signale les ressources non taguées ou expirées, et envoyez le rapport dans le Slack de l'équipe. Un cron d'auto-suspension qui descend les clusters à zéro hors heures de bureau est encore mieux quand la latence le permet.
3. Transfert inter-AZ dans les service meshes
0,01 $ par gigaoctet, ça paraît rien. Puis votre service mesh fan-out 50 appels par requête à travers trois zones de disponibilité, et ce « rien » devient un quart de la facture compute.
La tactique : le routage zone-aware. La plupart des service meshes modernes le supportent. Gardez le trafic dans la même AZ quand une réplique locale saine existe. Pour les services bavards tolérants à la latence, on peut aller plus loin et épingler des services à une AZ unique, en ne basculant qu'en cas de panne réelle. Les économies écrasent souvent le temps d'ingénierie en un trimestre.
L'histoire que je raconte toujours
J'ai bossé avec une équipe qui n'avait pas vu sa facture grossir de 40 % sur trois mois. La croissance venait presque entièrement du transfert NAT Gateway d'un nouveau pipeline d'entraînement ML qui tirait des datasets sur l'internet public. Personne n'avait alerté parce que la hausse était lisse, pas en pic. La facture avait simplement grossi, comme font les factures.
La leçon : les anomalies de coût ne sont généralement pas des pics. Ce sont des pentes. Mettez vos alertes sur la dérivée, pas sur la valeur.
J'ai écrit tout un livre là-dessus si vous voulez la version longue : AWS Cost Optimization. La version courte est sur cette page.