Amazon SES für dein MVP: Günstige E-Mail, rohe Einrichtung

Jedes MVP, das transaktionale E-Mails versendet, stößt irgendwann auf denselben Kompromiss: mehr für einen ausgereiften, fertigen Anbieter zahlen oder weniger zahlen und mehr von der Installationsarbeit selbst übernehmen. Resend vs SendGrid behandelt die erste Wahl — zwei Anbieter, die beide Komfort auf der E-Mail-Zustellung verkaufen. Amazon SES (Simple Email Service) steht komplett auf der anderen Seite dieser Trennlinie. Es ist die rohe E-Mail-Versandinfrastruktur von AWS, nahe an den tatsächlichen Kosten des E-Mail-Versands bepreist, ohne den Dashboard-Feinschliff oder integrierte Template-Tools. Für MVPs, die jeden Dollar Infrastrukturausgaben im Blick behalten, lohnt es sich, diesen Unterschied zu verstehen, bevor man standardmäßig einen Anbieter wählt.

Was Amazon SES eigentlich ist

SES ist Teil von AWS, kein eigenständiges E-Mail-Unternehmen. Es bietet dir eine API (und eine SMTP-Schnittstelle) zum Versenden von transaktionalen und Massen-E-Mails, zusammen mit der zugrunde liegenden Versandinfrastruktur — IP-Reputationsmanagement, Bounce- und Beschwerdebearbeitung sowie Zustellung über die Mailserver von AWS. Es kommt nicht mit einem visuellen Template-Editor, einem integrierten Analyse-Dashboard vergleichbar mit dem von SendGrid oder erstklassiger Unterstützung für ein Templating-Framework wie die React-Email-Integration von Resend. Was du bekommst, ähnelt eher einem gut gebauten Hilfsprogramm als einem Produkt: ein API-Endpunkt, Konfigurationsregler und CloudWatch-Metriken, wenn du sie selbst einrichtest.

Das ist keine Kritik — das ist der Punkt. SES ist für Teams gebaut, die bereits in AWS leben und E-Mail als eine weitere Infrastruktur-Grundeinheit neben ihrer Rechenleistung und Speicherung haben möchten, nicht als separat verwaltete Anbieterbeziehung mit einem eigenen zu überwachenden Dashboard.

Warum SES günstiger ist

Die Kostenlücke zwischen SES und Anbietern wie Resend oder SendGrid ist kein Rabatt oder eine Aktion — sie spiegelt eine andere Position im Stack wider. Resend und SendGrid kaufen Versandinfrastruktur (in manchen Fällen von AWS oder einem ähnlichen Cloud-Anbieter) und fügen dann eine Produktschicht hinzu: Dashboards, Template-Editoren, Webhooks mit freundlichen Payloads, Onboarding-Abläufe und Support-Personal. Ihre Preisgestaltung muss diese Produktschicht abdecken, nicht nur die Mechanik des E-Mail-Versands.

SES überspringt diese Schicht. Du zahlst AWS nahezu die rohen Kosten für den Transport einer E-Mail durch ihre Infrastruktur, genauso wie Hetzner günstiger ist als eine verwaltete Datenbank eines Hyperscalers, weil du für Rechenleistung und Speicher zahlst statt für einen darum gewickelten verwalteten Dienst (siehe Günstiges Cloud-Hosting für MVPs: Wann Hetzner sinnvoll ist für dieselbe Kostenebenen-Logik, angewendet auf Hosting). Die Einsparungen sind real, aber sie entstehen dadurch, dass AWS kein Geld für die Teile des Produkts ausgibt, die Resend oder SendGrid angenehm in der Nutzung machen — und dieser Unterschied zeigt sich, sobald du auf SES aufzubauen beginnst.

Die eigentlichen Kompromisse

Eine rohere API und weniger Leitplanken

Eine E-Mail über SES zu versenden bedeutet, das AWS SDK oder die REST-API direkt aufzurufen, die eigene Wiederholungslogik zu handhaben und jede gewünschte Sichtbarkeit auf den Zustellstatus selbst aufzubauen — Bounces, Beschwerden, Öffnungen — meist indem man selbst SNS-Benachrichtigungen einrichtet. Resend und SendGrid liefern dir lesbare Webhook-Payloads und ein Dashboard von Haus aus; bei SES stellst du das aus AWS-Grundbausteinen zusammen. Es ist alles dokumentiert und bewährt, aber es ist deutlich mehr Einrichtungsaufwand als „SDK installieren, send aufrufen”.

Mehr AWS-Konfiguration im Vorfeld

