aws ses rate limit

Amazon SES enforces two distinct sending limits per AWS Region, and a "rate limit" error can come from either one:

• Maximum sending rate — the number of emails SES accepts from your account per second. You can burst above it briefly, but not sustain it.
• Sending quota — the maximum number of emails you can send in a rolling 24-hour period.

How the error surfaces depends on the interface you use:

• API / AWS SDK: a ThrottlingException with the message Maximum sending rate exceeded or Daily message quota exceeded.
• SMTP interface: 454 Throttling failure: Maximum sending rate exceeded or 454 Throttling failure: Daily message quota exceeded.

When you hit a limit, SES drops the message and does not retry it for you — handling the retry is your responsibility.

What causes the AWS SES rate limit error?

• Your account is still in the SES sandbox. New accounts start sandboxed: 200 emails per 24-hour period, a maximum rate of 1 email per second, and you can only send to verified addresses/domains or the SES mailbox simulator.
• You're calling SES faster than your allocated send rate. Bursts of concurrent SendEmail/SendRawEmail calls (e.g. a queue draining all at once) exceed your per-second rate even if your daily quota is fine. This produces Maximum sending rate exceeded.
• You've used up your 24-hour quota. Sustained volume hits the daily cap and produces Daily message quota exceeded.
• Quotas are per Region. Sending from a Region where your account has a lower (or sandbox) quota can throttle you unexpectedly.

Note that SES quotas are counted by recipient, not by message — a single email to 50 recipients counts as 50 against your quota.

How do I fix the AWS SES rate limit error?

1. Throttle sends on your side to stay under your rate. Cap concurrent calls so you never exceed your max send rate. AWS's own guidance suggests a rate limiter (for example, Google Guava's RateLimiter in Java) or evenly spreading delivery over time rather than firing in bursts.

2. Retry with exponential backoff, and add jitter as a general best practice. A throttling error is retriable. AWS's SES documentation recommends waiting up to about 10 minutes before retrying after a throttling error — this guidance is generic to both the rate-exceeded and daily-quota-exceeded variants, and for the daily-quota case it may not actually help since that quota resets on a rolling 24-hour window rather than a fixed timer. Adding jitter to your backoff (so retries don't synchronize into a new burst) is standard AWS retry best practice, though it isn't specific to SES.

import time, random, botocore.exceptions

def send_with_retry(ses, args, max_attempts=5):
    for attempt in range(max_attempts):
        try:
            return ses.send_email(**args)
        except botocore.exceptions.ClientError as e:
            if e.response["Error"]["Code"] in ("Throttling", "ThrottlingException"):
                sleep = min(2 ** attempt, 30) + random.random()
                time.sleep(sleep)
                continue
            raise
    raise RuntimeError("SES throttled after retries")

3. Check your current quota. In the SES console (Account dashboard) or via the GetSendQuota API, confirm your Max24HourSend, MaxSendRate, and SentLast24Hours. This tells you which limit you're actually hitting.

4. Leave the sandbox / request a quota increase. If you're sandboxed, request production access from the SES console (Account dashboard → "Request production access"); AWS typically responds within 24 hours. If you're already in production and consistently near your ceiling, request a higher sending rate or 24-hour quota through the AWS Service Quotas console or a Support case. For healthy production senders, AWS often raises quotas automatically before you need it.

5. Smooth out spikes architecturally. Buffer outbound mail through a queue (e.g. SQS) with a consumer that releases messages at a fixed rate matched to your MaxSendRate, instead of sending the moment events occur.

If you send through Courier, Courier manages SES sending on your behalf and applies provider-aware retry/backoff, so transient SES throttling is handled without dropping the notification.