Why Amazon SES Is the Most Expensive “Cheap” Email Provider
Amazon SES advertises the lowest price in email: $0.10 per 1,000 messages. It’s true, and it’s the number that wins spreadsheets. But that price buys you exactly one thing — bytes leaving a mail server. Everything you actually need to run transactional email — knowing what bounced, catching a spam pattern before AWS suspends you, seeing a deliverability graph — is left as an exercise for the reader. We’re not theorizing here — we launched Mailer To Go on SES ourselves, and it’s the reason we don’t run there anymore. This post prices that exercise. Methodically, the headline $0.10 becomes an effective $4–6 per 1,000 by the time you can operate safely — and by then you’ve rebuilt, at your own expense, what MailerToGo, SendGrid, and Mailgun include in the box.
The promise
SES sells itself as email at AWS scale and AWS prices: pennies per thousand, elastic, pay-as-you-go, right next to the rest of your stack. For raw throughput, it delivers.
The reality: SES is a sending pipe, not an email platform
Send a message through SES and ask the questions any transactional sender has to answer:
- How many bounced in the last hour, and which addresses?
- What’s my complaint rate right now — am I about to trip AWS’s 0.1% limit and get paused?
- Which campaign or code path is generating the spam complaints?
- Is my delivery rate dropping for a specific mailbox provider?
- Who unsubscribed, and are they suppressed everywhere?
SES answers none of these out of the box. There is no dashboard, no event feed you can read, no suppression UI, no reputation graph, no anomaly detection. The data exists only as a firehose of individual events you must catch, store, aggregate, and visualize yourself. And you must — SES enforces a hard bounce rate under ~5% and complaint rate under ~0.1%, and if you blow past them, the first “dashboard” you’ll see is the email telling you your account is under review.
What you have to build
To recognize and prevent spam and abuse — the table stakes of transactional email — you wire up a pipeline for every event SES emits: send, delivery, bounce, complaint, reject, open, click. Track everything you need to stay safe and that’s easily 5 to 10 events for every message you send.
SES ──(configuration set event destination)──► SNS topic
│
▼
SQS queue (buffer so nothing is lost)
│
▼
Lambda (parse, run your spam/deliverability checks, write to your DB)
│
┌───────────┴───────────┐
▼ ▼
CloudWatch metrics your database
+ dashboards (suppression, history)
│
▼
the graph SES never gave you
Here’s the trap: that pipeline is billed per event, not per email. So the monitoring you build to watch for spam and deliverability problems costs 5–10× what the sending costs — and the multiple grows as you get more careful.
Pricing the exercise
Take a realistic SaaS sending 1,000,000 transactional emails/month. With full event tracking that’s roughly 7 million events/month flowing through the pipeline. Illustrative US-region figures (verify current AWS pricing; the point is the shape, not the cent):
| Layer | What it buys you | ~$/month | ~$/1,000 |
|---|---|---|---|
| SES sending | The message leaves | $100 | $0.10 |
| SNS | Fan out ~7M events | ~$4 | ~$0.00 |
| SQS | Buffer events reliably | ~$8 | ~$0.01 |
| Lambda | Parse ~7M events, run spam/deliverability checks, write to your DB | ~$60 | ~$0.06 |
| CloudWatch (custom metrics + PutMetricData + Logs) | The bounce/complaint/delivery/reputation graphs SES omits — high-cardinality by domain, campaign, and mailbox provider | ~$450 | ~$0.45 |
| NAT / data transfer | Let it talk inside your VPC | ~$35 | ~$0.04 |
| Event-processing subtotal | the machinery that watches for spam & deliverability | ~$560 | ~$0.56 |
| SES sending, for comparison | $100 | $0.10 |
Read that again: the monitoring costs roughly 5–6× the email itself. The cheapest line on an SES bill is the sending. CloudWatch is the expensive part — custom-metric cardinality is the silent killer, because to actually spot abuse you need metrics broken out by sending domain × event type × mailbox provider, and that count explodes. (AWS’s own answer to “SES has no dashboard,” Virtual Deliverability Manager, is a paid add-on on top of all this — another ~$0.07–0.12 per 1,000.)
And that’s still only the AWS invoice. The other half is people:
| Layer | ~$/month | ~$/1,000 | |
|---|---|---|---|
| Build the pipeline (amortized, year one) | 2–4 weeks to design SNS/SQS/Lambda + suppression + alerting | ~$2,000 | ~$2.00 |
| Maintain + on-call | it lags, AWS changes an API, a new event type appears | ~$1,500 | ~$1.50 |
| Fully-loaded effective cost | ~$4–6 / 1,000 |
The $0.10 was real. It was just the first — and smallest — line item.
It’s worse at scale, not better
The usual defense of SES is “but it’s unbeatable at volume.” It isn’t, and this is why: sending scales linearly ($0.10/1,000) while the event-processing scales against you. More email means more events (5–10×), more Lambda invocations, and — worst of all — higher CloudWatch metric cardinality as you add domains, campaigns, and finer-grained abuse monitoring. The bigger and more careful you get, the more the observability tax dominates. It’s not a scale advantage; it’s a scale trap.
The maze
The deeper problem isn’t the total — it’s the shape of the total. Your “SES cost” isn’t one number you can compare against a competitor; it’s smeared across six services, a VPC, and an engineering roadmap. Every piece is AWS-specific: configuration sets, SNS topic policies, CloudWatch metric math, IAM. None of it is portable. The more you build to make SES usable, the more you’re locked into a bespoke stack that only works on AWS and only your team understands — and the harder it becomes to answer the one question a business should be able to answer easily: what does sending email actually cost me, and is it any good?
We know because we tried
We didn’t reason our way to this from a spreadsheet — we launched Mailer To Go on SES. And we hit exactly the wall this post describes: once the fully-loaded cost of operating SES sat underneath us, we couldn’t put together an offer that was a better value for our customers than simply telling them to use a competitor would have been. Our real cost on SES was higher than the sticker price of the very providers we set out to beat. The specific killer: the events we pushed into CloudWatch and Lambda just to watch for spam and deliverability problems ran 5–10× the cost of the SES sending itself. The cheapest thing on the bill was the email; the expensive part was being able to see it. So we rebuilt the delivery stack — dashboards, event pipeline, suppression, and reputation tooling — as our own infrastructure, not as a tax bolted onto someone else’s pipe. That’s the difference you’re paying for, and it’s why the number on our pricing page is the whole number.
Don’t take our word for it
The pattern is well-documented — starting with AWS itself:
- AWS makes you build the monitoring. Amazon’s own guidance is to set up bounce and complaint notifications through SNS and event publishing and process them yourself — there is no built-in handling (AWS: set up notifications for bounces and complaints).
- And AWS will pause you if you don’t. SES enforces bounce and complaint thresholds and puts accounts under review when they’re crossed; clearing a review can take days to weeks (AWS: sending review process).
- CloudWatch is a known bill trap. Its per-metric, cardinality-driven pricing turns a few dollars of monitoring into hundreds per month once you break metrics out by dimension — exactly the granularity you need to spot abuse (CloudWatch pricing can hit $300/month by default).
- Independent reviews keep naming engineering time as SES’s biggest hidden cost — the $0.10 sending price sits next to hundreds of dollars a month in developer time for bounce handling, warm-up, and monitoring, and the recurring verdict is that SES only pays off if you already run an AWS/DevOps practice at volume (SendGrid vs AWS SES).
One honest reconciliation: casual pricing guides put basic SES CloudWatch monitoring at $10–30/month. That’s the toy version — enough to draw a graph, not enough to catch abuse. The high-cardinality metrics that actually flag spam and deliverability problems (by domain, campaign, and mailbox provider) are the ones that run into the hundreds. That gap is the story.
The belt-and-suspenders alternative
MailerToGo — like SendGrid and Mailgun — includes what SES makes you build: a dashboard, event webhooks, delivery/bounce/complaint analytics, automatic suppression, reputation management, and spam/abuse controls, in one per-message price. That number is directly comparable, head-to-head, against any peer — no six-service reconstruction, no per-event surprise, no metric-cardinality bill that grows faster than you do.
The honest nuance, because the math deserves it: SES’s sending price really is the lowest, and if you truly fire-and-forget with zero monitoring, you’ll pay pennies — right until your bounce or complaint rate trips a limit and AWS pauses you with no warning. The moment you build the monitoring that keeps you safe to send, the bill inverts, and it inverts harder the more you grow.
Cheapest to buy, most expensive to own.
Comparing directly? See Mailer To Go vs Amazon SES and, when you’re ready, how to migrate from Amazon SES. New to the deliverability side? Start with email authentication, end to end and transparent per-message pricing.