Troubleshooting throttling issues for on-demand mode - Amazon DynamoDB
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Troubleshooting throttling issues for on-demand mode

DynamoDB tables that use on-demand capacity mode automatically adapt to your application's traffic volume. However, tables that use the on-demand mode might still throttle. This topic discusses how to troubleshoot common throttling issues for on-demand tables.

The traffic is more than double the previous peak

If you exceed double your previous traffic's peak within 30 minutes, then you might experience throttling. Before you exceed your previous traffic's peak, we recommend that you spread your traffic growth over at least 30 minutes. To monitor traffic to the table, use the ConsumedReadCapacityUnits metric in Amazon CloudWatch. 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 a linear combination of both.

For an existing table that you switched to on-demand capacity mode, the previous peak is one of the following values:

  • Half the previous provisioned throughput for the table

  • The setting for a newly created table with on-demand capacity mode

For more information, see Initial throughput for on-demand capacity mode.

The traffic exceeds the per-partition maximum

Each partition on a 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, take the following actions:

  1. Use CloudWatch Contributor Insights for DynamoDBto 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 in your DynamoDB table.

A hot key may be causing throttling issues

In DynamoDB, a partition key that doesn’t have high cardinality can result in many requests which target just a few partitions. If a resulting hot partition goes past the partition limits of 3000 RCU or 1000 WCU per second, it can result in throttling.

The diagnostic tool CloudWatch Contributor Insights (CCI) can help you debug this by providing CCI graphs for each table’s item access patterns. You can continuously monitor your DynamoDB tables' most frequently accessed keys and other traffic trends. For more information about CloudWatch Contributor Insights see, CloudWatch Contributor Insights for DynamoDB. For more information, see Designing partition keys to distribute your workload in DynamoDB and Choosing the Right DynamoDB Partition Key.

The traffic exceeds the per-table account quota

For on-demand tables, the table-level read throughput and table-level write throughput quotas apply at the account level. By default, the table throughput has a maximum of 40,000 read requests units and a maximum of 40,000 write requests units. If the traffic to a table exceeds the per-table account quotas for throughput, then the table might experience throttling. To resolve this issue, use the Service Quotas console to increase the table-level read throughput and write throughput quotas for your account.

The global secondary index of your table is throttled

If your DynamoDB table has a secondary global index that's being throttled, then the throttling might create back pressure throttles on the base table. For more information, see How does throttling on my global secondary index affect my Amazon DynamoDB table and Using Global Secondary Indexes in DynamoDB.