Ordre de grandeur d'un audit typique sur une infra de scale-up : la part mensuelle de chaque coût caché, une fois isolée du reste.
Facturé à l'heure ET au Go traité. Chaque appel d'une instance privée vers Internet passe par là. Un VPC Endpoint pour S3/DynamoDB court-circuite le NAT — et le coût.
Sortir des données d'AWS coûte cher ; entre régions ou AZ aussi. Sers les assets par CloudFront et garde le trafic dans une seule AZ quand tu peux.
Chaque backup automatique s'empile et n'expire jamais tout seul. Sans politique de rétention, tu paies des années de sauvegardes mortes.
Des volumes provisionnés à 500 Go utilisés à 40, des logs en rétention infinie. On dimensionne au réel et on met une expiration.
Le NAT Gateway est le piège numéro un : invisible dans « EC2 », il peut dépasser le coût de tes instances. C'est toujours la première ligne que je vais chercher.
Le NAT Gateway ne coûte pas cher parce qu'il est allumé — il coûte cher parce que tout le trafic sortant d'un subnet privé le traverse, et qu'on paie 0,045 $ à l'heure PLUS 0,045 $ par Go traité. Chaque `GET` vers S3, chaque requête DynamoDB, chaque `docker pull` d'une instance privée s'additionne. La question n'est donc pas « comment payer le NAT moins cher » mais « quel trafic n'a rien à y faire ».
S3 et DynamoDB proposent des gateway endpoints qui injectent une route dans ta table de routage et court-circuitent complètement le NAT — sans passerelle Internet, sans device NAT. Et l'argument massue : `There is no additional charge for using gateway endpoints`. Zéro frais horaire, zéro frais au Go. Sur une infra data-heavy qui lit des téraoctets de S3 depuis des subnets privés, ce seul changement fait tomber la ligne NAT de plusieurs centaines de dollars par mois. C'est la première chose que je pose sur un audit, parce que le rapport effort/gain est indécent.
Piège classique : le gateway endpoint est régional. Si ton instance en eu-west-1 lit un bucket en us-east-1, le trafic repasse par le NAT et par l'egress inter-région. Garde les buckets et les tables dans la même région que le VPC, sinon l'endpoint ne sert à rien.
Pour ECR, Secrets Manager, SSM ou les API AWS internes, ce sont des interface endpoints (PrivateLink) — eux sont facturés, mais dès qu'un cluster tire ses images toute la journée, le coût de l'endpoint reste sous celui du NAT qu'il remplace. Je fais toujours le calcul avant : volume mensuel × 0,045 $ côté NAT, versus le forfait horaire de l'endpoint. En dessous d'un certain débit, garder le NAT reste plus malin.
Le gp3 coûte jusqu'à 20 % moins cher par Go que le gp2, avec un baseline garanti de 3 000 IOPS et 125 Mio/s quelle que soit la taille. Le vrai levier est là : sur du gp2, on surdimensionne le volume juste pour gratter des IOPS (l'IOPS est liée à la taille). Sur du gp3, on découple IOPS et débit du stockage — donc on peut souvent réduire la taille en gardant la perf. AWS donne l'exemple d'un volume gp2 de 2 To à 200 $/mois remplacé par un gp3 de 1 To à performance équivalente pour 100 $ : 50 % de moins, pas 20. La migration passe par Elastic Volumes, à chaud, sans détacher ni redémarrer l'instance.
Ma règle : tout nouveau volume naît en gp3, et je batch-migre l'existant. Le seul cas où je ralentis, c'est un volume qui dépasse déjà 16 000 IOPS provisionnées — là il faut recalculer, sinon le gp3 par défaut sous-performe.
Par défaut, un log group garde ses logs pour toujours — personne ne coche cette case à la création, et c'est exactement le problème. Deux leviers : d'abord poser une rétention sur CHAQUE log group (7, 30, 90 jours selon l'usage), ensuite basculer les groupes éligibles vers la classe Infrequent Access, qui divise par deux le prix d'ingestion (0,25 $/Go contre 0,50 $/Go en Standard). Depuis début 2026, l'IA supporte les requêtes Logs Insights complètes, donc pour des logs applicatifs qui n'ont pas besoin de metric filters temps réel, c'est le défaut que je recommande.
Snapshots, volumes détachés, log groups sans rétention : on peut tous les traquer une fois. Mais le prochain leak, il vient de ce qu'on ne surveille pas encore. J'active donc AWS Cost Anomaly Detection, qui applique un modèle ML sur le coût net et alerte par e-mail ou SNS (relayable dans Slack) dès qu'un poste dérape, en classant la cause par service, compte, région ou usage type. C'est gratuit, ça tourne ~3 fois par jour, il faut ~10 jours d'historique pour calibrer. Un seul angle mort à connaître : les produits Marketplace, dont les LLM tiers sur Bedrock, ne sont pas couverts — pour ça, un AWS Budget prend le relais.
Un arbre de décision selon la charge, le budget et la taille de ton équipe — pas la hype.
De « ça marche chez moi » à reproductible et observable : IaC, CI/CD, health checks, rollback.