- Newest
- Most votes
- Most comments
In on-demand mode read throttling occurs when you exceed twice your previous peak within 30 minutes, or you exceed your partition throughput limit of 3000 RCU per second.
While it may appear you are not exceeding the 3000 RCU, that is because CloudWatch works on a per-minute granularity, as thats the period DynamoDB emits metrics to CloudWatch. This means that you see a per min value, which is the average per second consumption within those 60 seconds.
The first step to overcoming a hot partition/key is to enable CloudWatch Contributor Insights, this will give you insight into which key(s) are causing the issue. From there you can understand if you can address the issue with some changes to your access patterns/code. If not then you may look into implementing a caching solution such as DAX which can offset your reads from the table to be served by DAX.
If you are using Strongly Consistent Reads, I would also suggest changing to Eventually Consistent Reads which can half your read throughput consumption.
Relevant content
- asked a year ago
- asked 9 months ago
- Accepted Answerasked 3 years ago
- asked 3 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 7 months ago
We are using eventually Consistent Reads only. Added GSI Reads and throttles graph for reference
The issue, nor the suggested fixes do not change. Enable CCI, see what keys are hot and work out a fix in your access patterns. If thats not possible, use a cache in front such as DAX which is API compatible with DynamoDB.