Why is my on-demand DynamoDB table being throttled?

Last updated: 2021-06-18

My on-demand Amazon DynamoDB table is being throttled.

Short description

Here are two common reasons why on-demand tables might be throttled:

  • The traffic is more than double the previous peak.
  • The traffic exceeds the per-partition maximum.


Amazon DynamoDB on-demand is a flexible option capable of serving thousands of requests per second without capacity planning. DynamoDB on-demand offers pay-per-request pricing for read and write requests so that you pay only for what you use. DynamoDB tables using on-demand capacity mode automatically adapt to your application’s traffic volume. However, tables using the on-demand mode might still throttle.

The traffic is more than double the previous peak

You might experience throttling if you exceed double your previous traffic peak within 30 minutes. It's a best practice to spread your traffic growth over at least 30 minutes before exceeding double your previous traffic peak. Use the ConsumedReadCapacityUnits metric in Amazon CloudWatch to monitor traffic to the table. For more information, see DynamoDB metrics and dimensions.

For new on-demand tables, you can immediately drive up to 4,000 write request units or 12,000 read request units, or any linear combination of the two. For an existing table that you switched to on-demand capacity mode, the previous peak is half the previous provisioned throughput for the table—or the settings for a newly created table with on-demand capacity mode, whichever is higher. For more information, see Initial throughput for on-demand capacity mode.

The traffic exceeds the per-partition maximum

Each partition on the table can serve up to 3,000 read request units or 1,000 write request units, or a linear combination of both. If the traffic to a partition exceeds this limit, then the partition might be throttled. To resolve this issue:

  1. Use CloudWatch Contributor Insights for DynamoDB to identify the most frequently accessed and throttled keys in your table.
  2. Randomize the requests to the table so that the requests to the hot partition keys are distributed over time. For more information, see Using write sharding to distribute workloads evenly.