Diagnosing DynamoDB Provisioned Throughput Throttling

The symptom: ThrottlingException under provisioned capacity

Your application starts returning HTTP 400 errors with ThrottlingException, and request latency climbs even though the table appears healthy in the console. In provisioned capacity mode, DynamoDB rejects reads and writes when a table or secondary index exceeds its configured read capacity units (RCUs) or write capacity units (WCUs) per second. The first useful step is to confirm whether the throttle is table-wide or confined to a single partition.

Common causes and diagnostic signals

Provisioned throttling usually stems from one of four conditions. The table below maps each cause to the signal you should look for.

Condition	Likely cause	Diagnostic signal
Throttling during steady traffic	Provisioned capacity too low for the workload	ConsumedReadCapacityUnits or ConsumedWriteCapacityUnits persistently near ProvisionedReadCapacityUnits / ProvisionedWriteCapacityUnits
Throttling only during traffic spikes	Hot partition or bursty access pattern	One partition’s read/write utilization far above the table average
Throttling persists after scaling actions	Auto Scaling policy lag or misconfiguration	Scaling history shows delayed or missed adjustments relative to metric changes
Errors in logs but CloudWatch metrics look normal	Burst capacity masking short spikes	1-minute metrics appear healthy, yet ThrottlingException counts are non-zero in logs or X–Ray

Ordered diagnostic checks

1. Compare consumed and provisioned capacity

Run the following from the AWS CLI or CloudShell. You need cloudwatch:GetMetricStatistics permission. Replace <table-name>, <start-time>, and <end-time> with your values.

aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name ConsumedReadCapacityUnits \
  --dimensions Name=TableName,Value=<table-name> \
  --start-time <start-time> \
  --end-time <end-time> \
  --period 300 \
  --statistics Average Sum

Check whether the returned datapoints approach the table’s ProvisionedReadCapacityUnits. For example, if consumed reads average 850 units over 5–minute periods while provisioned reads are 1,000 units, the table is at 85% utilization; any burst above the remaining 150 units will trigger throttling. Repeat for ConsumedWriteCapacityUnits and each global secondary index.

2. Correlate throttling events with traces and logs

Search CloudWatch Logs or AWS X–Ray for ThrottlingException entries. Confirm that the timestamps align with the metric spikes identified above. If errors appear without corresponding metric pressure, suspect burst absorption hiding short spikes from coarse–grained CloudWatch aggregation.

3. Detect hot partitions

In the DynamoDB console, open the table’s Metrics tab and select View partition–level data if the feature is enabled. Alternatively, enable Contributor Insights for the table to surface the most frequently accessed partition keys. A single partition consuming a disproportionate share of RCUs or WCUs indicates a hot partition rather than a global capacity deficit.

4. Confirm capacity mode and scaling configuration

Run the following from the AWS CLI. You need dynamodb:DescribeTable permission.

aws dynamodb describe-table --table-name <table-name>

Inspect BillingModeSummary. If the mode is PAY_PER_REQUEST, provisioned throttling does not apply and you should investigate other limits. If the mode is PROVISIONED, note the current throughput settings. If Application Auto Scaling manages capacity, review the scaling policies and recent scaling activities in the CloudWatch console to see whether adjustments kept pace with demand.

Fixes matched to findings

Hot partition

If a single partition key is receiving disproportionate traffic, increasing table–wide capacity will not eliminate throttling. Redistribute the workload by adding a random suffix or computed shard to high–traffic keys, or revise the access pattern to spread reads and writes across the key space. Caching frequently read items in Amazon ElastiCache or DAX can also reduce read pressure on the hot partition.

Sustained capacity shortfall

When consumed capacity consistently approaches the provisioned limit, raise the ceiling. Run the following from the AWS CLI. You need dynamodb:UpdateTable permission. Replace <new-rcu> and <new-wcu> with your target values.

aws dynamodb update-table \
  --table-name <table-name> \
  --provisioned-throughput ReadCapacityUnits=<new-rcu>,WriteCapacityUnits=<new-wcu>

Risk: This change increases your DynamoDB bill immediately. Rollback: Re–run the command with the previous ReadCapacityUnits and WriteCapacityUnits values.

Auto Scaling lag

If scaling policies exist but react too slowly, lower the target utilization percentage so scale–out triggers earlier, or increase the minimum provisioned capacity to cover baseline demand. Verify that the scaling policy’s cooldown periods do not prevent successive scale–out events during sustained growth.

Escalation and redesign criteria

Escalate to a schema review or AWS Support when throttling continues after capacity increases, when a hot partition cannot be resolved without changing the partition key, or when you suspect a service–side issue outside your control. A partition–key redesign is often the only durable fix for chronically skewed workloads.

Limitations and verification

DynamoDB retains a pool of burst capacity that absorbs short spikes above provisioned throughput. Because of this, alarms based on 1–minute metrics can miss throttling events. Monitor over intervals of at least 5 minutes, and preferably 15–30 minutes, before concluding that capacity is sufficient. If you switch to on–demand mode to avoid provisioned limits, validate that the resulting cost profile is acceptable for your traffic.

After applying any fix, verify the result by re–checking CloudWatch for a window longer than the burst period and confirming that ThrottlingException counts in logs or X–Ray drop to zero. If consumed capacity still tracks within 10% of provisioned limits during peak periods, treat the table as capacity–constrained and plan the next adjustment.