Reporting Amazon SES : Analyser Bounces et Complaints avec CloudWatch

Pourquoi monitorer les Bounces et Complaints sur Amazon SES ?

Maintenir une bonne délivrabilité est crucial pour tout service d’envoi d’emails. Amazon SES (Simple Email Service) surveille de près deux indicateurs :

• Bounce (Rebond) : L’email n’a pas pu être remis.

• Soft Bounce : Problème temporaire (boîte pleine, serveur indisponible).

• Hard Bounce : Problème permanent (adresse inexistante). Attention : Un taux de Hard Bounce > 10% peut entraîner la suspension de votre compte AWS.

• Complaint (Plainte) : Le destinataire a marqué votre message comme SPAM. Un taux > 0.1% est considéré comme critique par Amazon.

L’enjeu de la réputation d’expéditeur

Si vous ne traitez pas ces retours, votre réputation d’expéditeur chute, et vos emails finiront directement en spam, voire votre accès à SES sera révoqué. L’objectif ici est de mettre en place une architecture serverless pour analyser ces événements à moindre coût.

Architecture de la solution : SES, SNS et CloudWatch

L’idée est de créer un pipeline automatique pour centraliser les logs sans gérer de serveur.

1. Amazon SES capture l’événement (Bounce/Complaint).
2. Un topic Amazon SNS reçoit la notification.
3. Une fonction AWS Lambda traite le JSON et l’envoie vers CloudWatch Logs.
4. CloudWatch Logs Insights permet de requêter et visualiser les données.

Étape 1 : Configuration des notifications SES

Pour interconnecter SES avec SNS, suivez la documentation officielle d’Amazon SES. Dans la console AWS, allez dans Configuration Sets ou directement dans l’identité vérifiée (domaine), section Notifications, pour lier vos types de retours à votre topic SNS.

Étape 2 : Traitement des données avec AWS Lambda

Voici le code Python de la fonction Lambda. Son rôle est d’extraire le message SNS pour le rendre lisible par CloudWatch.

import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    # Extraction du message SNS
    message = event['Records'][0]['Sns']['Message']
    
    # Log structuré pour CloudWatch Insights
    print(message) 
    
    return {
        'statusCode': 200,
        'body': json.dumps('Log traité avec succès')
    }

Sécurité : Rôles et Permissions IAM

Pour que ce flux fonctionne, votre Lambda doit avoir les droits nécessaires.

Trust Policy (AssumeRole) : Permet à AWS Lambda d’exécuter la fonction.

IAM Policy pour CloudWatch : Assurez-vous que la Lambda possède les droits logs:CreateLogGroup, logs:CreateLogStream, et logs:PutLogEvents.

Étape 3 : Analyse avec CloudWatch Logs Insights

C’est ici que la magie opère. Une fois que vos logs arrivent dans CloudWatch, vous pouvez utiliser le langage de requête pour générer des rapports.

Requête pour isoler les Bounces

fields @timestamp, notificationType, mail.sourceIp as sourceIp, mail.source as Sender, mail.destination.0 as Recipient
| filter notificationType = "Bounce"
| sort @timestamp desc

Requête pour les Complaints (Plaintes pour Spam)

fields @timestamp, notificationType, mail.sourceIp as sourceIp, mail.source as Sender, mail.destination.0 as Recipient
| filter notificationType = "Complaint"
| sort @timestamp desc

Conclusion et perspectives

Cette architecture simple et Cloud Native vous permet de surveiller votre activité mail sans surcoût d’infrastructure. Pour aller plus loin, vous pourriez :

• Créer un Dashboard CloudWatch pour visualiser les taux en temps réel.
• Automatiser le bannissement des adresses “Hard Bounce” dans votre base de données via la Lambda.
• Utiliser Terraform pour déployer l’intégralité de cette stack en une commande.