Clarification on SES sending rate quota
In the Managing your Amazon SES sending limits article, it says:
Sending rate—The maximum number of emails that Amazon SES can accept from your account each second. You can exceed this quota for short bursts, but not for sustained periods of time.
After getting out of the Sandbox, my sending rate was set to 14. This is serviceable for most tasks, though I'm afraid that my solution (described below) to batch sending (say, sending to 2500 emails) might violate the above constraint. I've looked elsewhere and could not find anything more precise than 'short burst' -- I don't know how fast (30 messages in a second, for instance), nor how long (5 seconds, for instance), this burst can be.
My current solution is to place message data in SQS records and process them with Lambda. I've set my batch size to 14, batch window to 1s, and concurrency maximum to 2 (I used provisioned concurrency for these lambdas). I've implemented the token bucket algorithm using a dynamoDB record -- the two lambdas contend for and replenish the tokens, exponentially backing off on failure. I've conducted two types of experiments: (a) batch (rapidly placing ~200 records/second in SQS) and (b) stream (placing records in SQS at roughly a rate equal to my send limit rate), and have found that, while my average throughput in this solution remains lower than 14 (roughly 11 in both cases), there are frequent 1 second intervals wherein I'll reach a throughput of 20+ messages (which are often followed by 1 second intervals of low throughput, say, 5 messages).[^1]
Here's a csv I downloaded from the Cloudwatch logs. The data is a from a stream experiment on 2400 messages. And below is a visualization of it:
At this point, I'm actually considering abandoning the SQS approach because of the above and because of obligatory 20-second long polling. Still, SQS has the advantage of easily retrying messages.
[1] To simulate sending an email, I print the message data along with some information about the lambda instance.
- Newest
- Most votes
- Most comments
You've set concurrency to 2, with a batch of 14 records each and a max window of 1 second. This results in up to 28 emails per second, and you can see this clearly in your CW graph. Why not reduce the concurrency to 1, which will limit it to 14 emails per second.
Alternatively, you can reach out to AWS to request a limit increase, if you require more than 14 emails per second.
Thank you for providing such a detailed description of your Amazon SES (Simple Email Service) sending rate situation and your current implementation. Let me clarify some points about SES sending rate quotas and offer some insights on your approach.
First, it's important to understand that the sending rate quota is designed to be flexible. While your account has a set maximum sending rate (in your case, 14 emails per second after moving out of the sandbox), Amazon SES does allow for short bursts above this rate. However, as you've noted, the exact definition of "short bursts" is not precisely specified.
Your current implementation using SQS and Lambda with a token bucket algorithm is a good approach to manage your sending rate. The fact that you're seeing an average throughput of around 11 messages per second, which is below your quota of 14, is actually a good sign. It indicates that you're not consistently exceeding your quota.
The occasional spikes to 20+ messages per second for short intervals are likely within the "short bursts" that Amazon SES allows. As long as these spikes are brief and balanced by periods of lower sending rates (which your data shows), you're probably not violating the sending rate quota.
However, if you're concerned about these spikes, you could consider adjusting your implementation:
-
Reduce your Lambda concurrency to 1 instead of 2. This might help smooth out the spikes, although it could also reduce your overall throughput.
-
Implement a slight delay between message sends within your Lambda function. This could help ensure a more consistent sending rate.
-
Fine-tune your token bucket algorithm parameters to be slightly more conservative.
Regarding your consideration of abandoning the SQS approach, it's worth noting that SQS provides important benefits like message persistence and automatic retries, which can be crucial for ensuring message delivery in case of temporary failures. The 20-second long polling is generally not a significant drawback for email sending use cases, as it helps reduce the number of empty receives.
If you do decide to move away from SQS, you might consider using a custom queueing solution with more granular control over polling and processing. However, this would require more development and maintenance effort.
In conclusion, based on the information provided, your current implementation seems to be working reasonably well within the constraints of the SES sending rate quota. The occasional short bursts above the quota are likely acceptable, but if you want to be more conservative, you can implement some of the suggested adjustments. Remember, if you consistently need a higher sending rate, you can always request a quota increase from AWS Support.
Sources
Managing your Amazon SES sending limits - Amazon Simple Email Service
Managing your Amazon SES sending quotas - Amazon Simple Email Service
answered 2 years ago
Relevant content
asked 4 years ago
asked 3 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
You cannot set the maximum concurrency limit below 2. See Step 5 here [https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-scaling.html].
Batch size sets the max number of concurrent records, not the expected amount. In practice, if many records are available, getting exactly 14 at a time is rare. The graph spikes (never hitting 28) likely because the time between token acquisition and sending varies. It’s possible that tokens are acquired in a way that avoids exceeding 14/s, but one Lambda might take longer to send, ‘waiting’ for another, causing both to send within the same second.
For the next month or two, 14 should be sufficient for my needs. I would still like some clarification as to what a 'short burst' means, because once I raise my rate to, say, 30, I will have the same confusion as above. Without this clarification, I can't actually know what throughputs are allowed (with my current approach) until they are in production (!), and the alternative is to underutilize my rate like crazy.
I'll allow someone with more SQS expertise than I to weigh in on the short burst aspect, and what you can expect.