Revolve AI
Retour au blog

Méthode EC2 SES: Le guide pour envoyer des emails via AWS

1 juillet 2026 · 20 min

Méthode EC2 SES: Le guide pour envoyer des emails via AWS
#méthode ec2 ses#aws ses#amazon ec2#email transactionnel#délivrabilité email

Vous avez une application sur Amazon EC2 qui doit envoyer des e-mails. Confirmation de compte, réinitialisation de mot de passe, alerte métier, facture, relance commerciale. Le besoin paraît simple. En pratique, c'est souvent là que les ennuis commencent.

Le mauvais réflexe consiste à installer un serveur SMTP local sur l'instance et à tenter d'envoyer directement vers les boîtes de réception. Ça marche parfois en test, puis la délivrabilité se dégrade, les messages finissent en spam, et certains flux s'arrêtent sans signal clair. Sur AWS, il faut en plus composer avec des contraintes réseau classiques, notamment autour du port 25, qui surprennent régulièrement les équipes au moment du passage en production.

La voie propre consiste à découpler l'hébergement de l'application et l'envoi d'e-mails. EC2 exécute votre code. Amazon SES prend en charge l'expédition. C'est l'approche que je recommande pour un système prêt pour la production, parce qu'elle est plus propre côté sécurité, plus lisible côté exploitation, et plus simple à faire évoluer.

Un autre point est souvent négligé dans les tutoriels rapides. Beaucoup montrent uniquement l'authentification SMTP avec des identifiants statiques. Ça dépanne, mais ce n'est pas la bonne base pour un environnement sérieux. Pour une instance EC2, la meilleure pratique consiste à attacher un rôle IAM à l'instance afin que l'application récupère des permissions temporaires sans stocker de secrets longue durée sur le serveur.

Si vous suivez déjà des sujets d'industrialisation et d'exploitation applicative, le blog de Revolve sur l'automatisation et la mise en production propose aussi des contenus utiles sur les systèmes fiables et exploitables.

Table des matières

Introduction à l'envoi d'emails depuis EC2 avec SES

Votre application tourne sur EC2, les notifications doivent partir, et le premier réflexe consiste souvent à configurer un serveur SMTP sur l'instance. En production, ce choix crée surtout des problèmes d'exploitation. Files d'attente à gérer, réputation d'IP à surveiller, logs dispersés, secrets SMTP stockés quelque part dans le système.

Amazon SES évite ce détour. L'instance EC2 reste un client applicatif qui déclenche l'envoi, tandis que SES prend en charge la couche e-mail. C'est le bon découpage si vous voulez un système plus simple à maintenir et plus prévisible sous charge.

Le point souvent manqué dans les tutoriels est l'authentification. Beaucoup montrent uniquement des identifiants SMTP. Pour un test rapide, cela fonctionne. Pour une mise en production, le choix par défaut doit être un rôle IAM attaché à l'instance EC2, avec des permissions limitées à l'envoi via SES. Vous évitez ainsi de copier des secrets dans le code, dans un fichier de configuration ou dans des variables d'environnement mal gérées. Si vous cherchez d'autres retours d'expérience orientés exploitation AWS, le blog cloud et IA de Revolve AI contient ce type d'approche pragmatique.

Une autre réalité à anticiper dès le début concerne le réseau. Sur EC2, le trafic sortant SMTP sur le port 25 peut être limité. Des équipes perdent du temps à déboguer une application saine alors que le blocage vient du chemin réseau. L'appel API SES via le SDK AWS contourne souvent ce piège et s'intègre mieux avec IAM.

Ce qui tient en production

Les mises en service propres suivent généralement ces principes :

  • L'instance EC2 n'est pas un serveur mail. Elle appelle SES et garde la logique métier.
  • Le rôle IAM passe avant les identifiants SMTP. Moins de secrets à gérer, rotation plus simple, surface d'attaque réduite.
  • La région SES est choisie explicitement. Une mauvaise région provoque des erreurs difficiles à voir au premier test.
  • Les retours d'envoi sont prévus dès le départ. Bounces, complaints et refus doivent remonter vers vos logs et vos alertes.

