FinOps : où se cachent vraiment vos coûts AWS

Quand on regarde une facture AWS pour la première fois, le réflexe est d’attaquer EC2 et RDS. C’est visible, c’est gros, c’est connu. Le problème, c’est qu’entre 30 et 50 % d’une facture AWS de PME se cache dans des postes annexes — invisibles dans les revues mensuelles, jamais discutés en architecture review, et pourtant éliminables en grande partie.

Cet article fait l’inventaire des postes que nous trouvons systématiquement en mission Distribuée, et donne les commandes AWS CLI pour les chasser.

La répartition réelle d’une facture

Sur ~150 audits cumulés sur des PME entre 5K€ et 100K€/mois, voici la répartition typique que nous observons :

Les postes en orange (data transfer, NAT, CloudWatch, ressources orphelines) représentent un tiers de la facture. C’est là qu’on récupère le plus, le plus vite.

Poste 1 — Data transfer, l’invisible champion

Le data transfer est facturé chaque fois qu’un octet sort d’une AZ, d’une VPC, d’une region, ou de l’Internet. La plupart des architectures n’ont jamais été optimisées sur ce critère parce que ça ne casse rien.

Les chemins les plus courants à corriger :

EC2 → S3 sans VPC endpoint : passe par NAT Gateway → Internet → S3. Facturé deux fois (NAT + egress). Avec un Gateway Endpoint, c’est gratuit.

EC2 → RDS cross-AZ : 0,01 $/GB en aller, 0,01 $/GB en retour. Sur une app verbeuse en SQL, c’est massif. Le fix : Multi-AZ pour la résilience, mais lectures préférentielles sur le replica de la même AZ.

Inter-region : 0,02 $/GB. Souvent dû à des architectures multi-region qui ne le justifient plus. Question simple : avez-vous vraiment besoin de cette region secondaire ?

Pour cartographier votre situation :

# Top des coûts data transfer du dernier mois, par usage type
aws ce get-cost-and-usage \
  --time-period Start=$(date -v-1m +%Y-%m-01),End=$(date +%Y-%m-01) \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"USAGE_TYPE_GROUP","Values":["EC2: Data Transfer"]}}' \
  --query 'ResultsByTime[].Groups[?Metrics.UnblendedCost.Amount>`50`].[Keys[0],Metrics.UnblendedCost.Amount]' \
  --output table

Poste 2 — NAT Gateway, le tueur silencieux

Le NAT Gateway coûte 0,045 $/h de baseline + 0,045 $/GB processed. Sur un VPC qui pousse 1 To/mois vers Internet, ça fait 45 $ + 32 $ (heures) = ~77 $/mois par NAT, par AZ.

Avec 3 AZ × 3 environnements × 2 régions, ça monte vite à plusieurs milliers d’euros par an pour rien.

Les fixes par ordre de gain :

1. VPC Gateway Endpoints pour S3 et DynamoDB (gratuits) : éliminent ~40 % du trafic NAT typique
2. VPC Interface Endpoints pour les services AWS (~7 $/mois par endpoint mais souvent rentable) : ECR, Secrets Manager, SSM, STS
3. Mutualiser un seul NAT par environnement quand la résilience cross-AZ n’est pas critique
4. NAT Instances pour les workloads non-prod (~5 $/mois)

# Lister tous les NAT Gateway et leur coût mensuel estimé
aws ec2 describe-nat-gateways \
  --filter "Name=state,Values=available" \
  --query 'NatGateways[].[NatGatewayId,SubnetId,Tags[?Key==`Name`].Value | [0]]' \
  --output table

Poste 3 — CloudWatch Logs, la dette silencieuse

CloudWatch facture sur trois axes :

• Ingestion : 0,50 $/GB
• Stockage : 0,03 $/GB/mois
• Insights queries : 0,005 $/GB scanné

Sur des workloads verbeux (Lambda en debug, ALB access logs sans retention policy), on voit régulièrement 200 à 800 €/mois en CloudWatch — la plupart pour des logs jamais consultés.

Les fixes :

