Alertes par e-mail via Amazon SNS : pourquoi les e-mails n'arrivent pas et comment corriger la souscription

Vous avez créé un topic SNS, ajouté votre adresse e-mail comme abonné, déclenché une alarme CloudWatch — et rien. Pas un seul e-mail. Le problème le plus fréquent en production n'est pas un bug de configuration complexe : c'est un lien de confirmation ignoré ou expiré qui laisse la souscription bloquée en état PendingConfirmation.

Résumé (TL;DR) — Alertes e-mail SNS

ÉtapeActionRésultat attendu
1Créer le topic SNSARN du topic disponible
2Créer la souscription e-mailStatut PendingConfirmation
3Confirmer via le lien reçu par e-mailStatut passe à Confirmed
4Publier un message de testE-mail reçu dans la boîte
5Associer à une alarme CloudWatchAlertes opérationnelles

Comment fonctionne la souscription e-mail SNS

Amazon SNS utilise un modèle publish/subscribe. Un topic est le canal central : les producteurs publient des messages, les abonnés les reçoivent. Pour le protocole email, SNS envoie un e-mail de confirmation à l'adresse fournie dès la création de la souscription. Tant que le destinataire n'a pas cliqué sur le lien de confirmation, la souscription reste en état PendingConfirmation — SNS ne délivrera aucun message à cette adresse.

Ce comportement est intentionnel : il empêche qu'une adresse e-mail reçoive des messages sans le consentement explicite du propriétaire. Le lien de confirmation expire après 3 jours. Passé ce délai, il faut recréer la souscription pour recevoir un nouveau lien.

