Alerte de facturation AWS Free Tier : ne jamais dépasser 5 $ avec CloudWatch

Le Free Tier AWS est généreux sur le papier, mais il suffit d'une instance EC2 oubliée ou d'un transfert de données inattendu pour recevoir une facture surprise. Configurer une alarme CloudWatch sur les charges estimées prend moins de dix minutes et reste la première ligne de défense pour tout compte AWS nouvellement créé.

Résumé (TL;DR) : alerte de facturation AWS Free Tier

ÉtapeActionRésultat attendu
1Activer les alertes de facturation dans les préférences du compteMétriques de facturation disponibles dans CloudWatch
2Créer un topic SNS et s'y abonner par e-mailE-mail de confirmation reçu et validé
3Créer l'alarme CloudWatch sur EstimatedCharges avec seuil à 5 $Notification envoyée dès que les charges dépassent 5 $
4Vérifier l'état de l'alarme et testerAlarme visible dans la console, état OK ou ALARM

Comment fonctionne la métrique EstimatedCharges dans CloudWatch

AWS publie la métrique EstimatedCharges dans l'espace de noms AWS/Billing de CloudWatch. Cette métrique n'est disponible que dans la région us-east-1, quelle que soit la région où vos ressources sont déployées. Elle est mise à jour plusieurs fois par jour et représente le montant estimé de votre facture en cours, en dollars américains.

Deux points critiques à comprendre avant de créer l'alarme :

  • Les alertes de facturation doivent être explicitement activées dans les préférences du compte AWS. Sans cette activation, la métrique n'apparaît pas dans CloudWatch.
  • La métrique EstimatedCharges utilise la statistique Maximum sur la période d'évaluation — pas Sum ni Average. Utiliser la mauvaise statistique produit des alarmes qui ne se déclenchent jamais ou se déclenchent de façon erratique.