1. Retention par défaut, pas “Never expire” : 30 jours pour la prod, 7 pour le staging, 1 pour le dev
2. Filtres d’ingestion sur les Lambda : suppression des logs DEBUG en prod
3. Subscription filter vers S3 pour les logs à conserver longtemps : 25× moins cher que CloudWatch
4. Athena sur les logs S3 au lieu de Logs Insights pour les analyses ponctuelles

# Trouver les log groups sans retention configurée
aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null`].[logGroupName,storedBytes]' \
  --output table

# Set retention 30 jours sur tous les log groups d'un préfixe
aws logs describe-log-groups \
  --log-group-name-prefix "/aws/lambda/" \
  --query 'logGroups[?retentionInDays==`null`].logGroupName' \
  --output text | xargs -n1 -I{} aws logs put-retention-policy \
  --log-group-name {} --retention-in-days 30

Poste 4 — Les ressources orphelines

Les “fantômes” qui coûtent un peu chacun mais qui s’accumulent. Sur un compte qui n’a pas été nettoyé depuis 2 ans, on récupère facilement 200 à 600 €/mois.

Snapshots EBS orphelins

Chaque snapshot coûte 0,05 $/GB/mois. Les snapshots de volumes supprimés depuis longtemps sont la première source de gâchis.

# Snapshots dont le volume source n'existe plus
aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?VolumeSize>`0`].[SnapshotId,VolumeId,VolumeSize,StartTime]' \
  --output text | while read snap_id vol_id size date; do
    if ! aws ec2 describe-volumes --volume-ids "$vol_id" >/dev/null 2>&1; then
      echo "ORPHAN: $snap_id ($size GB, créé $date)"
    fi
  done

Elastic IPs non attachées

0,005 $/h, soit 3,60 $/mois par EIP au repos. Sur un compte avec 30 EIP fantômes, c’est 100 €/mois.

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' \
  --output table

Load Balancers vides

Un ALB tourne à ~16 €/mois minimum, qu’il ait du trafic ou non. Quand on déprovisionne un environnement et qu’on oublie le LB…

# ALB sans target group sain
aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[].[LoadBalancerArn,LoadBalancerName,State.Code]' \
  --output text | while read arn name state; do
    targets=$(aws elbv2 describe-target-groups \
      --load-balancer-arn "$arn" \
      --query 'length(TargetGroups)' --output text)
    if [ "$targets" = "0" ]; then
      echo "EMPTY ALB: $name"
    fi
  done

Volumes EBS détachés

Un volume EBS détaché coûte le même prix qu’un volume attaché. C’est l’oubli classique après une migration.

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' \
  --output table

Poste 5 — Les bases de données mal-dimensionnées

Pas vraiment “caché”, mais souvent ignoré. RDS et OpenSearch ne sont pas couverts par Compute Optimizer dans toutes les configurations. Les sur-dimensionnements y sont fréquents.

Les questions à se poser :

• Est-ce que la prod tourne en Multi-AZ alors que c’est un workload non-critique ?
• Est-ce que le storage RDS est sur GP3 (40 % moins cher que GP2) ?
• Est-ce que les snapshots manuels datent de plus de 12 mois ?
• Est-ce que la rétention des automated backups est à 35 jours alors que 7 suffisent ?

La méthode de chasse mensuelle

Tout ce qui précède doit devenir une routine, pas un grand audit ponctuel. Notre script de chasse mensuelle, exécuté automatiquement (Lambda + Slack) :

C’est ça, le FinOps quotidien. Pas une grande opération une fois par an. Une discipline continue, automatisée, alertée.

Conclusion

Le compute est visible, le reste est sournois. Sur la majorité des comptes AWS de PME que nous auditons, les postes “cachés” représentent à eux seuls le salaire de 1 à 3 ingénieurs juniors par an. Cet argent n’est pas perdu pour AWS — il est dans votre facture.

Si vous voulez un audit complet de votre facture, avec un plan d’action chiffré et priorisé sur 30/60/90 jours, c’est exactement ce que nous faisons sur la mission Audit Architecture & DevSecOps.