SysPad › Lessons › messaging lessons › Amazon SES

How Amazon SES works

Managed email sending (and receiving) at scale - the email leg of notification systems. Throughput is governed by an account send-rate quota; production senders queue via SQS and retry on throttle. $0.10 per 1,000 emails.

"Design a notification system" is a classic interview question, and email is always one leg of it. SES looks trivial, an API that sends email, until you meet its two real constraints: a send-rate quota you must engineer around, and a reputation system that can shut your account off harder than any throttle.

What you will learn

Why does every serious SES setup put a queue in front of it?
What is the sandbox and why does your first email not arrive?
How do bounce and complaint rates get accounts suspended?
What does email actually cost at scale?

The send-rate quota

Every SES account has a maximum send rate (emails per second) and a daily cap. New production accounts often start around 14/s; AWS raises it as your sending history proves clean. Exceed it and sends fail with throttling errors.

The sandbox trap

New SES accounts start in the sandbox: you can only send TO verified addresses, at a tiny rate. Every team hits this in their first deploy when emails to real users silently do not arrive. Production access is a request with a use-case review.

Reputation is the real quota

SES tracks your bounce rate and complaint rate. Sustained bounces above roughly 5%, or complaints above roughly 0.1%, put the account under review and can pause sending entirely, regardless of your rate quota.

Why does AWS police my bounce rate at all?

Because SES sends from shared IP pools: one spammer poisons deliverability for every other customer on those IPs. Gmail and Outlook score the sending IPs, so AWS aggressively protects the pool. Dedicated IPs exist for senders who want their own reputation.

Cost and the async shape

Email is cheap: about $0.10 per 1,000. A million welcome emails is $100. SES is also an async boundary: the user's request finished when the send was accepted, delivery happens later, so it never sits on your latency critical path.

⚓ In SysPad, wire API → SQS → SES and push the RPS up: the SES node saturates at its quota while the queue absorbs the difference. That picture is this whole lesson.

Flashcards

Black Friday: your order system needs to send 50k confirmation emails in a spike. SES quota is 100/s. What does the architecture look like?: Order events go to SQS; a worker drains the queue at ≤100 sends/s with retries on throttle. The spike becomes an 8-minute drain instead of a wall of errors.
Your staging environment sends email fine; production emails to customers vanish without errors in your logs. What did the team forget?: Requesting production access: the account is still in the SES sandbox, which only delivers to verified addresses. It is a console request with a review, not a code change.
Marketing imports a purchased list of 200k addresses and blasts it. Two days later ALL transactional email (password resets included) stops. Why?: The bounce/complaint rates from the bad list tripped SES reputation review, which pauses the whole account, not just the campaign. Separating transactional and marketing sending (separate accounts or configuration sets) contains that blast radius.

Sources

Open the SysPad canvas · Official Amazon SES documentation