Why SES is great — and when it isn’t
Amazon SES deserves respect. It is durable, cheap at scale, and deeply integrated into AWS. Plenty of serious email infrastructure sits on top of it — including products that look nothing like the SES console.
The mistake is treating “SES is great infrastructure” as “we should integrate SES first.”
Where SES wins
Choose SES (or stay on it) when:
- You already live in AWS and IAM is muscle memory
- Volume is high enough that raw unit cost dominates
- You want multi-region control and AWS-native event plumbing
- Your team will own logging, suppression, bounce/complaint handling, and DX
At that altitude, SES is often the correct economic choice. You are buying transport and accepting ops.
The SES tax nobody budgets for
Getting to a boring production send on SES usually includes:
- IAM users, roles, and policies
- Region choice and quotas
- Verified identities
- Configuration sets
- Bounce and complaint feedback (SNS, EventBridge, or something custom)
- CloudWatch (or silence)
- SDK wiring in every service that sends mail
Then, for many new accounts: a sandbox that only sends to verified recipients until AWS approves production access. That review is not a formality with a fixed SLA. Teams wait days. Some wait weeks. Some wait months.
If your goal this afternoon is a password-reset email in production, that path is a project — not a checkbox.
What a thin DX layer is for
A transactional email API does not replace SES’s economics at huge scale. It replaces the setup tax for the common case:
- API key instead of IAM archaeology
- One HTTPS send call
- Domain verification as SPF/DKIM in your DNS UI
- Logs and webhooks as product features
You can think of Notify as “the weekend project you would eventually build on top of raw delivery infrastructure” — already built, priced flat, opinionated toward minimalism.
Honest decision rule
| Your situation | Lean toward | | --- | --- | | Shipping auth/billing email this week | A thin email API | | Deep AWS ops + high volume + unit cost obsession | SES directly | | “We might need SES later” | Ship today with an API; revisit when volume or AWS strategy demands it |
“We might need SES later” is not a reason to delay the welcome email. You can migrate when the economics flip. See Migrate from AWS SES if you are going the other direction.