Aller au contenu

AWS Mis à jour le 2026-07-04

Facture AWS trop élevée? Un triage de 60 minutes pour trouver où l'argent est passé

Quand une facture AWS est soudainement trop élevée, la cause se trouve en une heure environ avec Cost Explorer, les types d'usage et la granularité quotidienne. Voici la séquence de triage exacte des opérateurs.

Une facture AWS qui a bondi, c’est presque toujours un ou deux postes, pas une dérive générale — et Cost Explorer peut les nommer en moins d’une heure. La séquence : comparer ce mois-ci au mois dernier groupé par service, creuser le poste qui a bougé jusqu’au type d’usage, passer en granularité quotidienne pour trouver le jour où ça a commencé, puis croiser cette date avec ce qui a changé — un déploiement, une nouvelle charge, une fuite ou un rabais expiré. Résistez à l’envie d’éteindre des choses avant de savoir quel poste a bougé.

Ce qui se passe

Une facture AWS, ce sont des milliers de postes mesurés, agrégés par service. Quand le total bondit, c’est l’une de ces causes courtes : une charge a grossi (plus d’heures d’instance, plus de requêtes), un chemin de données est devenu coûteux (traitement NAT Gateway, transfert inter-AZ ou sortant, tempêtes d’API S3), du stockage s’est accumulé au-delà du seuil où on le remarque (instantanés, journaux, compartiments versionnés), un engagement a expiré (Savings Plan ou RI échu et le même usage repayé à la demande), ou quelque chose a été créé puis oublié (un deuxième environnement, une instance GPU inactive, un test de charge laissé en marche). Des identifiants compromis qui minent de la cryptomonnaie produisent la même signature qu’une charge qui a grossi — de gros frais EC2 ou SageMaker dans des régions que vous n’utilisez pas — donc le triage ci-dessous vérifie explicitement les régions.

Deux mécaniques de facturation comptent ici. D’abord, les données de Cost Explorer retardent d’environ 24 heures : la fuite d’aujourd’hui apparaît demain. Ensuite, le coût non fusionné (unblended) montre les achats d’engagements comme des pointes à la date d’achat; si quelqu’un a acheté une RI avec paiement initial, la « pointe » est peut-être le rabais, pas un problème — vérifiez la vue amortie avant de paniquer.

Quoi vérifier en premier

  • Quel service a bougé? Une comparaison groupée répond en deux minutes.
  • Quand ça a commencé? La granularité quotidienne transforme « ce mois-ci est élevé » en « ça a commencé le 14 juin ».
  • Quelle région? Des frais dans des régions où vous n’opérez pas pointent vers une fuite ou une compromission.
  • Un engagement a-t-il expiré? Même usage, tarif plus élevé, aucun déploiement à blâmer.
  • Est-ce un seul compte? Si vous utilisez Organizations, groupez d’abord par compte lié.

Comment vérifier

La console d’abord : Billing and Cost Management > Cost Explorer, plage couvrant le mois dernier et ce mois-ci, granularité Monthly, Group by: Service. Le poste qui a bougé saute habituellement aux yeux. Ensuite, filtrez sur ce service et passez à Group by: Usage Type — le type d’usage nomme le mécanisme (NatGateway-Bytes = traitement de données, USW2-BoxUsage:m5.xlarge = heures d’instance en Oregon, TimedStorage-ByteHrs = stockage S3). La même chose en ligne de commande :

# Mois sur mois par service — trouver le poste qui a bougé
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Creuser jusqu'au type d'usage, en quotidien — trouver la date de départ
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity DAILY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

# Quelque chose tourne-t-il dans des régions que vous n'utilisez pas?
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=REGION

Pour la date de départ, croisez avec CloudTrail : CloudTrail > Event history, filtré sur le jour où la courbe a plié, vous dit ce qui a été lancé et par qui.

Le plan d’exécution

  1. Groupez par service, mois sur mois (10 minutes). Un service en forte hausse est une piste; tout en hausse proportionnelle suggère une croissance de trafic ou un rabais expiré, pas une fuite.
  2. Creusez jusqu’au type d’usage (10 minutes). Ça sépare « plus d’instances » de « plus de traitement de données » de « plus de stockage » — trois correctifs différents. Les types d’usage de transfert et de NAT sont là où vivent les surprises; la mécanique de sortie est couverte dans NAT Gateway vs instance NAT.
  3. Passez en granularité quotidienne (5 minutes). Trouvez le jour exact où la courbe a plié. Une marche nette = quelque chose a été lancé ou a planté; une rampe = accumulation (stockage, journaux) ou croissance organique.
  4. Croisez la date avec un changement (15 minutes). Journal de déploiement, historique CloudTrail, clavardage d’équipe. Un test de charge, un nouvel environnement, une tempête de reprises après un mauvais déploiement, une tâche cron devenue folle — la date nomme presque toujours le coupable.
  5. Vérifiez les engagements si rien n’a changé (10 minutes). Billing and Cost Management > Savings Plans et les pages RI montrent les dates d’expiration. Un engagement expiré repaye le même usage à la demande — le correctif est une décision de renouvellement, couverte dans RI, Savings Plans, Spot et à la demande.
  6. Vérifiez la compromission si la région ou le service est étranger (10 minutes). Du gros calcul dans des régions inutilisées, du SageMaker ou de l’ECS jamais activé : faites tourner les clés exposées immédiatement, terminez les ressources, puis ouvrez un dossier — le soutien AWS gère la remédiation des comptes compromis et, au cas par cas, les demandes d’ajustement de facturation pour compromission vérifiée.

Quand c’est la mauvaise approche

Si la facture est élevée mais l’est depuis des mois, ce n’est pas un triage de pointe — c’est un problème de coût structurel, et le travail de réduction levier par levier est un exercice différent. Et si la pointe s’explique par une vraie croissance de clientèle, la réponse est l’économie unitaire et la couverture d’engagements, pas la coupe; ne bridez pas un produit en croissance pour aplatir un graphique.

Erreurs courantes

  • Éteindre des choses avant d’identifier le poste. Vous risquez une panne et la facture reste élevée parce que vous avez mal deviné.
  • Lire le coût non fusionné un mois d’achat d’engagement. Le paiement initial ressemble à une pointe; la vue amortie est la vue honnête.
  • Ignorer les régions. Cost Explorer affiche toutes les régions par défaut, mais on filtre mentalement sur la sienne — la fuite est souvent ailleurs.
  • S’arrêter au niveau du service. « EC2 a monté » n’est pas un diagnostic; le type d’usage, oui.

Prévention

  • Activez Cost Anomaly Detection — il existe précisément pour que ce triage arrive au jour deux, pas à la facture.
  • Configurez des alertes AWS Budgets à 80 % du réel et 100 % de la prévision pour que les dépassements de mi-mois avertissent quelqu’un.
  • Étiquetez les charges pour qu’une pointe se rattache à un propriétaire en un clic.
  • Mettez les dates d’expiration d’engagements au calendrier d’équipe, un mois d’avance.
  • Lisez une fois la documentation AWS Cost Management — connaître la différence entre coût non fusionné et amorti évite deux des fausses alertes ci-dessus.

Une heure concentrée trouve la cause de presque toutes les pointes de facture, et la même heure répétée chaque mois empêche la prochaine de vous surprendre. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.