2- Provisioned throughput exceeded
Provisioned capacity throttling occurs when your application's consumption rate exceeds
the read or write capacity units (RCUs/WCUs) configured for your tables or global secondary
indexes. While DynamoDB provides burst capacity to handle occasional traffic spikes, sustained
requests beyond your provisioned limits result in throttling. When this happens, DynamoDB
returns a ProvisionedThroughputExceeded
throttling reason type in the
throttling exception. The reason identifies whether the issue is with read or write
operations and whether it affects the base table or a global secondary index. Throttling can
occur regardless of whether auto scaling is enabled.
Provisioned throughput exceeded mitigation measures
This section provides resolution guidance for provisioned capacity throttling scenarios. Before using this guide, ensure you have identified the specific throttling reason from your application's exception handling, and determined the Amazon Resource Name (ARN) of the affected resource. For information on retrieving throttling reasons and identifying throttled resources, see DynamoDB throttling diagnosis framework.
Select a specific throttling reason below to find recommended mitigation options:
TableReadProvisionedThroughputExceeded
When this occurs
Your application's read consumption rate exceeds the provisioned read capacity units (RCUs) configured for your table. You can monitor the CloudWatch metrics in Common diagnosis and monitoring to analyze your throttling event.
Resolution approach
Choose the appropriate strategy based on your table's Auto Scaling configuration:
-
Consider switching your table to on-demand capacity mode.
-
If Auto Scaling is not enabled:
-
Consider increasing the table read capacity.
-
Enable Auto Scaling for read capacity on your table.
-
-
If Auto Scaling is enabled (default for tables created in the console):
TableWriteProvisionedThroughputExceeded
When this occurs
Your application's write consumption rate exceeds the provisioned write capacity units (WCUs) configured for your table. You can monitor the CloudWatch metrics in Common diagnosis and monitoring to analyze your throttling event.
Resolution approach
Choose the appropriate strategy based on your table's Auto Scaling configuration:
-
Consider switching your table to on-demand capacity mode.
-
If Auto Scaling is not enabled:
-
Consider increasing the table write capacity.
-
Enable Auto Scaling for write capacity on your table.
-
-
If Auto Scaling is enabled (default for tables created in the console):
IndexReadProvisionedThroughputExceeded
When this occurs
Read requests to a Global Secondary Index (GSI) exceed the GSI's provisioned read capacity units (RCUs). You can monitor the CloudWatch metrics in Common diagnosis and monitoring to analyze your throttling event.
Resolution approach
Choose the appropriate strategy based on your GSI's Auto Scaling configuration:
-
Consider switching the base table to on-demand capacity mode.
-
If Auto Scaling is not enabled:
-
Consider increasing the GSI read capacity.
-
Enable Auto Scaling for read capacity on your GSI.
-
-
If Auto Scaling is enabled (default for tables created in the console):
IndexWriteProvisionedThroughputExceeded
When this occurs
Updates to items in the base table trigger writes to a GSI that exceed the GSI's provisioned write capacity. This causes back-pressure throttling on base table writes. You can monitor the CloudWatch metrics in Common diagnosis and monitoring to analyze your throttling event.
Resolution approach
Choose the appropriate strategy based on your GSI's Auto Scaling configuration:
-
Consider switching the base table to on-demand capacity mode.
-
If Auto Scaling is not enabled:
-
Consider increasing the GSI write capacity.
-
Enable Auto Scaling for write capacity on your GSI.
-
-
If Auto Scaling is enabled (default for tables created in the console):
Common diagnosis and monitoring
When troubleshooting throughput errors, several CloudWatch metrics can help identify the root cause.
Essential CloudWatch metrics
Monitor these key metrics to diagnose provisioned capacity throttling:
-
Throttling events:
ReadProvisionedThroughputThrottleEvents
andWriteProvisionedThroughputThrottleEvents
track when requests are throttled.ReadThrottleEvents
andWriteThrottleEvents
track when any read or write requests exceed the provisioned capacity. -
Capacity consumption:
ConsumedReadCapacityUnits
andConsumedWriteCapacityUnits
show actual usage. -
Provisioned capacity:
ProvisionedReadCapacityUnits
andProvisionedWriteCapacityUnits
show configured limits.
Analysis approach
Follow these steps to confirm throttling diagnosis:
-
Compare consumed capacity to provisioned capacity - if consumption consistently approaches or exceeds provisioned limits, this confirms the diagnosis.
-
Review throttling event frequency and timing to identify patterns.
-
Use CloudWatch Contributor Insights to identify which items or partition keys consume the most capacity.
For an overview of how to evaluate if you have right-sized provisioning on your DynamoDB tables, see Evaluate your provisioned capacity for right-sized provisioning in your DynamoDB table.
Resolution procedures
Increasing table throughput capacity
Use this procedure when Auto Scaling is not enabled and you need immediate capacity increase.
-
Update your table's provisioned capacity using the DynamoDB console, Amazon CLI, or SDK:
-
For read capacity: Increase the
ReadCapacityUnits
parameter, which specifies the maximum number of strongly consistent reads consumed per second before DynamoDB throttles requests. -
For write capacity: Increase the
WriteCapacityUnits
parameter, which specifies the maximum number of writes consumed per second before DynamoDB throttles requests.
-
-
Ensure that your table's provisioned throughput capacity remains within the per-account and per-table throughput limit in your Region..
Configuring table Auto Scaling to adjust the read or write capacity of your table or GSI
Configure DynamoDB Auto Scaling to automatically adjust read or write capacity based on traffic patterns. You can configure Auto Scaling independently for both tables and GSIs, with separate controls for read and write capacity units.
-
Enable Auto Scaling for read capacity, write capacity, or both on your table or GSI.
-
Set a target utilization percentage with headroom for traffic spikes.
Note
Lower target utilization increases costs and scaling frequency. Targets below 40% may cause over-provisioning. Monitor usage patterns and costs to balance performance and efficiency.
-
Set capacity boundaries:
-
Minimum RCUs/WCUs: Maintains sufficient capacity during low-traffic periods.
-
Maximum RCUs/WCUs: Accommodates peak traffic demands and protects against runaway scaling events.
-
For predictable traffic patterns and planned events, Application Auto Scaling supports scheduled scaling actions for DynamoDB tables. These scheduled actions allow you to adjust the read or write capacity of your tables at predetermined times using cron expressions.
For guidance on configuring and managing DynamoDB Auto Scaling, see Managing throughput capacity automatically with DynamoDB Auto Scaling.
Note
Be aware that Auto Scaling has some latency and may not react quickly enough to sudden traffic spikes, which is why proper target utilization settings with adequate headroom are important.
Optimizing your table's or index's read or write Auto Scaling settings
Use this procedure when Auto Scaling is enabled but throttling still occurs. You can tune auto-scaling independently for both tables and global secondary indexes (GSIs), with separate controls for read and write capacity units.
-
Adjust target utilization: Consider lowering the target utilization for your table or GSIs to trigger scaling earlier before throttling occurs. Ensure that you monitor your traffic after making these adjustments. See Configuring table Auto Scaling to adjust the read or write capacity of your table or GSI for more information about capacity consumption and cost implications.
-
Review capacity boundaries: Ensure your minimum and maximum capacity settings align with your actual workload patterns.
-
Modify scaling policies: Modify your scaling policies to be more aggressive for workloads with rapid changes in demand.
Switching to on-demand capacity mode
For general information about switching capacity modes, see Considerations when switching capacity modes in DynamoDB. Refer to the Service Quotas to learn about specific constraints when switching mode.
Increasing GSI throughput capacity
Use this procedure when Auto Scaling is not enabled on your GSI or you need immediate capacity increase.
-
Update the GSI's provisioned capacity using the DynamoDB console, Amazon CLI, or SDK:
-
For read capacity: Increase the
ReadCapacityUnits
parameter for the specific GSI, which specifies the maximum number of reads the GSI can consume per second before DynamoDB throttles requests. Note that GSIs only support eventually consistent reads. -
For write capacity: Increase the
WriteCapacityUnits
parameter for the specific GSI, which specifies the maximum number of writes the GSI can consume per second before DynamoDB throttles requests.
-
-
Ensure that the GSI's provisioned throughput capacity remains within the per-account and per-table throughput quotas.
Additional resources
-
For detailed information about handling traffic spikes in DynamoDB provisioned capacity tables, including various strategies from utilizing auto scaling and burst capacity to strategic throttle management, see Handle traffic spikes with Amazon DynamoDB provisioned capacity
. -
For detailed strategies on optimizing Auto Scaling configurations and performance tuning, see DynamoDB Auto Scaling: Performance and cost optimization at any scale
. -
For information about how to use a cron expression to schedule a scaling policy, see Optimize costs by scheduling provisioned capacity for DynamoDB
. -
For hands-on information about monitoring and analyzing throughput utilization patterns for your DynamoDB tables in provisioned capacity mode, see How to evaluate throughput utilization for Amazon DynamoDB tables in provisioned mode
.