Les erreurs qui coûtent des heures

Je vois les mêmes problèmes revenir en revue d'architecture ou en incident de mise en ligne :

  • Conserver des credentials SMTP sur le serveur parce que "c'était plus rapide".
  • Découvrir trop tard que le compte SES est encore en sandbox, avec des envois limités aux identités vérifiées.
  • Tester uniquement depuis un script local, puis échouer une fois déployé sur EC2 à cause du réseau ou des permissions IAM.
  • Attribuer les rejets au code alors que le domaine d'envoi n'est pas encore correctement préparé.

Le bon objectif n'est pas seulement d'envoyer un e-mail de test. Le bon objectif est d'avoir un chemin d'envoi sûr, observable et acceptable pour la production dès le premier déploiement.

Préparer votre compte Amazon SES pour la production

Le scénario classique ressemble à ceci. L'application fonctionne en staging, le premier test local passe, puis le déploiement en production échoue parce que le compte SES est encore en sandbox, que l'identité a été validée dans la mauvaise région, ou que l'équipe a prévu des identifiants SMTP au lieu d'un rôle IAM. Ce sont des erreurs banales, mais elles bloquent un lancement.

Schéma illustrant les deux étapes pour préparer un compte Amazon SES pour la production : vérification et configuration.

Vérifier votre identité d'envoi dans la bonne région

Pour la production, vérifiez un domaine plutôt qu'une simple adresse e-mail. Une adresse unique suffit pour un test rapide. Un domaine complet simplifie l'exploitation, évite de multiplier les exceptions, et donne un cadre propre pour les différentes adresses d'envoi de l'application.

La vérification passe par des enregistrements DNS publiés chez votre fournisseur DNS ou dans Route 53. Faites ce travail tôt. La propagation DNS, les erreurs de copier-coller et les confusions entre domaine racine et sous-domaine font perdre du temps au mauvais moment.

Avant de valider, contrôlez trois points :

  • Le domaine réellement utilisé par l'application. mail.example.com et example.com ne sont pas interchangeables.
  • La région SES visée par le code. Une identité vérifiée en eu-west-1 ne sera pas reconnue si votre SDK appelle us-east-1.
  • L'adresse From finale. Elle doit correspondre à ce que votre service enverra en production, pas à une adresse de test oubliée dans un script.

Une mauvaise région est un piège fréquent. La console semble correcte, mais l'appel applicatif échoue avec une erreur d'identité non vérifiée.

Demander l'accès production avant la date de mise en ligne

Un nouveau compte SES démarre en sandbox. Dans cet état, vous ne pouvez envoyer qu'à des identités vérifiées, ce qui suffit pour des essais techniques mais pas pour une application destinée à de vrais utilisateurs.

La demande d'accès production mérite d'être préparée comme un dossier d'exploitation, pas comme une formalité administrative. AWS veut comprendre votre cas d'usage et votre discipline d'envoi. Répondez de façon concrète, avec le moins d'ambiguïté possible.

Incluez au minimum :

  1. Le type de messages envoyés. Notifications transactionnelles, réinitialisation de mot de passe, factures, alertes applicatives, campagnes marketing si elles existent.
  2. L'origine du consentement. Création de compte, relation commerciale, opt-in explicite, ou obligation contractuelle.
  3. Le traitement des rebonds et des plaintes. Arrêt des envois vers les adresses en échec, suppression après plainte, désinscription claire si le cas d'usage l'exige.
  4. La montée en charge prévue. Volume initial, progression attendue, et mesures prises pour éviter des pics anormaux.

Une réponse vague ralentit souvent l'approbation. “Nous envoyons des e-mails depuis notre application” ne dit rien sur la qualité de votre trafic.

Préparer l'authentification de manière sûre dès le départ

Beaucoup de tutoriels s'arrêtent aux identifiants SMTP. Pour une mise en production sur EC2, ce n'est pas le bon point de départ. Le choix plus sûr consiste à attacher un rôle IAM à l'instance et à appeler SES via le SDK AWS.

