Si tu es dev, tu connais déjà le scénario. Tu déploies un truc vite fait. Une stack “simple”. Un peu de Lambda, un bucket S3, une base RDS “petite”. Tu oublies, tu bosses sur autre chose. Puis un matin, AWS t’envoie une facture qui ressemble à une blague interne. Sauf que non.
FinOps, c’est juste ça au fond : arrêter de piloter le cloud au feeling. Et apprendre à lire une facture comme on lit des logs. Calmement. Avec méthode. Et un soupçon de méfiance.
Dans cet article, je te montre comment décoder une facture AWS sans te faire mal. Pas la théorie en mode cabinet de conseil. Plutôt une lecture “dev friendly”.
Pourquoi une facture AWS paraît toujours “injuste”
Parce que la facture n’est pas une ligne “serveur : 20 €”. C’est un empilement de micro services facturés chacun à sa sauce : à l’heure, à la seconde, au Go stocké, au Go transféré, au million de requêtes, au nombre de journaux ingérés. Et parfois… au fait que tu as simplement laissé tourner un truc.
Et puis AWS segmente tout par : compte, région, service, type d’usage, tag. Donc sans structure, tu regardes une soupe.
Objectif FinOps minimal pour un dev : être capable de répondre à 3 questions.
- Qu’est ce qui coûte le plus cher, et où ?
- Est ce que c’est “normal” ou “accidentel” ?
- Quelle action simple réduit le coût sans casser le produit ?
La méthode rapide pour lire ta facture, dans le bon ordre
Ne commence pas par le PDF. Sérieux. Commence par Billing and Cost Management, puis :
- Cost Explorer
- Bills
- CUR (Cost and Usage Report) si tu veux vraiment l’autopsie
1) Cost Explorer : la vue “ça saigne où ?”
Dans Cost Explorer, mets :
- plage : “Last 30 days”
- group by : “Service”
- puis clique le plus gros service, et regroupe par “Usage type”
Tu vas souvent tomber sur un de ces classiques :
- EC2 : instances oubliées, EBS, snapshots
- RDS : instance surdimensionnée, stockage, I/O
- NAT Gateway : la surprise préférée de tout le monde
- CloudWatch : logs ingérés, métriques, alarms
- S3 : stockage + requêtes + data transfer
- Data transfer : surtout inter AZ ou sortie vers internet
Petit réflexe dev : regarde la courbe. Un coût stable, ok. Un pic brutal, c’est souvent un bug, un trafic, une boucle, un job qui s’est emballé.
2) Bills : la facture “ligne par ligne”
Onglet Bills, sélectionne le mois, puis déroule service par service. Ici, tu vois les sous postes exacts, et c’est là que tu identifies le vrai coupable.
Exemples de lignes qui doivent te faire tiquer.
- EC2 Other : souvent EBS, IPs élastiques, NAT, data transfer. Le “Other” est un nid à surprises.
- S3 Requests : quand une appli fait des LIST ou des GET en boucle.
- CloudWatch Logs : ingestion élevée, retention trop longue.
- Lambda : rarement énorme, sauf si tu as du volume ou des timeouts longs.
- ECR : images non nettoyées, stockage qui gonfle.
Tu veux un hack simple ? Clique sur la région. Beaucoup de coûts “incompréhensibles” deviennent clairs dès que tu vois : “ah, c’est en us east 1 alors que tout le reste est en eu west 3”.
Les 6 pièges AWS qui font pleurer, et quoi vérifier tout de suite
NAT gateway : le tueur silencieux
Le NAT Gateway facture :
- par heure
- par Go traité
Donc si tu as des subnets privés qui sortent vers internet pour apt, pip, npm, téléchargements, mises à jour… ça grimpe vite.
Actions rapides :
- ajouter des VPC endpoints (S3, ECR, CloudWatch, etc.)
- limiter les sorties, ou passer certains workloads en public subnet si c’est acceptable (à sécuriser, évidemment)
- surveiller “ProcessedBytes”
CloudWatch logs : “juste des logs”, jusqu’à la facture
Ingestion, stockage, requêtes. Et surtout retention. Beaucoup laissent “Never expire”.
Actions rapides :
- fixer une retention par défaut (7 ou 14 jours souvent)
- filtrer le bruit
- éviter de logger des payloads énormes en prod
EBS et snapshots : l’ombre d’EC2
Tu supprimes une instance, tu oublies un volume. Ou tu gardes des snapshots automatiques sans politique.
Actions rapides :
- lister volumes “available”
- mettre une lifecycle policy
- vérifier gp2 vs gp3, et les tailles
Data transfer : la ligne que personne ne lit
Sortie vers internet coûte. Inter AZ coûte. CloudFront peut aider, mais encore faut il l’avoir.
Actions rapides :
- vérifier si ton ALB parle à des targets dans une autre AZ inutilement
- coller compute et data ensemble (même région, même AZ si pertinent)
- activer compression, cache, CDN
RDS “trop prudent”
Le classique : db.t3.medium pour un produit qui ferait tourner sur une micro. Et stockage provisionné trop large.
Actions rapides :
- regarder CPU, connections, free storage
- passer sur une taille plus petite
- envisager Aurora Serverless v2 si usage très variable (à étudier, pas automatique)
S3 : stockage cheap, requêtes pas toujours
S3 Standard, ça va. Mais les requêtes répétées, la mauvaise classe de stockage, ou les transferts sortants… ça pique.
Actions rapides :
- activer l’analyse Storage Lens
- lifecycle vers IA, Glacier si pertinent
- mettre CloudFront devant un bucket public
Tags : le geste FinOps le plus rentable (et le plus ignoré)
Si tu ne tags pas, tu ne sais pas qui paie quoi. Et tu finis par couper des trucs au hasard.
Minimum vital :
appenv(prod, staging, dev)ownercost-centerouteam
Puis dans Billing :
- activer Cost Allocation Tags
- imposer des tags via IaC (Terraform, CDK, CloudFormation)
- refuser les ressources non taguées (policies, checks CI)
Oui, c’est relou au début. Mais après, Cost Explorer devient lisible. Et tu peux dire : “l’environnement staging coûte 38 % du total”, ce qui est une info exploitable.
Le kit de survie FinOps pour devs (sans devenir contrôleur de gestion)
- activer AWS Budgets avec alertes email
- activer Anomaly Detection
- faire un point hebdo de 10 minutes : top 3 services, top 3 régions, variation vs semaine dernière
- documenter une “baseline” : ce que coûte un environnement normal
- ajouter un check “cost” dans la review infra : instance size, NAT, logs retention
Si tu veux, je peux aussi publier sur Le Blog Tech Pro de Samyn-Antoy ABASSE une petite checklist téléchargeable “avant de mettre en prod” avec les 20 réglages qui évitent 80 % des mauvaises surprises. Tu peux garder le lien du site sous la main : https://monblog-sa-abasse.blogspot.com
Conclusion : lire la facture comme un outil, pas comme une punition
Une facture AWS, ce n’est pas un jugement moral sur ton code. C’est un diagnostic. Tu identifies le service, tu descends au usage type, tu retrouves la ressource, tu poses une action simple.
Et la prochaine fois que quelqu’un dit : « le cloud coûte cher », tu peux répondre calmement : « non, le cloud facture ce qu’on oublie ».
Questions fréquemment posées
Pourquoi ma facture AWS semble-t-elle toujours injuste ou difficile à comprendre ?
Parce que la facture AWS est un empilement complexe de micro services facturés chacun différemment : à l'heure, à la seconde, au Go stocké, aux millions de requêtes, etc. De plus, AWS segmente les coûts par compte, région, service, type d'usage et tag, ce qui rend la facture difficile à lire sans structure claire.
Quelles sont les trois questions clés à se poser pour gérer efficacement ses coûts AWS en tant que développeur ?
- Qu'est-ce qui coûte le plus cher et où ? 2) Est-ce que ce coût est normal ou accidentel ? 3) Quelle action simple puis-je prendre pour réduire ce coût sans casser le produit ?
Quelle est la méthode recommandée pour lire une facture AWS de manière efficace ?
Ne commencez pas par le PDF. Utilisez plutôt l'interface Billing and Cost Management d'AWS en suivant cet ordre : 1) Cost Explorer pour identifier où ça coûte le plus, 2) Bills pour analyser la facture ligne par ligne, et 3) CUR (Cost and Usage Report) si vous souhaitez une analyse approfondie.
Quels sont les services AWS les plus souvent responsables des coûts élevés inattendus ?
Les coupables classiques incluent EC2 (instances oubliées, EBS, snapshots), RDS (instances surdimensionnées, stockage), NAT Gateway (facturation par heure et Go traité), CloudWatch (logs ingérés et métriques), S3 (stockage et transferts), ainsi que les transferts de données inter-AZ ou vers internet.
Pourquoi le NAT Gateway peut-il devenir un tueur silencieux dans ma facture AWS et comment limiter ses coûts ?
Le NAT Gateway est facturé à la fois à l'heure et par Go traité. Si vos subnets privés sortent fréquemment vers internet pour des mises à jour ou téléchargements, cela peut faire grimper la facture rapidement. Pour limiter ces coûts : ajoutez des VPC endpoints (pour S3, ECR, CloudWatch...), limitez les sorties internet ou déplacez certains workloads en subnet public avec une bonne sécurisation.
Comment détecter rapidement un problème de coût lié aux logs CloudWatch dans ma facture AWS ?
Surveillez l'ingestion élevée de logs ainsi que la durée de rétention trop longue qui peuvent faire exploser les coûts. Dans l'onglet Bills d'AWS, vérifiez les lignes liées à CloudWatch Logs ; un volume important d'ingestion ou un stockage prolongé sont souvent responsables d'une facture élevée.
0 Commentaires