AWS SES gebruik ik wanneer een applicatie betrouwbaar e-mails moet versturen zonder dat ik daarvoor zelf mailinfrastructuur wil beheren.
Voor mij is SES vooral interessant omdat het heel goed past binnen backend- en event-driven architecturen. Een applicatie bepaalt wat er moet gebeuren, SES doet uiteindelijk waar het goed in is: e-mail afleveren.
Wat is AWS SES?
AWS Simple Email Service is een managed e-maildienst van AWS waarmee applicaties transactionele en bulk e-mails kunnen versturen.
Denk bijvoorbeeld aan:
Accountbevestigingen
Wachtwoord resets
Facturen
Notificaties
Systeemmeldingen
Statusupdates vanuit een proces
SES kan direct vanuit een backend worden aangeroepen, maar ook onderdeel worden van een groter event-driven proces.
Wat vind ik belangrijk bij SES?
E-mail is een technische verantwoordelijkheid
Ik probeer e-mail niet te diep in domeinlogica te verweven.
Een domeinproces bepaalt bijvoorbeeld dat een factuur is aangemaakt. Het daadwerkelijk versturen van de e-mail zie ik vervolgens als een aparte technische verantwoordelijkheid.
Dat maakt het systeem eenvoudiger te testen, te wijzigen en uit te breiden.
Versturen betekent niet automatisch afleveren
Een succesvolle API-call naar SES betekent nog niet dat een e-mail daadwerkelijk bij de ontvanger terechtkomt.
Daarom vind ik zaken zoals bounces, complaints en delivery feedback belangrijk. Zeker wanneer e-mail onderdeel is van een belangrijk bedrijfsproces moet je weten wat er na het versturen gebeurt.
Houd templates beheersbaar
E-mailtemplates kunnen verrassend snel onderdeel worden van je businesslogica.
Ik probeer daarom een duidelijke scheiding te houden tussen data, inhoud en het daadwerkelijke verzendproces. Daardoor blijft wijzigen eenvoudiger zonder dat iedere aanpassing gevolgen heeft voor de hele applicatie.
Hoe ik AWS SES gebruik
Ik gebruik SES voornamelijk als laatste stap binnen een backendproces.
Een applicatie of event bepaalt dat er communicatie nodig is. Vervolgens wordt de benodigde informatie verzameld en wordt SES aangeroepen om de daadwerkelijke e-mail te versturen.
Binnen een event-driven architectuur vind ik het vaak logischer om dit asynchroon te doen.
Bijvoorbeeld:
Domeinproces → Event → E-mail verwerking → AWS SES
Daardoor hoeft het primaire proces niet te wachten totdat een externe e-maildienst klaar is.
Voor mij is dat precies waar event-driven architectuur waarde toevoegt. Niet alles hoeft synchroon onderdeel te zijn van dezelfde request.
Waar ik AWS SES heb gebruikt
Bij Marvia heb ik meerdere jaren gewerkt binnen een SaaS-platform waarin AWS een belangrijk onderdeel was van de backendarchitectuur. Daar werkte ik onder andere met AWS Lambda, SES en SNS in combinatie met microservices en andere cloud-functionaliteit.
SES werd daar gebruikt als onderdeel van applicatieprocessen waarbij vanuit de backend e-mailcommunicatie nodig was.
Die combinatie van managed AWS-diensten vond ik vooral krachtig omdat iedere component een duidelijke verantwoordelijkheid kon houden. De applicatie bevat de domeinlogica, terwijl diensten zoals SES de infrastructuur rondom communicatie afhandelen.
Mijn ervaring met AWS SES
Mijn ervaring met SES komt voornamelijk uit backend- en SaaS-omgevingen waarin e-mail onderdeel is van een groter proces.
Daarbij kijk ik tegenwoordig minder naar alleen het versturen van een e-mail en meer naar het volledige proces eromheen.
Wat gebeurt er wanneer verzending mislukt? Moet er opnieuw geprobeerd worden? Is het belangrijk dat het primaire proces doorgaat? Moeten bounces worden verwerkt? Hoe voorkomen we dat dezelfde e-mail meerdere keren wordt verstuurd?
Dat zijn uiteindelijk interessantere vraagstukken dan de API-call naar SES zelf.
SES is technisch vrij eenvoudig te gebruiken. Het goed ontwerpen van het proces eromheen bepaalt voor mij uiteindelijk hoe betrouwbaar de oplossing wordt.
Veelgestelde vragen die ik krijg over AWS SES
Waarom SES en niet zelf een mailserver beheren?
Omdat e-mailinfrastructuur weinig toevoegt aan de businesslogica van de meeste applicaties. Ik besteed die verantwoordelijkheid liever uit aan een managed dienst.
Verstuur je e-mails synchroon vanuit een request?
Bij eenvoudige situaties kan dat, maar bij belangrijke processen doe ik dit liever asynchroon. Het primaire proces hoeft niet afhankelijk te zijn van de snelheid of beschikbaarheid van een e-mailprovider.
Combineer je SES met andere AWS-diensten?
Ja. Juist de combinatie met bijvoorbeeld Lambda, SNS of queues maakt SES interessant binnen event-driven architecturen.
Wat is belangrijker dan het versturen zelf?
Weten wat er daarna gebeurt. Bounces, complaints, retries en idempotency zijn minstens zo belangrijk wanneer e-mail onderdeel is van een bedrijfsproces.
Zou je SES gebruiken voor iedere applicatie?
Niet automatisch. Wanneer een applicatie al sterk op AWS leunt, is SES voor mij een logische keuze. Ik kies uiteindelijk voor de oplossing die het systeem het eenvoudigst houdt.