Cette approche réduit la gestion de secrets sur le serveur, simplifie la rotation des permissions et limite les fuites d'identifiants dans les variables d'environnement, les fichiers de configuration ou les outils de déploiement. Elle facilite aussi l'audit. Vous pouvez accorder seulement les actions nécessaires, par exemple l'envoi via SES, sans distribuer de credentials persistants.

Gardez les identifiants SMTP pour les cas où vous devez intégrer un composant qui ne sait parler qu'en SMTP. Même dans ce cas, stockez-les dans un gestionnaire de secrets et évitez de les laisser en clair sur l'instance.

Vérifications utiles avant le premier envoi réel

Avant d'ouvrir le trafic, validez aussi les points suivants :

  • Le rôle IAM de l'instance autorise bien l'envoi SES dans la région choisie.
  • Le chemin réseau est cohérent avec votre méthode d'envoi. Si vous utilisez l'API SES avec le SDK, vous évitez une bonne partie des problèmes liés au SMTP sortant.
  • Le port 25 n'est pas votre dépendance implicite. Sur EC2, il peut être limité ou ralenti. Si un outil impose SMTP, préférez les ports alternatifs pris en charge par SES.
  • Les quotas et limites d'envoi sont connus. Un trafic qui monte trop vite peut provoquer du throttling si vous n'avez pas prévu la rampe de démarrage.
  • Les adresses de retour et les mécanismes de suivi sont déjà définis pour traiter les rebonds et les plaintes.

Le bon résultat n'est pas seulement “un e-mail est parti”. Le bon résultat est un compte SES prêt pour un trafic réel, avec une identité correcte, une sortie de sandbox validée, et une authentification basée sur IAM plutôt que sur des secrets durables.

Authentifier vos envois avec SPF et DKIM

La plupart des problèmes de délivrabilité ne viennent pas du code applicatif. Ils viennent d'un manque de confiance entre votre domaine et les serveurs de réception. SPF et DKIM servent à établir cette confiance.

Sans eux, votre message peut tout à fait être accepté par SES puis traité avec suspicion à l'arrivée. Le serveur destinataire voit bien un e-mail venant de votre domaine, mais il n'a pas assez d'éléments pour confirmer que l'expéditeur est légitime.

Une boîte aux lettres en métal sur pied contenant des lettres devant une maison floue, symbolisant la sécurité.

Ce que SPF et DKIM changent concrètement

SPF indique quels services sont autorisés à envoyer des messages pour votre domaine. DKIM ajoute une signature cryptographique que les serveurs de réception peuvent vérifier. Dit autrement, SPF parle d'autorisation d'envoi, DKIM parle d'intégrité et d'authenticité du message.

Dans SES, la partie pratique est assez simple. Le service génère les enregistrements nécessaires. Votre travail consiste à les publier proprement dans votre DNS, puis à attendre leur propagation et leur validation.

Trois erreurs reviennent souvent :

  • Multiplier les modifications DNS en même temps. Quand tout change d'un coup, le diagnostic devient pénible.
  • Confondre le domaine racine et un sous-domaine d'envoi. Les deux approches sont valides, mais elles n'ont pas les mêmes implications.
  • Corriger à la main sans relire la syntaxe fournie par SES. Une petite divergence suffit à invalider la vérification.

Si vous voulez une base robuste, publiez les enregistrements exactement comme fournis par SES. Pas “presque pareil”.

Ajouter les enregistrements sans vous tromper

La méthode dépend de votre prestataire DNS, mais le principe reste identique. Chez OVH, GoDaddy ou Route 53, vous allez créer les entrées demandées, puis laisser le temps à la propagation. La console SES finit ensuite par afficher la validation de l'identité et, le cas échéant, de la signature DKIM.

Gardez une discipline simple :

  • Faites une capture de l'état initial avant modification.
  • Ajoutez les entrées une par une si vous travaillez sur un domaine déjà sensible.
  • Attendez la validation SES avant de poursuivre vos tests applicatifs.
  • Documentez le choix du domaine d'envoi dans votre dépôt d'infra ou votre runbook.

