Two separate limits, easy to conflate
The daily quota is a total-messages-per-rolling-24-hour-window cap; the sending rate is a maximum-per-second cap. An account can be well under its daily quota and still get throttled on rate if it tries to send a large batch too quickly, and conversely can send at a perfectly acceptable rate all day and still eventually hit the daily ceiling. They're diagnosed and fixed differently, which is exactly why AWS returns different exceptions for each.
Different exceptions, different fixes
Exceeding the daily quota returns `LimitExceededException` or `ServiceQuotaExceededException`, fixed by waiting for the rolling window to free up capacity or by requesting a higher quota. Exceeding the per-second rate returns `Throttling`, fixed by retrying with exponential backoff and jitter, and by bounding your own concurrency below the account's actual rate rather than letting every worker send independently. Both have dedicated `/ses/errors` pages precisely because the correct response to each is different enough that conflating them wastes time.
Quotas rise automatically, and can be requested to rise faster
AWS raises both the daily quota and the per-second rate over time as an account's sending reputation builds — consistently low bounce and complaint rates are the main input to that. To ask for more directly: request increased quotas in the same submission that asks to leave the SES sandbox, or once the account is already out of the sandbox, open a new case in the AWS Support Center — that's the actual mechanism, not a generic "Service Quotas" self-service form.
The quota is shared across everything sending from that account
Both limits apply to the AWS account as a whole, not to a single application or process — parallel workers, background jobs, and any other application sharing the account all draw from the same daily and per-second budget. A rate limiter or a queue that respects the limit inside one process does nothing to prevent a second, uncoordinated process from pushing the shared total over the line.
The daily quota counts recipients, not messages
A single SendEmail call to 10 recipients spends 10 units of the daily quota, not one — a detail that catches people right when a batch send unexpectedly exhausts the day's budget faster than the message count suggested it would. AWS's own guidance is one SendEmail call per recipient rather than a multi-recipient call, partly for this reason and partly because a multi-recipient call fails as a whole if any part of it is rejected.
Why it matters
Confusing the daily quota with the per-second rate leads directly to the wrong fix — retrying a daily-quota exhaustion with backoff does nothing but waste attempts until the rolling window frees capacity, and requesting a quota increase for what's actually a rate-throttling problem doesn't address the burst behavior causing it.
How to check it
aws sesv2 get-account --query 'SendQuota'Common questions
What's the difference between the SES daily quota and the sending rate?
The daily quota is a total message count allowed in a rolling 24-hour window. The sending rate is a maximum number of messages per second. You can be well within one and still hit the other, since they're independent limits with different failure exceptions.
Does the SES daily quota reset at midnight?
No, it's a rolling 24-hour window, not a fixed calendar-day reset. Capacity frees up gradually as older sends age out of the window rather than resetting all at once.
Why am I getting throttled even though my app respects the rate limit?
The limit is shared across the whole AWS account, not scoped to a single process. Any other application, background job, or worker sending from the same account draws from the identical per-second budget, and an uncoordinated second sender can push the shared total over the line.