Bevor du eine einzige E-Mail versendest, musst du deine Sendedomain in SES mit DNS-Einträgen verifizieren (ähnlich der SPF/DKIM/DMARC-Einrichtung bei jedem Anbieter, aber über die AWS-Konsole oder CLI statt über einen geführten Onboarding-Ablauf), IAM-Berechtigungen für den aufrufenden Dienst konfigurieren und entscheiden, ob du über die API- oder SMTP-Schnittstelle versendest. Nichts davon ist exotisch, wenn dein Team bereits mit AWS vertraut ist — es ist ein zusätzlicher Nachmittag Einrichtung, kein Forschungsprojekt. Wenn dein Team noch nie mit AWS gearbeitet hat, ist es ein steilerer erster Anstieg, als sich bei Resend anzumelden und einen API-Schlüssel einzufügen.

Die Sandbox und der Genehmigungsprozess für Sendelimits

Das ist der Kompromiss, der ein schnell vorankommendes Team am ehesten überrascht. Neue SES-Konten starten in einer Sandbox: Du kannst nur an verifizierte E-Mail-Adressen versenden, und das tägliche Sendevolumen ist niedrig gedeckelt. Um an echte, nicht verifizierte Nutzer in der Produktion zu versenden, musst du einen Antrag bei AWS einreichen, in dem du deinen Anwendungsfall, das erwartete Volumen und den Umgang mit Bounces und Beschwerden beschreibst — und AWS prüft dies, bevor der Produktionszugriff gewährt wird. Das geht nicht sofort, und historisch war es strenger als „anmelden und loslegen”, was zählt, wenn du diese Woche statt nächste Woche eine Anmeldebestätigungs-E-Mail ausliefern willst. Resend und SendGrid haben kein vergleichbares Genehmigungstor für den Einstieg.

Amazon SES im Vergleich zu Anbietern im Resend/SendGrid-Stil

Faktor	Amazon SES	Resend / SendGrid
Kosten im großen Maßstab	Am niedrigsten — rohe AWS-Infrastrukturpreise	Höher — Produkt-/Supportschicht im Preis enthalten
Einrichtungsaufwand	Höher — AWS-Konsole/IAM/DNS-Konfiguration, manuelle Webhook-Einrichtung	Geringer — API-Schlüssel, geführte Domain-Verifizierung, fertige Dashboards
Entwicklererfahrung	Rohe API/SMTP, Monitoring und Templating baust du selbst	Ausgereifte SDKs, integrierte Analysen, Template-Tools (z. B. React Email bei Resend)
Einstieg	Sandbox-Limits + AWS-Prüfprozess für Produktionsversand	Kein vergleichbares Genehmigungstor — schneller Versand an echte Adressen
Am besten geeignet für	Teams bereits auf AWS, hohes Sendevolumen, kostensensibel im großen Maßstab	Teams, die schnelle Einrichtung und weniger Wartung wollen, niedriges/mittleres Volumen

Wann sich die Kosteneinsparungen lohnen

SES ergibt in der Regel Sinn, sobald mindestens eine dieser Bedingungen zutrifft: Dein Team betreibt bereits nennenswerte Infrastruktur auf AWS, und ein weiterer Dienst ist wirklich mit wenig Reibung verbunden; dein erwartetes E-Mail-Volumen ist hoch genug, dass der Kostenunterschied pro E-Mail sich zu einem echten Budgetposten summiert, keiner Rundungsdifferenz; oder du hast die Engineering-Zeit, um das Monitoring, die Wiederholungslogik und die Template-Handhabung zu bauen, die dir ein ausgereifter Anbieter kostenlos liefert. In diesen Fällen summieren sich die niedrigeren laufenden Kosten in jedem Monat, in dem du das Produkt betreibst, und die einmaligen Einrichtungskosten spielen keine Rolle mehr, sobald sie erledigt sind.

Wann ein ausgereifter Anbieter mehr spart, als er kostet

Für die meisten MVPs in ihren ersten Monaten läuft die Rechnung andersherum. Wenn dein Team noch nie mit AWS gearbeitet hat, ist die Einrichtungszeit — plus das Warten auf die Genehmigung des Sendelimits bei SES — Zeit, die nicht in den Aufbau des Produkts selbst fließt. Wenn dein E-Mail-Volumen noch niedrig ist, sind die absoluten Dollar-Einsparungen durch die Wahl von SES im ersten Jahr gering, während die Engineering-Stunden für den Aufbau gleichwertigen Monitorings und Templatings es nicht sind. In dieser Situation ist der direkte Vergleich von Resend oder SendGrid die nützlichere Lektüre: Beide tauschen höhere Kosten pro E-Mail gegen deutlich weniger Einrichtung und Wartung, was in der Regel der richtige Kompromiss für ein Team ist, dessen knappe Ressource Engineering-Zeit ist, nicht Infrastrukturbudget.