Le sujet de la Méthode EC2 SES scolaire donne d'ailleurs une autre leçon utile. Certaines ressources rappellent que l'élève doit lire un document statistique avec précision, en explicitant date, unité et source dans la rédaction. Une synthèse méthodologique sur Knowunity au sujet de la méthode EC2 en SES souligne ce niveau d'exigence formelle, tout en évoquant des écarts de réussite selon la maîtrise de la présentation du document et des calculs. En infrastructure mail, c'est la même philosophie. Les petits détails de forme produisent de grands écarts de résultat.

Configurer un accès sécurisé depuis votre instance EC2

C'est ici que se joue la différence entre une intégration acceptable et une intégration propre. Votre application sur EC2 doit obtenir l'autorisation d'envoyer via SES. Deux options existent en pratique. Les identifiants SMTP et les rôles IAM.

Si vous ne retenez qu'une chose, retenez celle-ci. Pour une instance EC2, le rôle IAM doit être votre choix par défaut.

Pourquoi le rôle IAM doit être votre choix par défaut

Un rôle IAM attaché à l'instance donne à votre code des permissions temporaires via le mécanisme natif d'AWS. Vous n'avez pas à déposer une clé secrète sur le serveur. Vous n'avez pas à gérer une rotation manuelle de credentials dans vos fichiers de configuration. Et vous réduisez fortement le risque d'exposition accidentelle.

Le principe de moindre privilège s'applique très bien ici. Votre rôle peut se limiter aux permissions nécessaires à l'envoi, comme ses:SendEmail, éventuellement complétées selon votre usage précis. Le code récupère automatiquement les credentials temporaires via le SDK AWS.

Bon réflexe d'ops : si une application EC2 peut fonctionner sans secret statique, ne lui en donnez pas.

Voici la comparaison utile en exploitation.

Critère Rôle IAM (Recommandé) Identifiants SMTP
Sécurité Permissions temporaires, pas de secret longue durée sur l'instance Secret statique à stocker et protéger
Rotation Gérée nativement par AWS À organiser manuellement
Intégration SDK Native avec Boto3 et SDK AWS pour JavaScript Non concernée si vous passez par SMTP
Surface d'exposition Réduite Plus large si le serveur ou les logs fuitent
Gestion multi-environnements Claire avec des rôles distincts par instance ou service Souvent bricolée avec plusieurs jeux d'identifiants
Usage recommandé Production sur EC2 Cas de compatibilité ou héritage applicatif

Quand les identifiants SMTP restent acceptables

Il ne faut pas caricaturer. Les identifiants SMTP ont encore un intérêt dans certains cas. Typiquement, une application héritée sait parler SMTP mais pas AWS SDK. Ou bien un composant tiers n'offre qu'une configuration de relais SMTP.

Dans ces cas-là, l'objectif n'est pas de diaboliser SMTP. L'objectif est de contenir le risque. Si vous devez l'utiliser :

  • Stockez les secrets dans un gestionnaire adapté, pas dans le code.
  • Restreignez les permissions et la portée d'usage autant que possible.
  • Séparez les identifiants par environnement pour éviter les croisements entre préproduction et production.
  • Surveillez les accès et les journaux pour repérer toute utilisation anormale.

Le problème n'est pas que SMTP “ne marche pas”. Le problème est qu'il pousse facilement les équipes à normaliser le stockage de secrets persistants sur les serveurs.

Mise en place concrète côté EC2

La séquence propre ressemble à ceci :

  1. Créer un rôle IAM dédié à l'application qui envoie des e-mails.
  2. Attacher une policy minimale autorisant l'action d'envoi requise.
  3. Associer ce rôle à l'instance EC2 ou au profil d'instance utilisé.
  4. Configurer le SDK dans l'application sans clés statiques. Il résoudra les credentials automatiquement.
  5. Tester avec un envoi simple puis vérifier la réception et les évènements de retour.

Si le SDK essaie encore de lire des variables d'environnement ou un fichier de credentials local, c'est souvent le signe qu'un ancien paramétrage traîne sur l'instance. Nettoyez-le. L'authentification doit être explicite, sobre et prévisible.

Exemples de code pour envoyer des emails en Python et Node.js

