Amazon SES costs $0.10 per 1,000 emails. That's the number on the pricing page. That's the number your CTO will quote when someone suggests paying for an email platform. It's technically accurate and practically meaningless.
SES is a pipe. It accepts an email and delivers it. Everything else — suppression management, deliverability monitoring, bounce handling, templates, analytics — is your problem. And "your problem" has a cost measured in engineering weeks, not dollars per thousand.
The real costs, line by line
No suppression list management
SES does not maintain a suppression list for you. If an address hard-bounces, SES adds it to an account-level suppression list — but only for hard bounces. Complaints, role-based addresses, spam traps, and soft bounces that should be suppressed? You build that yourself.
If you don't, you'll keep sending to bad addresses. Your bounce rate climbs. Amazon notices. They put your account under review, or they suspend it. The SES documentation even warns you about this — they expect you to handle suppression. They just don't give you the tools to do it.
Building a proper suppression system means SNS topic subscriptions for bounce and complaint notifications, a Lambda function or webhook consumer to process those events, a database to store suppressed addresses, and logic in your sending pipeline to check the list before every send. That's a project, not a configuration.
No deliverability dashboard
SES gives you CloudWatch metrics: sends, deliveries, bounces, complaints, rejects. Raw numbers. No reputation score. No inbox placement rate. No domain health assessment.
If you want to know whether Gmail is spam-foldering your emails, you need Google Postmaster Tools (separate setup, separate dashboard). If you want to correlate delivery metrics with campaign performance, you're building a data pipeline — CloudWatch to SNS to your analytics stack.
Most ESPs give you a deliverability dashboard out of the box. SES gives you CloudWatch Alarms and the AWS console. If you've ever tried to build an operational dashboard from CloudWatch, you know the pain.
IAM policy complexity
To send an email with SendGrid, you create an API key. It takes 30 seconds. One string, one HTTP header, done.
To send an email with SES, you need an IAM user or role with a policy that grants ses:SendEmail and ses:SendRawEmail permissions. You need to scope those permissions to verified identities using resource ARNs. If you're running in ECS, Lambda, or EC2, you need the right execution role attached with the right trust policy.
IAM is powerful. It's also a maze of principals, policies, conditions, and resource-level permissions that requires its own expertise to navigate. Every SES permission mistake results in an opaque AccessDenied error that tells you nothing useful.
Region-locked sending
SES is available in roughly 5 AWS regions: us-east-1, us-west-2, eu-west-1, ap-southeast-2, and a few others. If your application runs in a region without SES, you're making cross-region API calls.
Cross-region calls add latency. More importantly, they add cost — data transfer between AWS regions isn't free. If you're sending emails with attachments from ap-northeast-1 to SES in us-east-1, you're paying data transfer fees on every request.
Per-attachment charges
The $0.10/1,000 emails price covers the message itself. Attachments cost $0.12 per GB. Sending a 5MB PDF invoice to 10,000 recipients? That's 50GB of attachment data — $6.00 on top of the $1.00 sending cost. The attachment charge is 6x the email charge.
This adds up fast for transactional emails that include receipts, reports, or documents.
Sandbox mode
Every new SES account starts in sandbox mode. In sandbox, you can send a maximum of 200 emails per day, and only to verified email addresses. You cannot send to unverified recipients.
To get out of sandbox, you submit a support request to AWS. You explain your use case, your expected sending volume, how you handle bounces and complaints, and where you got your recipient list. Then you wait 24-48 hours for review.
This is a reasonable anti-abuse measure. It's also a cold start problem. If you're building an application and need to test email sending with real recipients during development, sandbox mode blocks you. Every other ESP lets you send immediately (with rate limits, not recipient restrictions).
No IP warmup automation
If you request dedicated IPs from SES (available for an additional cost), you manage the warmup yourself. SES does not automatically ramp sending volume. There's no warmup scheduler. You either manually control daily sending volume for 4-6 weeks, or you pay for a third-party warmup service.
Get the warmup wrong — send too much too fast — and you've burned the IP's reputation before it had a chance to build one.
No templates, no sequences, no campaigns
SES has a basic templating feature (SES templates with {{variable}} substitution), but there's no template editor, no version history, no preview. There are no drip sequences. No campaign scheduler. No A/B testing. No audience segmentation.
SES sends emails. That's it. Everything that makes email useful for a business — onboarding sequences, re-engagement campaigns, scheduled newsletters, segmented sends — you build from scratch or you bolt on another tool.
The engineering time cost
Here's a conservative estimate of what it takes to build what SES doesn't include:
| Component | Engineering time |
|---|---|
| Bounce/complaint processing (SNS + Lambda + DB) | 2-3 days |
| Suppression list with send-time checks | 1-2 days |
| Deliverability dashboard (CloudWatch + custom UI) | 3-5 days |
| Template system with variable rendering | 2-3 days |
| Queue-based sending with rate limiting | 2-3 days |
| Drip sequence engine | 3-5 days |
| Campaign scheduler | 2-3 days |
Total: 15-24 engineering days. At $150/hour for a senior developer, that's $18,000 to $28,800 — before you send your first production email.
And this is just the build cost. You still have to maintain it. Every AWS SDK update, every SES API change, every edge case in bounce processing becomes your on-call problem.
What $0.10 per 1,000 really costs
For a sender doing 100,000 emails per month:
- SES sending cost: $10/month
- Engineering build cost (amortized over 12 months): $1,500-2,400/month
- Ongoing maintenance: 2-4 hours/month ($300-600)
- Total real cost: ~$1,810-3,010/month
For the same 100,000 emails on PushMail at $0.003/email: $300/month. That includes validation, suppression, bounce handling, deliverability tracking, templates, sequences, campaigns, and webhook-based analytics.
SES is a building block, not a product
Amazon SES is good at what it does — delivering email at low cost and high throughput. If you have a platform engineering team that wants to build email infrastructure as a core competency, SES is a reasonable foundation.
But if you're a development team that needs to send email as part of your product — not as your product — SES is the most expensive cheap option available. The sticker price is $0.10 per thousand. The real price is weeks of engineering time and an ongoing maintenance burden that never ends.
PushMail includes everything SES doesn't: validation, suppression, deliverability tracking, sequences, campaigns, templates, and webhook-based analytics. Pay per email. No infrastructure to build.