Die Entscheidung treffen

Amazon SES ist weder ein versteckter Trick noch eine Falle — es ist dieselbe Entscheidung „rohe Infrastruktur versus verwaltetes Produkt”, die MVP-Teams bereits beim Hosting treffen, angewendet auf E-Mail. Der Kostenvorteil ist real und wächst mit dem Volumen, wird aber mit Einrichtungszeit, einer roheren API und einem Genehmigungsprozess bezahlt, der Vorlaufzeit hinzufügen kann, bevor du echte Produktions-E-Mails versendest. Wenn dein Team AWS-nativ ist oder bereits über den Punkt hinaus skaliert, an dem die Kosten pro E-Mail eine Rolle spielen, lohnt sich dieser Kompromiss. Wenn du das Produkt noch validierst und transaktionale E-Mail diese Woche zum Laufen bringen willst, ohne die AWS-Konfiguration zu betreuen, bringt dich ein Anbieter wie Resend oder SendGrid schneller ans Ziel — und du kannst später immer noch zu SES migrieren, sobald das Volumen den Wechsel rechtfertigt, ähnlich wie Teams bestimmte Workloads von einem Budget-Host zu einem Hyperscaler migrieren, sobald sich die Rechnung ändert.

Häufig gestellte Fragen

Ist Amazon SES günstiger als Resend oder SendGrid?

Bei nennenswertem Sendevolumen ja — SES ist in der Regel die kostengünstigste Option, da es als rohe AWS-Infrastruktur bepreist wird und nicht als ausgereiftes Produkt mit Support, Dashboards und Templating im Preis inbegriffen. Prüfe die aktuelle Preisseite jedes Anbieters gegen dein erwartetes Volumen, statt dich auf eine gemerkte Zahl zu verlassen, da sich die Stufen ändern.

Ist Amazon SES schwer einzurichten?

Es ist aufwendiger als Resend oder SendGrid. Du konfigurierst den Versand über die AWS-Konsole oder CLI, verifizierst deine Sendedomain mit DNS-Einträgen und beantragst — für den Produktionseinsatz außerhalb der Sandbox — eine Erhöhung des Sendelimits, die AWS vor der Genehmigung prüft. Es ist nicht so sehr schwierig als vielmehr manuell, mit weniger Leitplanken als eine dedizierte E-Mail-API.

Was ist die SES-Sandbox und wie wirkt sie sich auf ein neues MVP aus?

Neue SES-Konten starten in einer Sandbox, die den Versand auf verifizierte E-Mail-Adressen beschränkt, mit niedrigen täglichen Sendelimits. Der Wechsel zum Produktionszugriff erfordert einen Antrag bei AWS, in dem du deinen Anwendungsfall beschreibst, den AWS prüft, bevor die Beschränkung aufgehoben wird — plane diese Vorlaufzeit ein, bevor du erwartest, echte Nutzer per E-Mail zu erreichen.

Sollte ein MVP in einer frühen Phase Amazon SES anstelle von Resend oder SendGrid verwenden?

Nur wenn mehr Engineering-Zeit als Budget verfügbar ist oder du bereits tief in der AWS-Infrastruktur steckst. Wenn du transaktionale E-Mails schnell mit minimaler Einrichtung ausliefern möchtest und es dir nichts ausmacht, pro E-Mail mehr zu zahlen, bringen dich Resend oder SendGrid schneller ans Ziel. Wenn du auf die niedrigstmöglichen Kosten im großen Maßstab optimierst und bereit bist, mehr selbst zu bauen, ist SES den zusätzlichen Aufwand wert.

Kann ich später von Amazon SES zu Resend oder SendGrid wechseln, oder umgekehrt?

Ja. Du richtest den E-Mail-Versandcode deiner Anwendung auf eine neue API aus und wiederholst die Domain-Authentifizierung (SPF, DKIM, DMARC) für den neuen Anbieter — echte Arbeit, aber kein Neuaufbau. Viele Teams starten aus Geschwindigkeitsgründen bei einem ausgereiften Anbieter und wechseln später zu SES, sobald das Volumen den Wechsel rechtfertigt, oder umgekehrt, wenn der Einrichtungsaufwand von SES die Einsparungen übersteigt.