Quand le domaine est vérifié, que l'authentification DNS est en place et que le rôle IAM est attaché à l'instance, le code devient très simple. C'est l'un des avantages majeurs de cette architecture. Vous n'avez pas à gérer les credentials dans le code si l'instance reçoit bien son rôle IAM.

Exemple Python avec Boto3

En Python, Boto3 est le choix naturel. Le SDK récupère automatiquement les credentials temporaires fournis à l'instance.

import boto3
from botocore.exceptions import ClientError

ses = boto3.client("ses", region_name="eu-west-1")

def send_email():
    try:
        response = ses.send_email(
            Source="noreply@votredomaine.fr",
            Destination={
                "ToAddresses": ["destinataire@example.com"]
            },
            Message={
                "Subject": {
                    "Data": "Confirmation de votre action",
                    "Charset": "UTF-8"
                },
                "Body": {
                    "Text": {
                        "Data": "Votre demande a bien été prise en compte.",
                        "Charset": "UTF-8"
                    },
                    "Html": {
                        "Data": """
                        <html>
                          <body>
                            <h1>Confirmation</h1>
                            <p>Votre demande a bien été prise en compte.</p>
                          </body>
                        </html>
                        """,
                        "Charset": "UTF-8"
                    }
                }
            }
        )
        print("Email envoyé :", response["MessageId"])
    except ClientError as e:
        print("Erreur SES :", e.response["Error"]["Message"])

send_email()

Quelques points méritent votre attention :

  • Choisissez la bonne région. Elle doit correspondre à celle où votre identité SES est configurée.
  • Utilisez une adresse Source cohérente avec votre domaine vérifié.
  • Prévoyez une gestion d'erreur claire. Un échec SES doit remonter dans vos logs applicatifs.

Exemple Node.js avec le SDK AWS

En Node.js, le principe est identique. Le client SES exploite lui aussi les credentials du rôle IAM lorsqu'il s'exécute sur EC2.

import { SESClient, SendEmailCommand } from "@aws-sdk/client-ses";

const client = new SESClient({ region: "eu-west-1" });

async function sendEmail() {
  const command = new SendEmailCommand({
    Source: "noreply@votredomaine.fr",
    Destination: {
      ToAddresses: ["destinataire@example.com"],
    },
    Message: {
      Subject: {
        Data: "Votre notification",
        Charset: "UTF-8",
      },
      Body: {
        Text: {
          Data: "Votre opération a été enregistrée.",
          Charset: "UTF-8",
        },
        Html: {
          Data: `
            <html>
              <body>
                <h1>Notification</h1>
                <p>Votre opération a été enregistrée.</p>
              </body>
            </html>
          `,
          Charset: "UTF-8",
        },
      },
    },
  });

  try {
    const response = await client.send(command);
    console.log("Email envoyé :", response.MessageId);
  } catch (error) {
    console.error("Erreur SES :", error);
  }
}

sendEmail();

Le conseil important ici est de ne pas mélanger plusieurs stratégies d'authentification. Si vous avez choisi le rôle IAM, laissez le SDK faire son travail. N'ajoutez pas des variables de secours partout “au cas où”. Ce type de doublon finit souvent par masquer un mauvais paramétrage.

En production, le meilleur code est souvent le plus simple. Moins il y a de logique d'authentification embarquée dans l'application, plus le comportement est lisible.

Surveillance Dépannage et Bonnes Pratiques

Un e-mail “envoyé” par l'application n'est pas un e-mail “délivré”. C'est la distinction que les équipes oublient le plus vite après la mise en ligne. L'exploitation sérieuse d'Amazon SES demande une boucle de surveillance continue.

Une liste numérotée de cinq bonnes pratiques pour la surveillance et le dépannage du service Amazon SES.

Ce qu'il faut surveiller après la mise en service

Le Reputation Dashboard de SES est votre premier tableau de bord. Il permet de suivre les signaux qui dégradent la réputation d'envoi, notamment les rebonds et les plaintes. Ne le regardez pas uniquement quand un incident survient. Intégrez-le à votre routine d'exploitation.

