Pricing
Build on Amazon SES, or buy a platform? The calculation nobody does
Updated 3 September 2026 · 5 min read · SendKernel
Amazon SES costs about $0.10 per thousand emails against roughly $0.40 for a platform, so at 100,000 messages a month you are choosing between spending about $10 and about $32. The difference is $22 — less than an hour of engineering time — and to capture it you build and then maintain contact storage, consent records, suppression, unsubscribe endpoints, bounce processing, DKIM management, and reputation monitoring. The break-even sits somewhere north of a million messages a month, and even there only if email matters enough to own.
The short version
- The price comparison is not platform minus SES. It is platform versus the fully loaded cost of the layer you would otherwise build.
- That layer is roughly six to ten engineering weeks to build and never finishes needing maintenance.
- At 100,000 messages a month the saving is about $22. At 5 million it is real money.
- SES is the right answer when email is strategically important and you have engineers to spare — not merely when it looks cheaper.
What SES gives you, precisely
Amazon SES accepts messages, authenticates domains, and reports delivery events. That is the complete list. It is excellent at all three, priced at roughly $0.10 per thousand messages, and scales further than almost anyone reading this will need.
What it does not give you is everything between a database row and a delivered campaign: no contact storage, no consent records, no suppression list, no unsubscribe endpoint, no templates, no dashboard, no per-customer limits, no reputation alerting, and no enforcement of any compliance rule whatsoever. SES will happily send a message with no unsubscribe link and no postal address to a purchased list. Whether that is permitted is entirely your problem.
The layer you build
Estimates below assume a competent engineer who has not built this before, which describes most people making the decision. They are for a first working version, not a polished one.
| Component | Rough effort | Why it is harder than it looks |
|---|---|---|
| Contact storage and import | 1 week | Deduplication, malformed addresses, and consent recorded at import rather than assumed |
| Suppression list | 3–5 days | Must be account-wide and permanent, and must be applied at send time rather than at import |
| Unsubscribe endpoints | 3–5 days | RFC 8058 one-click, tokens that never expire, and a GET that does not unsubscribe people via link prefetchers |
| Bounce and complaint processing | 1 week | SNS subscription, signature verification, idempotent handling of redelivered events |
| DKIM and domain verification | 3–5 days | Key rotation, DNS checking, and telling a user which of five records is wrong |
| Compliance injection | 3–5 days | Postal address and unsubscribe link added after composition so they cannot be removed |
| Reputation monitoring | 1 week | Rates computed over a rolling window, plus alerting someone reads and a threshold that actually stops sending |
| A dashboard non-engineers can use | 2–3 weeks | The part that gets deferred, and the reason marketing keeps asking for a deploy |
Where the break-even falls
| Monthly volume | SES messages | Platform | Monthly saving |
|---|---|---|---|
| 50,000 | ~$5 | $18 | ~$13 |
| 100,000 | ~$10 | $32 | ~$22 |
| 500,000 | ~$50 | $315 | ~$265 |
| 5,000,000 | ~$500 | Custom, call it $2,000 | ~$1,500 |
At 100,000 messages a month, eight weeks of engineering buys you $22 a month. Even ignoring maintenance entirely, that is a payback period measured in decades. At five million messages a month the saving is around $1,500 a month, the build pays for itself inside a year, and the calculation genuinely flips.
When SES directly is the right answer
- Volume above roughly a million messages a month, sustained rather than occasional.
- Email is strategically important — it is the product, or the product depends on it in a way that makes owning delivery worth engineering attention.
- You already run on AWS and want one bill, one IAM boundary, and one incident process.
- You need something genuinely unusual: custom routing, unusual event handling, or a data residency requirement no platform satisfies.
- You have engineers with capacity, and the maintenance will have an owner after the person who built it moves on.
When it is a mistake
- The reason is that SES looks cheaper on a pricing page. Below a million messages a month, it is not.
- Non-technical colleagues need to send campaigns. You are agreeing to build them a product, on your own time, forever.
- Nobody has volunteered to watch the complaint rate at three in the morning.
- You are pre-launch and building the email layer instead of the thing customers pay for.
One nuance worth knowing before you compare prices: SES pricing is not a single number. À-la-carte outbound is about $0.10 per thousand, but new accounts may land in a tier with different economics, and the crossover point depends on your volume. Model your actual number rather than taking $0.10 as a given.
Full disclosure, since it changes how you should read this: we run on SES ourselves. That makes us both an interested party and, for what it is worth, people who have actually built the layer described above and can tell you the estimates are not padded.
Questions people actually ask
- Is Amazon SES cheaper than an email platform?
- Per message, yes, by roughly four to one — about $0.10 per thousand against $0.40 or so. In total cost it is only cheaper above about a million messages a month, because below that the difference is tens of dollars monthly and you would spend six to ten engineering weeks building the layer that captures it, then maintain it indefinitely.
- What do I have to build if I use SES directly?
- Contact storage with consent records, an account-wide permanent suppression list, unsubscribe endpoints implementing RFC 8058 one-click, bounce and complaint processing from SNS with signature verification, DKIM and domain verification with DNS checking, compliance injection for the postal address and unsubscribe link, reputation monitoring with thresholds that stop sending, and a dashboard for anyone who is not an engineer.
- Can I use SES and a platform at the same time?
- Yes, and it is a reasonable arrangement: high-volume transactional traffic straight to SES from your application, marketing campaigns through a platform where non-engineers can work. A domain can carry multiple DKIM selectors, so both can authenticate on the same domain simultaneously.
- Does using SES directly give better deliverability?
- No. It gives you more control and more responsibility. Deliverability is determined by authentication, list quality, and complaint rate, and none of those improve because you called the API yourself. What changes is that the monitoring and the reaction when something goes wrong become entirely yours.
Model your own volume against SES pricing
The calculator takes your monthly volume and shows infrastructure cost, platform cost, and the difference — including the à-la-carte versus default-tier distinction that catches new AWS accounts.
Open the SES cost calculatorRead next
What bulk email actually costs in 2026
Cost per thousand emails across the major providers, the three billing traps that inflate an invoice, and how to work out your own number in five minutes.
Sending transactional email over an API without regretting it later
The integration decisions that are painful to reverse: retries, idempotency, bounce handling, and keeping receipts away from marketing mail.
The preflight checklist that should run before every send
Eight checks that should block a send rather than warn about it — identity, consent, suppression, quota, reputation — and why one shared path matters.