Amazon SES voor je MVP: Goedkope e-mail, ruwe setup

Elke MVP die transactionele e-mail verstuurt, loopt uiteindelijk tegen dezelfde afweging aan: meer betalen voor een gepolijste, kant-en-klare provider, of minder betalen en meer van de loodgieterswerkzaamheden zelf bouwen. Resend versus SendGrid behandelt de eerste keuze — twee providers die beide gemak verkopen bovenop e-mailbezorging. Amazon SES (Simple Email Service) staat volledig aan de andere kant van die lijn. Het is AWS’s ruwe e-mailverzendinfrastructuur, geprijsd dicht bij de kostprijs van het daadwerkelijk versturen van de e-mail, zonder de dashboardpolish of templatetools ingebakken. Voor MVP’s die elke dollar aan infrastructuurkosten in de gaten houden, is dat verschil de moeite waard om te begrijpen voordat je standaard een provider kiest.

Wat Amazon SES eigenlijk is

SES maakt deel uit van AWS, geen op zichzelf staand e-mailbedrijf. Het geeft je een API (en SMTP-interface) om transactionele en bulk-e-mail te versturen, samen met de onderliggende verzendinfrastructuur — IP-reputatiebeheer, afhandeling van bounces en klachten, en bezorging via AWS’s mailservers. Het wordt niet geleverd met een visuele template-editor, een ingebouwd analytics-dashboard vergelijkbaar met dat van SendGrid, of eersteklas ondersteuning voor een templating-framework zoals de React Email-integratie van Resend. Wat je krijgt lijkt meer op een goed gebouwde utility dan op een product: een API-endpoint, configuratieknoppen en CloudWatch-metrics als je die zelf aansluit.

Dat is geen kritiek — het is precies het punt. SES is gebouwd voor teams die al in AWS leven en e-mail willen als nog een infrastructuur-primitief naast hun compute en opslag, niet als een apart beheerde leveranciersrelatie met een eigen dashboard om te controleren.

Waarom SES goedkoper is

Het kostenverschil tussen SES en providers zoals Resend of SendGrid is geen korting of promotie — het weerspiegelt een andere positie in de stack. Resend en SendGrid kopen verzendinfrastructuur (in sommige gevallen van AWS of een vergelijkbare cloudprovider) en voegen daar een productlaag aan toe: dashboards, template-editors, webhooks met vriendelijke payloads, onboardingflows en supportmedewerkers. Hun prijzen moeten die productlaag dekken, niet alleen de mechaniek van het versturen van een e-mail.

SES slaat die laag over. Je betaalt AWS bijna de ruwe kostprijs van het verplaatsen van een e-mail door hun infrastructuur, op dezelfde manier waarop Hetzner goedkoper is dan de managed database van een hyperscaler omdat je betaalt voor compute en opslag in plaats van een managed service eromheen (zie Budget cloudhosting voor MVP’s: wanneer Hetzner logisch is voor dezelfde kostenlogica toegepast op hosting). De besparingen zijn reëel, maar ze komen doordat AWS geen geld uitgeeft aan de onderdelen van het product die Resend of SendGrid prettig maken in gebruik — en dat verschil merk je zodra je begint te bouwen op SES.

De echte afwegingen

Een ruwere API en minder vangrails

Een e-mail versturen via SES betekent dat je de AWS SDK of REST-API rechtstreeks aanroept, je eigen retry-logica afhandelt en zelf de zichtbaarheid opbouwt die je wilt in de bezorgstatus — bounces, klachten, opens — meestal door zelf SNS-meldingen aan te sluiten. Resend en SendGrid geven je kant-en-klare leesbare webhook-payloads en een dashboard; bij SES stel je dat samen uit AWS-primitieven. Het is allemaal gedocumenteerd en beproefd, maar het is aanzienlijk meer setup dan “installeer de SDK, roep send aan.”

Meer AWS-configuratie vooraf