Pour aller plus loin, connectez les évènements d'e-mail à Amazon SNS et, si besoin, à CloudWatch. L'idée n'est pas seulement de collecter des métriques. L'idée est de déclencher une action lorsqu'une adresse rebondit, lorsqu'un destinataire se plaint, ou lorsqu'un flux applicatif se met à échouer.

Une base opérationnelle solide repose sur ces pratiques :

  • Surveiller les rebonds. Une adresse invalide ne doit pas rester dans votre flux actif.
  • Traiter les plaintes immédiatement. Continuez à envoyer après une plainte et vous attaquez votre réputation vous-même.
  • Corréler les erreurs applicatives et les évènements SES. Sans ça, le diagnostic reste incomplet.
  • Faire monter le volume progressivement lors d'un nouveau lancement ou d'un nouveau domaine d'envoi.

Une bonne réputation d'envoi se construit lentement et se détériore vite. Le monitoring n'est pas un supplément. C'est une fonction du système.

Pannes courantes et contournements utiles

Le problème réseau le plus classique sur EC2 concerne le port 25. Beaucoup découvrent qu'un flux SMTP direct n'est pas aussi simple qu'attendu. En pratique, pour l'envoi applicatif, il vaut mieux s'appuyer sur l'API SES ou sur une configuration SMTP compatible avec des ports adaptés à ce type d'usage, comme 587, plutôt que de bâtir une dépendance autour du port 25.

Autres incidents fréquents en production :

  • Mauvaise région SES. Le code appelle une région différente de celle qui contient l'identité validée.
  • Adresse From non alignée. L'identité autorisée n'est pas celle utilisée réellement par l'application.
  • Rôle IAM incomplet. Le SDK s'initialise, mais l'appel d'envoi échoue faute de permission.
  • DNS non propagé ou incohérent. SPF ou DKIM ne sont pas encore pris en compte côté réception.

Sur la partie purement méthodologique, certaines ressources pédagogiques sur la méthode EC2 en SES scolaire insistent sur la hiérarchisation des informations et l'usage de calculs pour confirmer une lecture de tendance. Une fiche de révision sur Partielo à propos de la méthodologie EC2 SES associe cette rigueur à des difficultés fréquentes de structure et de traitement des données. C'est une comparaison intéressante pour l'exploitation de SES chez AWS. Une intuition ne suffit pas. Il faut des signaux observables, hiérarchisés, puis des actions correctives.

Checklist d'exploitation

Avant de considérer votre intégration comme stable, vérifiez cette liste :

  • Identité validée. Domaine d'envoi confirmé dans la bonne région.
  • Compte hors sandbox. Sinon vos tests “réussis” restent trompeurs.
  • SPF et DKIM actifs. Pas seulement configurés, mais validés.
  • Rôle IAM attaché à l'instance. Pas de clés statiques sur le serveur.
  • Gestion des rebonds et plaintes. Avec notification et traitement.
  • Logs applicatifs lisibles. Chaque erreur SES doit être exploitable.
  • Port et chemin d'envoi adaptés. Évitez de dépendre d'un flux SMTP fragile sur le port 25.
  • Montée en charge progressive. Surtout sur un nouveau domaine.

Une dernière nuance utile. Certaines ressources sur la méthode EC2 SES côté enseignement soulignent une difficulté souvent sous-traitée entre données en pourcentage et données brutes, avec un risque de perte de points si l'interprétation n'est pas adaptée. Un guide pratique hébergé sur Scribd au sujet de la méthodologie EC2 mentionne précisément cet angle. En exploitation cloud, l'équivalent existe aussi. Les équipes confondent volontiers “message accepté par le service” et “message correctement délivré au destinataire”. Ce sont deux niveaux différents. Si vous ne faites pas cette distinction, vous concluez trop vite que tout va bien.

Si vous voulez industrialiser ce type de flux dans un SI réel, avec intégration à vos outils métier, supervision exploitable et mise en production rapide, Revolve conçoit et déploie des agents IA et des automatisations fiables pour PME et ETI françaises. Leur approche est orientée production, intégration aux outils existants et résultats opérationnels concrets.

Méthode EC2 SES: Le guide pour envoyer des emails via AWS | Blog Revolve AI