Retour aux ressources
// finops · coûts cachés

Les 5 lignes qui plombent ta facture

Ce ne sont jamais les EC2 qui surprennent — c'est ce qu'il y a autour. Voici les cinq postes que je retrouve gonflés sur presque chaque audit, et qui saignent une facture sans que personne ne les regarde.

Technique16 juil. 2026~7 min · intermédiaire
NAT GatewayData transferEBSsnapshotsCloudWatch
01

Le classement

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.

NAT Gateway
$1,350
Egress (sortie)
$980
Snapshots oubliés
$640
EBS surdimensionné
$520
Logs CloudWatch
$410
02

Pourquoi elles gonflent

01
NAT Gateway

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.

02
Egress

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.

03
Snapshots

Chaque backup automatique s'empile et n'expire jamais tout seul. Sans politique de rétention, tu paies des années de sauvegardes mortes.

04
EBS & logs

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.

03

Les correctifs

NATVPC Endpoints pour S3/DynamoDB ; 1 seul NAT partagé si le débit le permet
egressCloudFront devant tout ce qui est public ; éviter le cross-AZ inutile
snapshotsDLM (Data Lifecycle Manager) : rétention 7/30 jours automatique
EBSgp3 au lieu de gp2, taille au réel, supprimer les volumes détachés
logsexpiration des log groups + export S3/Glacier pour l’archive
!

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.

04

La topologie qui coupe le NAT

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 ».

Les gateway endpoints : gratuits, et c'est là que je commence

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.

S3 / DynamoDBGateway endpoint — gratuit, court-circuite le NAT, une route à ajouter
ECR / Secrets / SSMInterface endpoint (PrivateLink) — payant à l'heure + au Go, mais souvent < NAT si le volume est là
Inter-AZColocaliser les services qui se parlent ; le cross-AZ est facturé dans les deux sens
Public / statiqueCloudFront devant : le cache absorbe l'egress et il est moins cher que la sortie directe

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.

05

Stockage et logs : les gains silencieux

gp2 → gp3 : 20 % en une commande, sans downtime

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.

Logs CloudWatch : la rétention infinie est le vrai coût

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.

set-retention.shcopier
# Poser une rétention 30j sur tous les log groups qui n'en ont pas
# Set 30-day retention on every log group that has none
aws logs describe-log-groups \
--query "logGroups[?retentionInDays==null].logGroupName" \
--output text | tr '\t' '\n' | while read lg; do
aws logs put-retention-policy \
--log-group-name "\${lg}" \
--retention-in-days 30
done

Le garde-fou qui rattrape ce que tu n'as pas anticipé

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.

06

Sources & ressources

01AWS — Gateway endpoints (S3 & DynamoDB)Doc officielle : les gateway endpoints court-circuitent le NAT et sont gratuits. La base pour couper l'egress inutile.02AWS Storage Blog — Migrate EBS gp2 to gp3 (save up to 20%)Le chiffrage du gain gp2→gp3, l'exemple 2 To/1 To et la migration à chaud via Elastic Volumes.03AWS — Migrate EBS volumes from gp2 to gp3 (Prescriptive Guidance)Le guide pas-à-pas pour migrer en masse, avec le calculateur d'économies EBS.04AWS — Analyzing, optimizing, and reducing CloudWatch costsRétention, classe Infrequent Access, ingestion : où le coût des logs se cache et comment le tailler.05AWS — Detecting unusual spend with Cost Anomaly DetectionLe garde-fou ML gratuit : alertes e-mail/SNS, cause classée par service/compte/région.06AWS — Automate EBS snapshots with Data Lifecycle ManagerDLM : politiques de rétention automatiques pour ne plus payer des années de snapshots morts. Gratuit.07AWS — Amazon VPC pricing (data transfer)Le barème NAT (horaire + par Go traité) et les tarifs de transfert : la référence pour chiffrer chaque leak.

Ces cinq lignes ne font pas la une de ta facture, mais mises bout à bout elles pèsent souvent plus que le calcul lui-même. Les traquer une fois, poser les garde-fous, et elles ne reviennent plus. Le playbook complet est ici : [diviser une facture AWS par deux](art:finops-cut).