Burst absorption with SQS
Producers enqueue a small send request and return immediately. Campaign launches, batch jobs and sign-up spikes drain at a controlled rate, and nothing is lost when a worker restarts.
Amazon SES Queued Sending
Amazon SES Queued Sending: Rate-Limited, Multi-Tenant Email on SQS and Lambda
Your application produces email in bursts, and SES accepts it at a fixed rate per second. We build the queue, the rate-limited consumer and the per-tenant isolation that sit between them, so spikes turn into a short backlog instead of throttling errors and lost messages.
- A send event arrives from the app or the campaign.
- Amazon SES is the send path.
- Authentication is SPF, DKIM, and DMARC on the sending domain.
- Delivery is an IP and a reputation you can see.
- Bounces and complaints return on the feedback loop.
- The mail that should reach an inbox does.
Last updated:
The problem this solves
Amazon SES enforces a maximum send rate per second and a 24-hour quota per account in each Region. Applications rarely send at a steady rate. A campaign launch, a nightly digest or a burst of sign-ups calls SES faster than the quota allows, and SES rejects the excess with a ThrottlingException.
Teams usually notice this in one of four ways:
- Lost or late email. In-process retries make the burst worse, and messages disappear when a container restarts mid-retry.
- No backlog visibility. Nobody can answer “how many emails are waiting, and how old is the oldest one?”
- One tenant hurts everyone. In a SaaS or agency setup, one customer’s bulk send uses up the shared rate, and one customer’s bad list pushes the account bounce rate toward the 5% level at which AWS places the account under review.
- Quota increases go unused. AWS raises your limit and nothing in the code reads the new value.
Who this is for
A good fit if you:
- Send in bursts that approach or exceed your account MaxSendRate
- Run a multi-tenant product (SaaS, marketing platform, agency) on one SES account
- Have mail that must not be lost, such as order confirmations, invoices or alerts
- Are migrating to SES and want to stop calling the email API inline as part of the move
Probably not a fit if you:
- Send a few thousand emails a day at a steady rate. Direct
SendEmailcalls with sensible retries are enough. - Need marketing campaign tooling (segmentation, a visual editor). That is an email marketing product, not a sending architecture.
How we build it
The architecture follows our published SES queued sending reference pattern. A typical engagement runs in four steps.
1. Discovery. We read your current send path, SES account quotas (GetAccount), configuration sets, event destinations and CloudWatch history. We map every producer: application handlers, batch jobs, third-party integrations. Then we agree on the mail streams that need separate treatment, usually transactional, time-critical and marketing.
2. Design. We choose standard or FIFO queues per stream. Standard is the default; FIFO is used when per-tenant ordering or fairness matters, with MessageGroupId set to the tenant. We size consumer concurrency and batch size from your measured per-call latency so the aggregate rate stays at roughly 70–80% of MaxSendRate. We also define the retry rules: which SES errors are retriable and which are permanent.
3. Build. Queues, DLQs, Lambda consumers, configuration sets, event destinations and alarms are delivered as infrastructure as code in your repository. Producers change in one place: they enqueue instead of sending.
4. Prove it. We load-test the burst you expect, check that throttling is absorbed and that nothing lands in the DLQ without a reason, and run the old and new paths side by side for one mail stream before cutting over the rest.
Tenant isolation and fair scheduling
Isolation is where most home-grown queues fall short. We separate tenants at three levels:
| Level | Mechanism | What it protects |
|---|---|---|
| Queue | FIFO MessageGroupId per tenant, or a queue per high-volume tenant | One tenant’s backlog cannot block another’s mail |
| Sending | Configuration set or SES tenant per customer or mail stream | Events, reputation metrics and dedicated IP pools stay separate |
| Suppression | Tenant-scoped suppression where SES tenant management is used | A complaint storm against one tenant does not suppress sends for the rest |
When one tenant’s bounce or complaint rate spikes, an alarm pauses sending for that configuration set only. Everyone else keeps sending.
Monitoring and operations
We add the alarms that answer the questions operations teams actually ask:
- Is the backlog growing? SQS
ApproximateAgeOfOldestMessageper queue - Are messages failing? DLQ depth and Lambda error counts
- Are we hitting the quota? Throttling counts from the consumer
- Is reputation at risk? SES
Reputation.BounceRateandReputation.ComplaintRate, alarmed below the levels at which AWS reviews the account
Each alarm comes with a runbook entry: what it means, what to check, and how to redrive or pause.
Deliverables
- Architecture decision record covering queue type, sizing math, retry rules and isolation model
- Infrastructure as code for queues, DLQs, consumers, configuration sets, event destinations and alarms
- Producer changes, or a small client library your team calls instead of SES directly
- Load-test results for your expected peak
- Operations runbook and a handover session with your engineers
Outside the scope: email content, list acquisition and campaign strategy. Deliverability work such as authentication, IP warm-up and reputation recovery is covered by our Amazon SES deliverability service. Many clients combine the two.
Proof
We built the SES infrastructure behind TargetBay’s 200M+ emails a month. That work includes an SNS/SQS/Lambda event pipeline for bounces and complaints, dedicated IP warm-up and a migration from SendGrid. The TargetBay SES case study has the details.
Related services and guides
- Amazon SES deliverability consulting: authentication, IP warm-up, reputation
- SES migration from SendGrid, Mailgun or Postmark
- Reference architecture: SES queued sending on SQS and Lambda
- Amazon SES tenant management for multi-tenant senders
- SES global endpoints, sending rate and worker concurrency
- Reliable queue systems on AWS: SQS, Kafka and Redis
Key Features
Consumer sized to your quota
Lambda event source mapping MaximumConcurrency and batch size are set from the MaxSendRate that the SESv2 GetAccount API reports, with headroom, and re-read on a schedule so quota increases get used.
Throttling and retry handling
ThrottlingException is treated as retriable through partial batch responses. Permanent failures such as suppressed addresses are logged and dropped, never retried in a loop.
Dead-letter queue and redrive
Messages that keep failing land in a DLQ with enough context to fix the cause, then go back to the source queue with SQS redrive.
Tenant isolation and fair scheduling
Per-tenant configuration sets or SES tenants keep events, reputation metrics and suppression scope separate. FIFO queues with MessageGroupId per tenant stop one large send from starving everyone else.
Backlog and reputation monitoring
CloudWatch alarms on queue age, DLQ depth, throttling counts, and SES bounce and complaint rates, with a runbook that pauses only the offending configuration set.
Why Choose FactualMinds?
We have run SES at high volume
We built the SES infrastructure TargetBay uses to send 200M+ emails a month, including the SNS/SQS/Lambda event pipeline for bounces and complaints. See the published case study.
Infrastructure as code, handed over
Queues, consumers, alarms and configuration sets ship as IaC in your repository, with a runbook your team owns after we leave.
Measured, not assumed
We size concurrency from your own per-call latency and quota, then load-test the burst you expect before production traffic depends on it.
Email specialists, not generalists
Queued sending is one part of our SES work, alongside deliverability and provider migration. Your queue design and your sender reputation get reviewed together.
Step-by-Step Guides
Implementation guides for this service from our team of AWS experts.
Amazon SES Tenant Management: The Ultimate Enterprise Guide
SES tenants (GA Aug 2025) add $0.005/tenant/mo reputation isolation—when ISV platforms need them vs configuration sets alone, with IAM, pricing, and IaC.
Read guide
AWS SES Global Endpoints (MREP): The Enterprise Decision Guide
SES Global Endpoints (Dec 2024) add $0.03/1k for active-active failover across two regions. MREP decision matrix, replication rules, Tenant Management, and a reproducible readiness benchmark — for architects choosing regional vs multi-region email.
Read guide
AWS SES Marketing Automation with EventBridge and Step Functions (2026)
When to keep Customer.io/Loops vs build journeys with EventBridge + Step Functions + SES — stream isolation, RFC 8058, Pro for DIPs, and a first-party journey architecture checklist.
Read guide
Amazon SES for eCommerce: Scaling Promotional and Transactional Email That Actually Reaches the Inbox
Amazon SES is the most cost-effective email infrastructure for high-volume retail sending — but inbox placement requires dedicated IPs, proper authentication, and automated bounce handling. Here is how to do it right.
Read guide
How to Build Reliable Queue Systems on AWS (SQS, Kafka, Redis)
SQS, MSK Kafka, and Redis queues are not interchangeable. Each has different cost models, ordering guarantees, and failure modes. This guide covers when to use each, how to autoscale workers on queue depth, and how to build idempotent consumers.
Read guide
Implementation Reference
Architecture patterns, decision trees, and glossary terms that map to this engagement.
Amazon SES queued sending — SQS + Lambda rate limiting for burst and multi-tenant email
Reference architecture for queued Amazon SES sending: an SQS buffer, a Lambda consumer whose maximum concurrency is sized to your SES MaxSendRate, retry with backoff on ThrottlingException, DLQ redrive, per-tenant configuration sets, and CloudWatch reputation alarms.
Open reference
Multi-Tenant SaaS on AWS — Pool, Silo, and Bridge
Production-ready multi-tenant architecture for SaaS on AWS. Covers tenant isolation models (pool, silo, bridge), per-tenant cost attribution, noisy-neighbor mitigation, and the trade-offs CTOs actually wrestle with at Series B and beyond.
Open reference
Event-driven microservices on AWS — EventBridge, Pipes, and the Outbox Pattern
Production event-driven architecture on AWS — EventBridge custom buses, EventBridge Pipes for the transactional outbox, SQS dead-letter queues, Step Functions for orchestration, and Lambda or Fargate workers. Decouple services without dual-writes.
Open reference
Amazon CloudWatch
AWS monitoring and observability service for collecting metrics, logs, traces, and setting alarms across AWS infrastructure and applications.
Open reference
AWS CloudTrail
AWS audit logging service that records every API call and account activity across your AWS infrastructure for security, compliance, and operational investigation.
Open reference
From Our Blog
In-depth guides and best practices from our certified AWS architects.
Amazon SES isBotEvent on Open and Click events (August 7, 2026)
On August 7, 2026 SES added isBotEvent with two values, Likely and Unlikely, on Open and Click notifications. That is 2 of the 10 published event types, and existing configuration-set destinations pick the field up with no new setting.
Read articleAmazon SES Dedicated IP Warm-Up: Standard vs Managed (2026)
On 3 July 2025 AWS published a dedicated-IP ramp from 1,050 emails on day 1 to 21 million on day 40. Standard dedicated IPs auto-warm on a fixed 45-day percentage; managed dedicated IPs warm per ISP. Use the fast ramp only in the 40–60% engagement band.
Read articleAmazon SES Cold Email for B2B: Compliance and Deliverability Setup (2026)
Legitimate B2B outbound on SES in 2026: sandbox exit, SPF/DKIM/DMARC, RFC 8058, Microsoft May 2025 bars, warm-up, and when Pro DIPs beat shared pools — with a first-party compliance checklist.
Read articleFrequently Asked Questions
Do we need queued sending if our volume is low?
Usually not. If your peak send rate stays well under your account MaxSendRate and losing an email on a process restart is acceptable, direct SendEmail calls are fine. Queued sending pays off when you have bursts (campaigns, digests, batch notifications), several tenants sharing one SES account, or mail that must not be lost.
Will a queue delay password resets and one-time passcodes?
Only if they share a queue with bulk mail. We give time-critical mail its own queue and a reserved share of the send rate, so a marketing backlog cannot delay a login code.
Can you add queueing to our existing SES setup without a rewrite?
In most cases, yes. The change is at the point where your application calls SES: it writes a message to SQS instead, and a new consumer does the sending. Templates, identities and configuration sets stay as they are. We usually run old and new paths side by side for one tenant or mail stream before switching the rest.
How is this different from your SES migration service?
Migration moves you from another provider (SendGrid, Mailgun, Postmark) to SES. Queued sending is the sending architecture on SES itself. Many migrations include it, because the move is a good time to stop calling the email API inline.
What does the queue-and-consumer layer cost?
Little next to SES. Our reference architecture works through a 10 million emails per month example: about $11 of SQS and Lambda against about $1,000 of SES sending at a-la-carte rates. The pattern page shows the assumptions behind that estimate.
How do you stop "Maximum sending rate exceeded" errors?
By keeping the aggregate call rate below MaxSendRate on purpose instead of hoping for it. The consumer concurrency and batch size are derived from the quota, throttled messages go back to the queue after the visibility timeout, and an alarm on throttling counts tells you when latency changes have pushed the rate up.
Compare Your Options
In-depth comparisons to help you choose the right approach before engaging.
Migrating from SendGrid to AWS SES: Complete Guide
Practical migration guide from SendGrid to AWS SES. Email deliverability setup, features, and infrastructure integration.
Read comparison
Migrating from Mailgun to AWS SES: Step-by-Step Guide
Technical migration guide from Mailgun to AWS SES. Email deliverability, SMTP, configuration, and cost comparison.
Read comparison
Stop losing email to throttling and bursts
Tell us your peak send rate, your SES quota and how many tenants share the account. We will tell you whether you need a queue, and what it should look like.