graph LR A["Préférences du compte
Alertes de facturation activées"] --> B["AWS publie EstimatedCharges
dans us-east-1"] B --> C["CloudWatch évalue
Maximum sur 24h"] C --> D{"Charges >= 5 USD ?"} D -- Non --> E["État : OK"] D -- Oui --> F["État : ALARM"] F --> G["Publication sur
topic SNS"] G --> H["Abonné confirmé ?"] H -- Non --> I["Notification abandonnée
silencieusement"] H -- Oui --> J["E-mail envoyé"]
  1. Activation des alertes : sans cette étape dans les préférences du compte, AWS ne publie aucune métrique de facturation dans CloudWatch.
  2. Métriques publiées dans us-east-1 : la région de vos ressources n'a aucune importance — toutes les métriques de facturation sont centralisées dans us-east-1.
  3. Évaluation CloudWatch : l'alarme évalue la statistique Maximum de EstimatedCharges sur la période configurée.
  4. SNS → E-mail : lorsque le seuil est franchi, CloudWatch publie un message sur le topic SNS, qui le transmet à l'adresse e-mail abonnée.

Étape 1 : activer les alertes de facturation AWS

Cette étape est bloquante. Si vous la sautez, la métrique EstimatedCharges n'existera pas dans CloudWatch et la création de l'alarme échouera silencieusement — vous ne verrez aucune donnée dans le graphique.

Dans la console AWS, accédez à Mon compte → Préférences de facturation et cochez Recevoir des alertes de facturation CloudWatch. Enregistrez les préférences. Cette activation est irréversible une fois effectuée et peut prendre jusqu'à 15 minutes avant que les métriques apparaissent dans CloudWatch.

Il n'existe pas de commande AWS CLI directe pour activer cette préférence — elle doit être configurée via la console ou l'API Billing.

Étape 2 : créer un topic SNS et s'abonner par e-mail

CloudWatch a besoin d'une destination pour envoyer les notifications. SNS joue le rôle d'intermédiaire : CloudWatch publie une alerte sur le topic, SNS la distribue aux abonnés. L'abonnement par e-mail nécessite une confirmation manuelle — sans cela, les notifications sont silencieusement abandonnées.

Créez le topic SNS :

aws sns create-topic \
  --name billing-alarm-topic \
  --region us-east-1

La commande retourne l'ARN du topic, par exemple :
arn:aws:sns:us-east-1:123456789012:billing-alarm-topic

Abonnez votre adresse e-mail au topic :

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:billing-alarm-topic \
  --protocol email \
  --notification-endpoint votre@email.com \
  --region us-east-1

Vérifiez votre boîte de réception et cliquez sur le lien Confirm subscription dans l'e-mail reçu d'AWS. Tant que la confirmation n'est pas effectuée, l'abonnement reste à l'état PendingConfirmation et aucune notification ne sera délivrée.

Étape 3 : créer l'alarme CloudWatch sur EstimatedCharges

L'alarme doit être créée dans us-east-1 — c'est la seule région où la métrique EstimatedCharges existe. Créer l'alarme dans une autre région ne produit aucune erreur mais l'alarme ne recevra jamais de données.

🔽 Cliquer pour afficher la commande de création d'alarme 
aws cloudwatch put-metric-alarm \
  --alarm-name "FreeTierBillingAlarm" \
  --alarm-description "Alerte si les charges estimees depassent 5 USD" \
  --metric-name EstimatedCharges \
  --namespace AWS/Billing \
  --statistic Maximum \
  --period 86400 \
  --evaluation-periods 1 \
  --threshold 5 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --dimensions Name=Currency,Value=USD \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:billing-alarm-topic \
  --treat-missing-data notBreaching \
  --region us-east-1

Paramètres clés à comprendre :

  • --statistic Maximum : correspond à la façon dont AWS publie cette métrique. Ne pas utiliser Sum ou Average.
  • --period 86400 : période d'évaluation de 24 heures (en secondes), adaptée à la fréquence de mise à jour de la métrique.
  • --dimensions Name=Currency,Value=USD : dimension obligatoire pour la métrique EstimatedCharges.
  • --treat-missing-data notBreaching : évite les fausses alarmes pendant les périodes où AWS n'a pas encore publié de nouvelle valeur.

Étape 4 : vérifier l'alarme et l'abonnement SNS

Après création, vérifiez que l'alarme existe et que son état est lisible :

aws cloudwatch describe-alarms \
  --alarm-names "FreeTierBillingAlarm" \
  --region us-east-1

Vérifiez l'état de l'abonnement SNS :

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:billing-alarm-topic \
  --region us-east-1

Si le champ SubscriptionArn affiche PendingConfirmation, l'e-mail de confirmation n'a pas encore été validé. Dans ce cas, renvoyez simplement la commande d'abonnement — cela déclenche l'envoi d'un nouvel e-mail de confirmation sans nécessiter de désabonnement préalable :

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:billing-alarm-topic \
  --protocol email \
  --notification-endpoint votre@email.com \
  --region us-east-1

Vérifiez ensuite votre boîte de réception et confirmez l'abonnement via le lien reçu.

Expérience terrain : le piège de l'alarme muette

Symptôme observé : l'alarme passe en état ALARM dans la console CloudWatch, mais aucun e-mail n'arrive. Premier réflexe — vérifier les règles anti-spam. Mauvaise piste.

Cause réelle : l'abonnement SNS était resté à l'état PendingConfirmation. L'e-mail de confirmation initial était arrivé dans le dossier spam, avait été ignoré, et l'abonnement n'avait jamais été validé. CloudWatch publiait bien les alertes sur le topic SNS, mais SNS les abandonnait silencieusement faute d'abonné confirmé.

Correction : ré-exécuter la commande aws sns subscribe avec les mêmes paramètres suffit à déclencher l'envoi d'un nouvel e-mail de confirmation. Après validation du lien, les notifications suivantes ont été délivrées normalement.

Un topic SNS sans abonné confirmé fonctionne comme une boîte aux lettres sans destinataire : CloudWatch dépose le courrier, mais personne ne le reçoit jamais.

IAM : permissions minimales requises

Si vous exécutez ces commandes depuis un rôle IAM (pas le compte root), les permissions suivantes sont nécessaires :

🔽 Cliquer pour afficher la politique IAM minimale 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricAlarm",
        "cloudwatch:DescribeAlarms"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "sns:CreateTopic",
        "sns:Subscribe",
        "sns:ListSubscriptionsByTopic"
      ],
      "Resource": "arn:aws:sns:us-east-1:123456789012:billing-alarm-topic"
    }
  ]
}

Note : cloudwatch:PutMetricAlarm et cloudwatch:DescribeAlarms requièrent "Resource": "*" — ces actions ne supportent pas la restriction au niveau de la ressource individuelle selon la référence d'autorisation de service AWS.

Prochaines étapes et ressources

Une alarme à 5 $ est un filet de sécurité, pas une stratégie de gestion des coûts. Pour aller plus loin :

Glossaire

TermeDéfinition
EstimatedChargesMétrique CloudWatch publiée dans l'espace de noms AWS/Billing, représentant le montant estimé de la facture en cours en USD. Disponible uniquement dans us-east-1.
Topic SNSPoint de terminaison de messagerie pub/sub d'Amazon Simple Notification Service. CloudWatch y publie les alertes, SNS les distribue aux abonnés.
PendingConfirmationÉtat d'un abonnement SNS par e-mail dont le lien de confirmation n'a pas encore été cliqué. Aucune notification n'est délivrée dans cet état.
treat-missing-dataParamètre CloudWatch définissant comment l'alarme interprète les périodes sans données. notBreaching évite les fausses alarmes.
Free Tier AWSProgramme offrant un usage gratuit limité de certains services AWS pendant 12 mois ou de façon permanente selon le service.

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite