I'm working on developing a consumer SaaS product that requires sending various types of transactional emails like signup verifications, welcome messages, password resets, alerts for unusual logins, billing notifications, etc. Based on my research, AWS Simple Email Service (SES) appears to be the go-to option for this need, though I've noticed that Amazon Simple Notification Service (SNS) can also handle email delivery. My question is: what's the best way to set up AWS SES for sending these transactional emails? Should I push the emails into an SQS queue with a worker handling the sending process, or can my ECS Fargate task connect directly to SES to send them out?
6 Answers
SES isn't inherently a queued service, so if you're expecting high traffic, it's best to integrate SQS with a Lambda processor. Just remember there are size limits for SQS messages if you're planning to include attachments, so plan accordingly!
For managed options, using SQS with polling is a solid choice, especially for differentiating between immediate emails, like OTPs, and others that can wait, like password change notifications. You can mix it up with direct SES calls as needed.
Yeah, I just worry about losing important emails, like the verification ones. I'm evaluating two setups: ECS Fargate → SQS → Lambda → SES or ECS Fargate → SES. What are the benefits of the first?
I’d just connect your Fargate task directly to SES. Sending directly works like any other SMTP service, keeping the setup straightforward and effective.
Transactional emails are really critical. The last thing I want is for those to get lost.
I recommend setting up a queue and having a worker handle the email sending. Using SNS can also help you gather analytics. I recently built a queue with a database instead of SQS, but honestly, SQS is probably easier to use in this situation.
You're thinking about SQS with Lambda, right? I'll definitely look into that approach.
I personally manage my own task queue and just add delays to non-urgent emails. For my small SaaS, this approach is scalable enough for now, even if it won’t hold up globally.
You can directly use the SES API for sending emails. Your API call limit will depend on your configured sending rate with AWS SES. And don't forget, SNS is great for tracking delivery stats like sent, delivered, opened, clicked, and bounced. If all of this sounds too complicated, you might consider self-hosted services like Sendy or SaaS options like Sendune for easier management.
You might want to try sending with SES directly first, and if emails fail, then you can always queue them via SQS to retry with Lambda.