graph LR Producteur["Producteur
(CloudWatch / Lambda)"] --> Topic["Topic SNS
alertes-production"] Topic --> CheckSub{"Souscription confirmée ?"} CheckSub -- "PendingConfirmation" --> Ignore["Message ignoré
pour cet abonné"] CheckSub -- "Confirmed" --> Deliver["Livraison e-mail"] Deliver --> Inbox["Boîte de réception"]
  1. Producteur (CloudWatch, Lambda, etc.) publie un message sur le topic SNS.
  2. SNS vérifie l'état de chaque souscription avant la livraison.
  3. Si la souscription est PendingConfirmation, le message est ignoré pour cet abonné.
  4. Si la souscription est Confirmed, SNS livre le message à l'adresse e-mail.
  5. En cas d'échec de livraison, SNS applique sa politique de retry (configurable via une Dead Letter Queue).

Étape 1 : Créer le topic SNS pour les alertes e-mail

Commencez par créer un topic SNS standard. Les topics FIFO ne supportent pas le protocole email — utilisez un topic Standard.

aws sns create-topic \
  --name alertes-production \
  --region us-east-1

La commande retourne l'ARN du topic, par exemple :

{
    "TopicArn": "arn:aws:sns:us-east-1:123456789012:alertes-production"
}

Conservez cet ARN — il sera nécessaire pour toutes les étapes suivantes.

Étape 2 : Créer la souscription e-mail SNS

Créez la souscription avec le protocole email. SNS envoie immédiatement un e-mail de confirmation à l'adresse spécifiée.

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:alertes-production \
  --protocol email \
  --notification-endpoint votre-adresse@exemple.com \
  --region us-east-1

Réponse attendue :

{
    "SubscriptionArn": "pending confirmation"
}

La valeur pending confirmation confirme que l'e-mail de confirmation a été envoyé. Vérifiez votre boîte de réception — et votre dossier spam, c'est souvent là que ça finit.

Étape 3 : Confirmer la souscription — l'étape critique

C'est ici que la majorité des configurations échouent silencieusement. L'e-mail reçu contient un lien du type :

https://sns.us-east-1.amazonaws.com/confirmation?...
  &Token=...longtoken...
  &TopicArn=arn:aws:sns:us-east-1:123456789012:alertes-production

Cliquez sur ce lien depuis votre navigateur. SNS affiche une page de confirmation indiquant que la souscription est activée. Sans cette action, aucun message ne sera jamais livré à cette adresse.

Vérifier l'état de la souscription via CLI

Après confirmation, vérifiez que le statut est bien Confirmed :

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:alertes-production \
  --region us-east-1

Résultat attendu après confirmation :

{
    "Subscriptions": [
        {
            "SubscriptionArn": "arn:aws:sns:us-east-1:123456789012:alertes-production:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
            "Owner": "123456789012",
            "Protocol": "email",
            "Endpoint": "votre-adresse@exemple.com",
            "TopicArn": "arn:aws:sns:us-east-1:123456789012:alertes-production"
        }
    ]
}

Si le champ SubscriptionArn affiche encore PendingConfirmation, le lien n'a pas été cliqué ou a expiré. Dans ce cas, supprimez la souscription et recommencez l'étape 2.

Supprimer une souscription expirée

Une souscription en PendingConfirmation dont le lien a expiré ne peut pas être confirmée rétroactivement. Il faut la recréer :

aws sns unsubscribe \
  --subscription-arn arn:aws:sns:us-east-1:123456789012:alertes-production:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --region us-east-1

Étape 4 : Tester la livraison d'un message SNS

Avant de connecter CloudWatch ou tout autre producteur, validez que la livraison fonctionne en publiant un message de test directement sur le topic.

aws sns publish \
  --topic-arn arn:aws:sns:us-east-1:123456789012:alertes-production \
  --subject "Test alerte SNS" \
  --message "Ceci est un message de test depuis AWS SNS." \
  --region us-east-1

Si l'e-mail arrive dans les secondes qui suivent, la configuration est correcte. Si rien n'arrive, consultez les logs CloudWatch Logs pour la livraison SNS (si vous avez activé le logging SNS) ou vérifiez les politiques IAM du topic.

Étape 5 : Connecter une alarme CloudWatch à SNS pour les alertes e-mail

Une fois la souscription confirmée et testée, associez le topic SNS à une alarme CloudWatch. L'exemple ci-dessous crée une alarme sur l'utilisation CPU d'une instance EC2.

🔽 Cliquez pour afficher la commande CloudWatch 
aws cloudwatch put-metric-alarm \
  --alarm-name cpu-eleve-production \
  --alarm-description "CPU superieur a 80% pendant 5 minutes" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:alertes-production \
  --ok-actions arn:aws:sns:us-east-1:123456789012:alertes-production \
  --region us-east-1

Le paramètre --alarm-actions déclenche une publication SNS quand l'alarme passe en état ALARM. Le paramètre --ok-actions envoie une notification quand l'alarme revient en état OK — utile pour savoir quand un incident est résolu.

graph LR CW["CloudWatch Alarm
CPUUtilization > 80%"] -- "État ALARM" --> SNS["Topic SNS
alertes-production"] SNS --> Sub1["Souscription e-mail
Confirmed"] Sub1 --> Email["E-mail reçu
par l'équipe"] CW -- "État OK" --> SNS
  1. CloudWatch évalue la métrique CPUUtilization toutes les 5 minutes.
  2. Si le seuil est dépassé, l'alarme passe en état ALARM et publie sur le topic SNS.
  3. SNS délivre le message à tous les abonnés confirmés.
  4. L'e-mail arrive dans la boîte de réception de l'équipe.

Politique IAM pour publier sur un topic SNS

Si vous publiez sur SNS depuis une fonction Lambda, une instance EC2, ou un autre service AWS, le rôle IAM associé doit avoir la permission sns:Publish sur le topic cible. CloudWatch dispose d'une intégration native avec SNS et n'a pas besoin de permissions IAM supplémentaires pour déclencher des alarmes — mais pour des appels directs depuis votre code, voici la politique minimale :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-east-1:123456789012:alertes-production"
    }
  ]
}

Appliquez le principe du moindre privilège : restreignez la ressource à l'ARN exact du topic plutôt qu'à *.

Diagnostic : pourquoi les alertes e-mail SNS n'arrivent toujours pas

Voici le scénario classique en production : l'alarme CloudWatch passe en état ALARM, le dashboard le confirme, mais aucun e-mail n'arrive. Le premier réflexe est de vérifier la politique du topic ou les logs CloudWatch. Mauvaise piste.

La cause réelle : la souscription est toujours en PendingConfirmation parce que l'e-mail de confirmation est arrivé dans le spam trois semaines plus tôt, personne ne l'a vu, et le lien a expiré au bout de 3 jours. Le topic SNS fonctionne parfaitement — il publie le message, mais SNS ne le délivre à aucun abonné confirmé.

