Si vous êtes responsable d’une facture AWS et voulez apprendre une pointe de dépense des jours avant la facture, AWS Cost Anomaly Detection est l’outil à configurer, et ça prend une quinzaine de minutes. Le service est gratuit. Il apprend votre dépense habituelle pour chaque service AWS et signale les journées qui sortent du modèle. Le problème courant, c’est que personne n’entend l’alerte. Un moniteur est créé une fois, ses alertes partent vers une boîte courriel que personne ne lit, et la pointe apparaît sur la facture de fin de mois.
La configuration qui fonctionne tient en trois gestes. Créez un moniteur qui surveille tous les services AWS du compte. Envoyez les alertes individuelles vers Amazon SNS (Simple Notification Service), qui les relaie vers Slack, Teams ou votre outil de garde. Fixez ensuite un seuil en dollars assez élevé pour que chaque alerte vaille la peine de déranger quelqu’un. Comptez environ une journée avant l’alerte, parce que les données de facturation AWS arrivent avec un délai.
Ce qui se passe
Cost Anomaly Detection entraîne un modèle sur votre dépense historique par segment et signale les écarts au-dessus du patron appris — il attrape « l’inhabituel pour vous », ce que les seuils fixes de budget ne peuvent pas, parce qu’il s’adapte aux cycles hebdomadaires et à la croissance graduelle. Trois mécaniques façonnent la configuration.
Les moniteurs définissent la segmentation. Un moniteur AWS services modélise chaque service indépendamment et est le défaut recommandé — un par compte, et il évalue tous les services sans autre configuration. Les moniteurs personnalisés segmentent plutôt par compte lié, catégorie de coûts ou étiquette de répartition; ils ont du sens dans une Organization où des équipes différentes doivent recevoir des alertes différentes, mais ils analysent la dépense totale par segment plutôt que par service — des instruments plus grossiers.
Les abonnements définissent qui l’apprend. Les alertes individuelles partent au fil des détections et peuvent livrer vers SNS (c’est ainsi qu’on rejoint Slack, Teams ou PagerDuty); les sommaires quotidiens et hebdomadaires livrent par courriel seulement. Le seuil d’un abonnement — impact en dollars absolus, en pourcentage, ou une combinaison — est votre valve à bruit.
La détection n’est pas instantanée. Le service évalue après l’ingestion des données de facturation, quelques fois par jour environ, et les données elles-mêmes retardent. Attendez-vous à apprendre une pointe dans la journée qui suit son début, parfois plus vite. Un compte tout neuf ou un service tout neuf a aussi besoin d’un peu d’historique avant que le modèle ait une base de référence.
Quoi vérifier en premier
- Un moniteur existe-t-il déjà? Les comptes en ont souvent un, créé en explorant la console, abonné à une boîte que personne ne lit.
- Où atterrissent les alertes aujourd’hui? Une alerte qui tombe dans une boîte de courriel personnelle est une décoration.
- Utilisez-vous Organizations? Configurez dans le compte de gestion (ou l’admin délégué) pour couvrir les comptes membres, et décidez si les équipes ont besoin de leur propre segmentation.
- Quel impact en dollars vaut une interruption? Choisissez le chiffre avant que la console vous le demande.
Comment vérifier
# Quels moniteurs existent en ce moment?
aws ce get-anomaly-monitors
# Qu'est-ce qui a été signalé dans les 30 derniers jours?
aws ce get-anomalies \
--date-interval StartDate=2026-06-04,EndDate=2026-07-04Chemin console : Billing and Cost Management > Cost Anomaly Detection. L’onglet Detection history est la vérification de santé la plus rapide — un historique rempli sans abonnement veut dire que l’outil travaillait en silence et que personne n’a branché la sortie.
Le plan d’exécution
-
Créez le moniteur AWS services. Console : Cost Anomaly Detection > Cost monitors > Create monitor > AWS services. Ou en CLI :
aws ce create-anomaly-monitor \ --anomaly-monitor '{"MonitorName":"account-services","MonitorType":"DIMENSIONAL","MonitorDimension":"SERVICE"}' -
Créez un abonnement en alertes individuelles vers SNS. SNS est le point d’intégration pour tout ce qui avertit. Le seuil ci-dessous est « alerter quand l’impact total de l’anomalie atteint 100 $ » — mettez le vôtre au chiffre qui vaut une interruption :
aws ce create-anomaly-subscription \ --anomaly-subscription '{"SubscriptionName":"anomaly-individual","MonitorArnList":["<monitor-arn>"],"Subscribers":[{"Type":"SNS","Address":"arn:aws:sns:us-east-1:111111111111:cost-anomalies"}],"Frequency":"IMMEDIATE","ThresholdExpression":{"Dimensions":{"Key":"ANOMALY_TOTAL_IMPACT_ABSOLUTE","MatchOptions":["GREATER_THAN_OR_EQUAL"],"Values":["100"]}}}'Le sujet SNS a besoin d’une politique de ressource qui permet à
costalerts.amazonaws.comde publier — le parcours console offre de la configurer; en CLI, vous écrivez la politique du sujet vous-même. -
Ajoutez un sommaire hebdomadaire par courriel comme filet. Un deuxième abonnement, fréquence hebdomadaire, vers une boîte partagée. Il attrape les anomalies à combustion lente qui restent sous le seuil des alertes individuelles.
-
Branchez SNS dans le chemin de garde. Même patron que les alarmes CloudWatch — la plomberie de livraison que vous utilisez déjà pour la base d’alarmes CloudWatch est aussi la bonne destination ici. Une anomalie de coûts est un événement opérationnel; acheminez-la comme tel.
-
Exécutez le plan de réponse quand ça sonne. L’alerte nomme le service, le compte et les types d’usage contributeurs — c’est la longueur d’avance. Le reste est la même séquence de 60 minutes que dans le triage de pointe de facture. Marquez les vrais événements comme tels et les faux positifs comme faux dans l’historique de détection; la rétroaction est conservée avec l’anomalie.
-
Revoyez le seuil après un mois. Plus de deux ou trois alertes par semaine, c’est un seuil qui entraîne les gens à l’ignorer — montez-le, ou passez à une combinaison pourcentage plus absolu.
Quand c’est la mauvaise approche
La détection d’anomalies attrape les écarts au patron; elle ne signalera jamais une dépense qui a toujours été du gaspillage — un parc surdimensionné stable est « normal » pour le modèle. C’est aussi le mauvais contrôle unique pour des plafonds fermes : elle n’a pas de bras d’application. Jumelez-la avec AWS Budgets pour l’alerte à seuil et la prévision; les deux outils se recoupent moins qu’il n’y paraît. Les détails de la famille d’outils sont dans la documentation AWS Cost Management.
Erreurs courantes
- Des abonnements courriel seulement. Les alertes individuelles vers SNS sont le seul chemin qui atteint un canal surveillé en quasi temps réel.
- Un seuil symbolique. La première semaine d’alertes à petits montants finit en filtre de courriel, et l’outil est mort dans l’organisation.
- Configuré dans un seul compte membre. Les moniteurs voient le compte où ils vivent; la couverture d’Organization vient du compte de gestion ou de l’admin délégué.
- S’attendre à attraper une fuite dans l’heure. La latence des données en fait un contrôle à l’échelle du jour; la protection en direct, ce sont les limites de capacité et la revue de code, pas la télémétrie de facturation.
Prévention
- Testez le chemin SNS de bout en bout à la création — publiez un message d’essai et confirmez qu’il atterrit dans le canal.
- Revérifiez les abonnements quand des gens partent; les abonnés courriel orphelins sont la panne silencieuse la plus courante.
- Ajoutez la création du moniteur et de l’abonnement à votre gabarit de base de compte, pour que les nouveaux comptes naissent couverts.
- Revisitez les seuils chaque trimestre à mesure que la dépense grossit; un seuil taillé pour la facture de l’an dernier devient du bruit ou de l’aveuglement un an plus tard.
Quinze minutes de configuration vous achètent un système où la prochaine tâche emballée est un message Slack du mardi matin au lieu d’une revue d’incident de fin de mois. 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.