Voordat je één e-mail verstuurt, moet je je verzenddomein verifiëren in SES met DNS-records (vergelijkbaar met SPF/DKIM/DMARC-instellingen voor elke provider, maar gedaan via de AWS-console of CLI in plaats van een begeleide onboardingflow), IAM-machtigingen configureren voor welke service SES ook aanroept, en beslissen of je verstuurt via de API- of SMTP-interface. Niets hiervan is exotisch als je team al vertrouwd is met AWS — het is een extra middag setup, geen onderzoeksproject. Als je team nog nooit met AWS heeft gewerkt, is het een steilere eerste klim dan je aanmelden bij Resend en een API-sleutel plakken.

De sandbox en het goedkeuringsproces voor verzendlimieten

Dit is de afweging die een snel bewegend team het meest waarschijnlijk verrast. Nieuwe SES-accounts starten in een sandbox: je kunt alleen versturen naar geverifieerde e-mailadressen, en het dagelijkse verzendvolume is laag begrensd. Om naar echte, niet-geverifieerde gebruikers in productie te versturen, moet je een aanvraag indienen bij AWS waarin je je gebruikssituatie, verwachte volume en de manier waarop je bounces en klachten afhandelt beschrijft — en AWS beoordeelt dit voordat productietoegang wordt verleend. Dit gaat niet direct, en historisch gezien is het strikter geweest dan “meld je aan en ga aan de slag,” wat ertoe doet als je deze week een aanmeldbevestigingsmail wilt uitrollen in plaats van volgende week. Resend en SendGrid hebben geen vergelijkbare goedkeuringspoort om te beginnen.

Amazon SES versus providers in de stijl van Resend/SendGrid

Factor	Amazon SES	Resend / SendGrid
Kosten op schaal	Laagst — ruwe AWS-infrastructuurprijzen	Hoger — inclusief product-/supportlaag in de prijs
Setup-inspanning	Hoger — AWS-console/IAM/DNS-configuratie, handmatige webhookkoppeling	Lager — API-sleutel, begeleide domeinverificatie, kant-en-klare dashboards
Developer-ervaring	Ruwe API/SMTP, je bouwt zelf monitoring en templating	Gepolijste SDK’s, ingebouwde analytics, templatetools (bijv. React Email op Resend)
Aan de slag gaan	Sandboxlimieten + AWS-beoordelingsproces voor productieverzending	Geen vergelijkbare goedkeuringspoort — snel naar echte adressen versturen
Best geschikt voor	Teams die al op AWS zitten, hoog verzendvolume, kostengevoelig op schaal	Teams die snelle setup willen en minder onderhoud, laag/gemiddeld volume

Wanneer de kostenbesparing het waard is

SES is meestal zinvol zodra ten minste een van deze zaken waar is: je team draait al betekenisvolle infrastructuur op AWS en het toevoegen van nog één service is echt weinig gedoe; je verwachte e-mailvolume is hoog genoeg dat het kostenverschil per e-mail optelt tot een echte budgetpost, geen afrondingsverschil; of je hebt de engineeringtijd om de monitoring, retry- en template-afhandeling te bouwen die een gepolijste provider je gratis geeft. In die gevallen stapelen de lagere lopende kosten zich op elke maand dat je het product draait, en de eenmalige setupkosten worden onbelangrijk zodra ze zijn afgehandeld.

Wanneer een gepolijste provider meer bespaart dan hij kost

Voor de meeste MVP’s in hun eerste maanden loopt de berekening andersom. Als je team nog nooit in AWS heeft gewerkt, is de setuptijd — plus wachten op de goedkeuring van de verzendlimiet van SES — tijd die niet aan het bouwen van het product zelf wordt besteed. Als je e-mailvolume nog laag is, zijn de absolute dollarbesparingen door SES te kiezen klein in een eerste jaar, terwijl de engineeringuren om gelijkwaardige monitoring en templating te bouwen dat niet zijn. In die situatie is de directe vergelijking van Resend of SendGrid de nuttigere leesstof: beide ruilen hogere kosten per e-mail in voor aanzienlijk minder setup en onderhoud, wat meestal de juiste ruil is voor een team wiens schaarse hulpbron engineeringtijd is, niet infrastructuurbudget.