La correction prend 2 minutes : supprimer la souscription orpheline, en recréer une, confirmer immédiatement le lien, republier un message de test. Ce n'est pas un problème de permissions IAM, pas un problème de politique de topic — c'est uniquement l'état de la souscription.

graph TD Start["Pas d'e-mail reçu"] --> Check["Vérifier statut souscription
list-subscriptions-by-topic"] Check --> Pending{"PendingConfirmation ?"} Pending -- "Oui" --> Delete["Supprimer et recréer
la souscription"] Delete --> Confirm["Confirmer le lien
dans les 3 jours"] Confirm --> Test["Publier un message de test"] Pending -- "Non (Confirmed)" --> Filter["Vérifier FilterPolicy
get-subscription-attributes"] Filter --> FilterSet{"Filtre actif ?"} FilterSet -- "Oui" --> FixFilter["Corriger les attributs
du message ou supprimer le filtre"] FilterSet -- "Non" --> Policy["Vérifier la politique
du topic SNS"]
  1. Vérifiez l'état de la souscription avec list-subscriptions-by-topic.
  2. Si PendingConfirmation : supprimez et recréez la souscription.
  3. Si Confirmed mais toujours pas d'e-mail : vérifiez la politique du topic et les filtres de message.
  4. Si la politique du topic est correcte : activez le logging SNS vers CloudWatch Logs pour inspecter les tentatives de livraison.

Activer le logging de livraison SNS

Pour diagnostiquer les échecs de livraison au niveau du protocole email, SNS ne supporte pas nativement le logging de livraison pour ce protocole — contrairement aux protocoles HTTP/S, SQS, Lambda ou Kinesis. Si vous avez besoin d'une traçabilité complète des livraisons, envisagez d'ajouter une souscription SQS en parallèle pour capturer tous les messages publiés.

Filtres de message SNS : une cause silencieuse de non-réception

Une interaction moins évidente : si vous avez défini une politique de filtre de message (subscription filter policy) sur la souscription, SNS ne délivrera que les messages dont les attributs correspondent au filtre. Un message publié sans les attributs requis sera silencieusement ignoré pour cette souscription — même si elle est confirmée.

Vérifiez les attributs de filtre d'une souscription :

aws sns get-subscription-attributes \
  --subscription-arn arn:aws:sns:us-east-1:123456789012:alertes-production:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --region us-east-1

Si l'attribut FilterPolicy est présent et non vide, assurez-vous que vos messages publiés incluent les attributs correspondants — ou supprimez le filtre si ce n'est pas intentionnel.

Conclusion et prochaines étapes — Alertes e-mail SNS en production

La configuration des alertes e-mail via Amazon SNS est directe, mais la souscription e-mail exige une confirmation explicite que beaucoup oublient ou ratent. Vérifiez systématiquement l'état de vos souscriptions avec list-subscriptions-by-topic avant de chercher des causes plus complexes.

Pour aller plus loin :

  • Consultez la documentation officielle SNS sur les notifications e-mail.
  • Envisagez d'ajouter une souscription SQS en parallèle pour capturer les messages même en cas de problème de livraison e-mail.
  • Pour des alertes plus structurées, explorez l'intégration SNS avec AWS Chatbot pour recevoir des notifications dans Slack ou Amazon Chime.
  • Mettez en place une Dead Letter Queue (DLQ) SQS sur votre topic SNS pour capturer les messages non délivrés sur les protocoles qui le supportent.

Glossaire

TermeDéfinition
Topic SNSCanal de messagerie pub/sub dans Amazon Simple Notification Service. Les producteurs publient des messages, les abonnés les reçoivent.
PendingConfirmationÉtat d'une souscription SNS dont le lien de confirmation n'a pas encore été cliqué. Aucun message n'est livré dans cet état.
Subscription Filter PolicyRègle JSON attachée à une souscription SNS qui filtre les messages selon leurs attributs. Les messages non correspondants sont ignorés silencieusement.
Dead Letter Queue (DLQ)File SQS configurée pour recevoir les messages qu'SNS n'a pas pu délivrer après épuisement des tentatives de retry.
ARN (Amazon Resource Name)Identifiant unique d'une ressource AWS, au format arn:aws:<service>:<region>:<account-id>:<resource>.

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