Diagnosing and Fixing DynamoDB ProvisionedThroughputExceededException Throttling

Recognizable Condition

Repeated ProvisionedThroughputExceededException errors appear in application logs and CloudWatch metrics show rising ThrottledRequests for a DynamoDB table.

Cause/Diagnostic Table

Symptom	Likely Cause
Throttling spikes lasting seconds to minutes	Burst capacity exhausted
Throttling concentrated on a few partition keys	Hot partition due to skewed key distribution
Steady increase in throttling despite stable traffic	Auto scaling target utilization too low or scaling cooldown too long
High read throttling with strongly consistent reads	Each strongly consistent read consumes 2 RCUs
Large items (>1 KB) causing more WCUs per write	Item size inflates write capacity consumption

Ordered Checks

1. Verify CloudWatch ThrottledRequests metric for the table (and optionally for specific partition keys via Contributor Insights).
2. Check the ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits metrics to see if they approach provisioned RCU/WCU.
3. If Contributor Insights enabled, look for partition keys with high request rates.
4. Review Auto Scaling policy: target utilization, min/max capacity, and scaling cooldown.
5. Examine item size distribution (e.g., via DynamoDB Export to S3 and a quick Athena query).
6. Confirm whether strongly consistent reads are used excessively.

Fixes Tied to Findings

Burst Capacity Exhausted

• Increase provisioned RCU/WCU to accommodate peak bursts.
• Alternatively, enable on‑demand capacity temporarily to absorb spikes.

Hot Partition (Skewed Partition Key)

• Redesign the partition key to spread load (e.g., add a random suffix, use composite key, or shift to a different attribute).
• Migrate existing data using AWS Data Pipeline, DynamoDB Streams + Lambda, or AWS Glue.
• Test the new key pattern on a staging table before cutover.

Auto Scaling Not Reacting Fast Enough

• Lower the target utilization (e.g., from 70% to 50%) so scaling triggers earlier.
• Reduce the scaling cooldown period or adjust step scaling to add capacity more aggressively.
• Ensure the maximum provisioned capacity is high enough to handle expected peaks.

Large Item Size or Strongly Consistent Reads

• If possible, compress large attributes or store blobs in S3 and keep only references in DynamoDB.
• Replace strongly consistent reads with eventually consistent reads where consistency can be relaxed.
• Consider using transactional reads only when required.

Escalation Criteria

Escalate to the database‑operations team when:

• Throttling persists after applying the above fixes and provisioned capacity is already at the account‑level limit.
• Partition key redesign would require a schema change that impacts multiple services and needs coordinated deployment.
• Cost analysis shows that moving to on‑demand would exceed budget thresholds and no further provisioning adjustments are feasible.

Verification

After each change, monitor the CloudWatch ThrottledRequests metric for at least 5‑10 minutes. A successful fix shows a clear drop to baseline levels (typically < 1% of requests). Validate partition key uniformity by exporting the table to S3 and running a query like:

SELECT partition_key, COUNT(*) AS request_count
FROM dynamodb_export
GROUP BY partition_key
ORDER BY request_count DESC
LIMIT 10;

If the top partition key accounts for less than ~20% of total requests, the distribution is considered acceptable.