Pourquoi Amazon SES est le fournisseur d'e-mail « bon marché » le plus cher
Amazon SES annonce le prix le plus bas de l’e-mail : 0,10 $ pour 1 000 messages. C’est vrai, et c’est le chiffre qui gagne les feuilles de calcul. Mais ce prix vous achète exactement une chose — des octets quittant un serveur de messagerie. Tout ce dont vous avez réellement besoin pour gérer l’e-mail transactionnel — savoir ce qui a rebondi, détecter un modèle de spam avant qu’AWS vous suspend, voir un graphique de délivrabilité — est laissé comme exercice pour le lecteur. Nous ne théorisons pas ici — nous avons lancé Mailer To Go sur SES nous-mêmes, et c’est la raison pour laquelle nous ne fonctionnons plus là-bas. Cet article tarifie cet exercice. Méthodiquement, le prix affiché de 0,10 $ devient un 4–6 $ efficaces pour 1 000 au moment où vous pouvez fonctionner en toute sécurité — et à ce moment-là, vous avez reconstruit, à vos propres frais, ce que MailerToGo, SendGrid et Mailgun incluent dans la boîte.
La promesse
SES se vend comme l’e-mail à l’échelle et aux prix d’AWS : des centimes par millier, élastique, paiement à l’usage, juste à côté du reste de votre pile. Pour le débit brut, c’est efficace.
La réalité : SES est un tuyau d’envoi, pas une plateforme de courrier électronique
Envoyez un message via SES et posez-vous les questions que tout expéditeur transactionnel doit poser :
- Combien ont rebondi dans la dernière heure, et quelles adresses ?
- Quel est mon taux de plainte en ce moment — vais-je dépasser la limite de 0,1 % d’AWS et être suspendu ?
- Quel chemin de campagne ou de code génère les plaintes de spam ?
- Mon taux de livraison baisse-t-il pour un fournisseur de boîtes aux lettres spécifique ?
- Qui s’est désinscrit, et sont-ils supprimés partout ?
SES ne répond à aucune de ces questions directement. Il n’y a pas de tableau de bord, pas de flux d’événements que vous pouvez lire, pas d’interface de suppression, pas de graphique de réputation, pas de détection d’anomalies. Les données n’existent que sous la forme d’un tuyau d’incendie d’événements individuels que vous devez capturer, stocker, agréger et visualiser vous-même. Et vous devez — SES impose un taux de rebond inférieur à ~5% et un taux de plainte inférieur à ~0,1%, et si vous dépassez ces seuils, le premier « tableau de bord » que vous verrez est l’e-mail vous disant que votre compte est en révision.
Ce que vous devez construire
Pour reconnaître et prévenir le spam et les abus — l’enjeu fondamental de l’e-mail transactionnel — vous câblez un pipeline pour chaque événement que SES émet : envoi, livraison, rebond, plainte, rejet, ouverture, clic. Suivez tout ce que vous avez besoin de suivre pour rester en sécurité et c’est facilement 5 à 10 événements pour chaque message que vous envoyez.
SES ──(destination d'événement de jeu de configuration)──► Sujet SNS
│
▼
File d'attente SQS (tampon pour ne rien perdre)
│
▼
Lambda (analyser, exécuter vos vérifications de spam/délivrabilité, écrire dans votre BD)
│
┌───────────┴───────────┐
▼ ▼
Métriques CloudWatch votre base de données
+ tableaux de bord (suppression, historique)
│
▼
le graphique que SES ne vous a jamais donné
Voici le piège : ce pipeline est facturé par événement, pas par e-mail. Donc la surveillance que vous construisez pour surveiller les problèmes de spam et de délivrabilité coûte 5–10× le coût d’envoi — et le multiple augmente à mesure que vous êtes plus prudent.
Tarification de l’exercice
Prenez un envoi transactionnel SaaS réaliste de 1 000 000 e-mails/mois. Avec un suivi d’événement complet, c’est environ 7 millions d’événements/mois circulant dans le pipeline. Chiffres illustratifs de la région US (vérifiez la tarification AWS actuelle ; le point est la forme, pas le centime) :
| Couche | Ce qu’il vous achète | ~$/mois | ~$/1 000 |
|---|---|---|---|
| Envoi SES | Le message part | 100 $ | 0,10 $ |
| SNS | Distribuer ~7M d’événements | ~4 $ | ~0,00 $ |
| SQS | Événements tampons de manière fiable | ~8 $ | ~0,01 $ |
| Lambda | Analyser ~7M d’événements, exécuter les vérifications de spam/délivrabilité, écrire dans votre BD | ~60 $ | ~0,06 $ |
| CloudWatch (métriques personnalisées + PutMetricData + Journaux) | Les graphiques de rebond/plainte/livraison/réputation que SES omet — cardinalité élevée par domaine, campagne et fournisseur de boîte aux lettres | ~450 $ | ~0,45 $ |
| NAT / transfert de données | Laisser parler à l’intérieur de votre VPC | ~35 $ | ~0,04 $ |
| Sous-total traitement des événements | la machinerie qui surveille le spam et la délivrabilité | ~560 $ | ~0,56 $ |
| Envoi SES, pour comparaison | 100 $ | 0,10 $ |
Relisez cela : la surveillance coûte environ 5–6× l’e-mail lui-même. La ligne la moins chère sur une facture SES est l’envoi. CloudWatch est la partie chère — la cardinalité des métriques personnalisées est le tueur silencieux, car pour réellement détecter les abus, vous avez besoin de métriques ventilées par domaine d’envoi × type d’événement × fournisseur de boîte aux lettres, et ce compte explose. (La propre réponse d’AWS à « SES n’a pas de tableau de bord », Virtual Deliverability Manager, est un complément payant en plus de tout cela — environ ~0,07–0,12 $ par 1 000.)
Et c’est toujours uniquement la facture AWS. L’autre moitié est les gens :
| Couche | ~$/mois | ~$/1 000 | |
|---|---|---|---|
| Construire le pipeline (amorti, première année) | 2–4 semaines pour concevoir SNS/SQS/Lambda + suppression + alertes | ~2 000 $ | ~2,00 $ |
| Maintenir + astreinte | elle traîne, AWS change une API, un nouveau type d’événement apparaît | ~1 500 $ | ~1,50 $ |
| Coût effectif entièrement chargé | ~4–6 $ / 1 000 |
Le 0,10 $ était réel. C’était juste le premier — et le plus petit — élément de ligne.
C’est pire à grande échelle, pas mieux
La défense habituelle de SES est « mais c’est imbattable en volume ». Ce n’est pas le cas, et voici pourquoi : l’envoi évolue linéairement (0,10 $/1 000) tandis que le traitement des événements évolue contre vous. Plus d’e-mails signifie plus d’événements (5–10×), plus d’invocations Lambda, et — pire — une cardinalité plus élevée des métriques CloudWatch à mesure que vous ajoutez des domaines, des campagnes et une surveillance des abus plus granulaire. Plus vous êtes gros et prudent, plus la charge d’observabilité domine. Ce n’est pas un avantage d’échelle ; c’est un piège d’échelle.
Le labyrinthe
Le problème plus profond n’est pas le total — c’est la forme du total. Votre « coût SES » n’est pas un seul nombre que vous pouvez comparer à un concurrent ; il est réparti sur six services, un VPC et une feuille de route d’ingénierie. Chaque pièce est spécifique à AWS : jeux de configuration, politiques de sujet SNS, mathématiques de métrique CloudWatch, IAM. Rien n’est portable. Plus vous construisez pour rendre SES utilisable, plus vous êtes enfermé dans une pile personnalisée qui ne fonctionne que sur AWS et que seule votre équipe comprend — et plus il devient difficile de répondre à la seule question qu’une entreprise devrait être capable de répondre facilement : quel est mon coût réel d’envoi d’e-mails, et est-ce bon ?
Nous le savons parce que nous avons essayé
Nous n’avons pas raisonné notre façon d’y arriver à partir d’une feuille de calcul — nous avons lancé Mailer To Go sur SES. Et nous avons frappé exactement le mur que ce post décrit : une fois que le coût entièrement chargé d’exploitation de SES s’est assis sous nous, nous n’avions pas pu assembler une offre qui était une meilleure valeur pour nos clients que simplement leur dire d’utiliser un concurrent n’aurait pas été. Notre coût réel sur SES était plus élevé que le prix affiché des fournisseurs même que nous avons cherché à surpasser. Le tueur spécifique : les événements que nous avons poussés dans CloudWatch et Lambda juste pour surveiller le spam et les problèmes de délivrabilité ont coûté 5–10× le coût de l’envoi SES lui-même. La chose la moins chère sur la facture était l’e-mail ; la partie chère était de pouvoir la voir. Donc nous avons reconstruit la pile de livraison — tableaux de bord, pipeline d’événements, suppression et outils de réputation — comme notre propre infrastructure, pas comme une taxe boulonnée sur le tuyau de quelqu’un d’autre. C’est la différence que vous payez, et c’est pourquoi le numéro sur notre page de tarification est le numéro complet.
Ne nous croyez pas sur parole
Le modèle est bien documenté — à commencer par AWS lui-même :
- AWS vous oblige à construire la surveillance. Les conseils d’Amazon lui-même consistent à configurer les notifications de rebond et de plainte via SNS et la publication d’événements et à les traiter vous-même — il n’y a pas de gestion intégrée (AWS : configurer les notifications pour les rebonds et les plaintes).
- Et AWS vous suspendra si vous ne le faites pas. SES applique les seuils de rebond et de plainte et met les comptes en révision quand ils sont dépassés ; effacer une révision peut prendre des jours à des semaines (AWS : processus d’examen d’envoi).
- CloudWatch est un piège de facture connu. Sa tarification par métrique et par cardinalité transforme quelques dollars de surveillance en centaines par mois une fois que vous ventillez les métriques par dimension — exactement la granularité dont vous avez besoin pour détecter les abus (La tarification CloudWatch peut atteindre 300 $/mois par défaut).
- Les critiques indépendantes continuent de nommer le temps d’ingénierie comme le coût caché le plus important de SES — le prix d’envoi de 0,10 $ se situe à côté de centaines de dollars par mois de temps de développeur pour la gestion des rebonds, l’échauffement et la surveillance, et le verdict récurrent est que SES ne paie que si vous exécutez déjà une pratique AWS/DevOps en volume (SendGrid vs AWS SES).
Une réconciliation honnête : les guides de tarification occasionnels mettent la surveillance CloudWatch basique de SES à 10–30 $/mois. C’est la version jouet — assez pour dessiner un graphique, pas assez pour attraper les abus. Les métriques de cardinalité élevée qui signalent réellement le spam et les problèmes de délivrabilité (par domaine, campagne et fournisseur de boîte aux lettres) sont celles qui s’exécutent à des centaines. Cet écart est l’histoire.
L’alternative à bretelles et bretelles
MailerToGo — comme SendGrid et Mailgun — inclut ce que SES vous oblige à construire : un tableau de bord, des webhooks d’événements, des analyses de livraison/rebond/plainte, une suppression automatique, la gestion de la réputation et les contrôles de spam/abus, dans un prix par message. Ce numéro est directement comparable, tête à tête, contre n’importe quel pair — pas de reconstruction à six services, pas de surprise par événement, pas de facture de cardinalité métrique qui augmente plus vite que vous.
La nuance honnête, car les mathématiques la méritent : le prix d’envoi réel de SES est vraiment le plus bas, et si vous tirez vraiment sans surveillance ni suivi, vous paierez des centimes — jusqu’au moment où votre taux de rebond ou de plainte dépasse une limite et qu’AWS vous suspend sans avertissement. Au moment où vous construisez la surveillance qui vous garde en sécurité pour envoyer, la facture s’inverse, et elle s’inverse plus dur à mesure que vous grandissez.
Le moins cher à acheter, le plus cher à posséder.
Comparant directement ? Voir Mailer To Go vs Amazon SES et, quand vous êtes prêt, comment migrer d’Amazon SES. Nouveau dans le côté délivrabilité ? Commencez par l’authentification e-mail, de bout en bout et tarification transparente par message.