Why is my DynamoDB provisioned table throttled?

Short description

You might experience throttling on your DynamoDB provisioned table in the following scenarios:

• Your DynamoDB table has adequate provisioned capacity, but DynamoDB throttles most of your requests.
• You turned on AWS Application Auto Scaling for DynamoDB, but DynamoDB throttles your table.
• You have a hot partition in your table.
• Your table's traffic exceeds your AWS account throughput quotas.

Resolution

Note: For information about DynamoDB metrics that you can monitor when you experience throttling, see DynamoDB metrics and dimensions.

Your DynamoDB table has adequate provisioned capacity, but DynamoDB throttles most of your requests

DynamoDB reports minute-level metrics to Amazon CloudWatch. CloudWatch calculates the metrics as an average over 1 minute, but DynamoDB applies the rate quotas each second. For example, if you provisioned 60 write capacity units for your DynamoDB table, then you can perform 3,600 writes of 1 KB each in 1 minute. However, if you make all 3,600 requests in 1 second with no additional requests for the rest of the minute, then you might experience throttling. The total number of read capacity units (RCUs) or write capacity units (WCUs) per minute might be lower than the provisioned throughput for the table. Or, your requests might target a few partitions and create a hot partition.

To resolve the inadequate provisioned capacity issue, make sure that your table has enough capacity to serve your traffic. Then, use exponential backoff to retry throttled requests. If you use an AWS SDK, then the AWS SDK implements exponential backoff by default. For more information, see Error retries and exponential backoff.

To resolve a hot partition, see the You have a hot partition in your table section.

Note: DynamoDB doesn't throttle the table after the used capacity per second exceeds the provisioned capacity. DynamoDB uses burst capacity to reserve a portion of the unused capacity for later bursts of throughput to handle usage spikes. For more information, see DynamoDB provisioned capacity mode and How does DynamoDB handle spiky loads in short intervals?

You turned on Application Auto Scaling for DynamoDB, but DynamoDB throttles your table

When two consecutive data points for used capacity units exceed the configured utilization value within 1 minute, Application Auto Scaling scales up. Application Auto Scaling automatically scales the provisioned capacity only when the used capacity is higher than target utilization for 2 consistent minutes.

When 15 consecutive data points in CloudWatch for used capacity are lower than the target utilization, Application Auto Scaling scales down. Application Auto Scaling then invokes the UpdateTable API call. The API call might take a few minutes to update the provisioned capacity for your DynamoDB table or index. Application Auto Scaling requires consecutive data points with higher target utilization values to scale up the provisioned capacity of the DynamoDB table. During this period, Application Auto Scaling throttles requests that exceed the provisioned capacity of the table.

It isn't a best practice to use Application Auto Scaling to manage spikes in DynamoDB workloads. Instead, use on-demand capacity mode. For more information, see Managing throughput capacity automatically with DynamoDB auto scaling.

You have a hot partition in your table

A hot partition occurs when a partition key that doesn't have a high cardinality results in many requests that target only a few partitions. If you exceed the partition quota of 3000 RCU, 1000 WCU, or a linear combination of both per second, then a hot partition might cause throttling. For more information, see Key range throughput exceeded (hot partitions).

To identify the most frequently accessed and throttled items in your table and monitor the graphs for your table's item access patterns, use CloudWatch Contributor Insights.

A hot partition might reduce the performance of your table. To avoid this issue, distribute the read and write operations as evenly as possible across your table. For more information, see Choosing the right DynamoDB partition key.

Also, you can use write sharding on the hot key to increase cardinality so that the hot key can span multiple partitions. Use exponential backoff to retry throttled requests. If you use an AWS SDK, then the AWS SDK implements exponential backoff by default. For more information, see Error retries and exponential backoff.

When you expect high traffic, it's a best practice to increase the provisioned capacity to a higher value. Increased provisioned capacity increases the number of backend partitions.

Note: If you use CloudWatch Contributor Insights for DynamoDB, you incur additional charges. For more information, see CloudWatch Contributor Insights for DynamoDB billing.

Your table's traffic exceeds your account throughput quotas

The table-level read or write throughput quotas apply at the account level in any AWS Region. The quotas apply for tables with both provisioned capacity mode and on-demand capacity mode. By default, your table throughput quota is 40,000 read requests units and 40,000 write requests units. If the traffic to your table exceeds this quota, then DynamoDB might throttle your table.

To resolve this issue, request a table-level read or write throughput quota increase.

Related information

Best practices for designing and using partition keys effectively in DynamoDB

DynamoDB throttling resolution guide