De keuze maken

Amazon SES is geen verborgen cheatcode en geen valkuil — het is dezelfde afweging tussen “ruwe infrastructuur versus managed product” die MVP-teams al maken voor hosting, nu toegepast op e-mail. Het kostenvoordeel is reëel en groeit met volume, maar wordt betaald met setuptijd, een ruwere API en een goedkeuringsproces dat doorlooptijd kan toevoegen voordat je echte productie-e-mail verstuurt. Als je team AWS-native is of al voorbij het punt schaalt waar kosten per e-mail ertoe doen, is die ruil de moeite waard. Als je het product nog aan het valideren bent en transactionele e-mail deze week werkend wilt hebben zonder AWS-configuratie te hoeven verzorgen, brengt een provider zoals Resend of SendGrid je daar sneller — en je kunt later altijd naar SES migreren zodra het volume de overstap rechtvaardigt, ongeveer zoals teams specifieke workloads migreren van een budgethost naar een hyperscaler zodra de rekensom verandert.

Veelgestelde vragen

Is Amazon SES goedkoper dan Resend of SendGrid?

Bij een betekenisvol verzendvolume, ja — SES is over het algemeen de goedkoopste optie omdat het geprijsd is als ruwe AWS-infrastructuur in plaats van een gepolijst product met support, dashboards en templating inbegrepen in de prijs. Controleer de actuele prijspagina van elke provider tegenover je verwachte volume in plaats van te vertrouwen op een onthouden getal, aangezien de tariefschijven veranderen.

Is Amazon SES moeilijk in te stellen?

Het is bewerkelijker dan Resend of SendGrid. Je configureert het verzenden via de AWS-console of CLI, verifieert je verzenddomein met DNS-records en — voor productiegebruik buiten de sandbox — vraag je een verhoging van de verzendlimiet aan die AWS beoordeelt voordat deze wordt goedgekeurd. Het is niet zozeer moeilijk als wel handmatig, met minder vangrails dan een specifieke e-mail-API.

Wat is de SES-sandbox en hoe beïnvloedt deze een nieuwe MVP?

Nieuwe SES-accounts starten in een sandbox die je beperkt tot het verzenden naar alleen geverifieerde e-mailadressen, met lage dagelijkse verzendlimieten. Overstappen naar productietoegang vereist het indienen van een aanvraag bij AWS waarin je je gebruikssituatie beschrijft, die zij beoordelen voordat de beperking wordt opgeheven — houd rekening met deze doorlooptijd voordat je verwacht echte gebruikers te e-mailen.

Moet een vroege-fase-MVP Amazon SES gebruiken in plaats van Resend of SendGrid?

Alleen als er meer engineeringtijd beschikbaar is dan budget, of als je al diep in AWS-infrastructuur zit. Als je snel transactionele e-mail wilt uitrollen met minimale setup en het niet erg vindt om meer per e-mail te betalen, brengen Resend of SendGrid je daar sneller. Als je optimaliseert voor de laagst mogelijke kosten op schaal en bereid bent om meer zelf te bouwen, is SES de extra setup waard.

Kan ik later overstappen van Amazon SES naar Resend of SendGrid, of andersom?

Ja. Je herwijst de e-mailverzendcode van je applicatie naar een nieuwe API en doet de domeinauthenticatie (SPF, DKIM, DMARC) opnieuw voor de nieuwe provider — echt werk, maar geen herbouw. Veel teams beginnen bij een gepolijste provider voor snelheid en stappen later over naar SES zodra het volume de overstap rechtvaardigt, of doen het omgekeerde als de setupoverhead van SES zwaarder weegt dan de besparingen.