Diagnosing and Fixing Provisioned‑Capacity Throttling in DynamoDB with Auto Scaling

Problem Statement

High latency or frequent ProvisionedThroughputExceededException errors mean your table is being throttled. In Provisioned Capacity Mode with Auto Scaling, throttling usually points to inadequate provisioned units, stalled scaling, or a hot partition key. The goal of this guide is to help you pinpoint the exact cause and apply the right fix quickly.

Symptoms to Watch

• Latency > 200 ms for read or write operations.
• Application logs contain ProvisionedThroughputExceededException or ThrottlingException.
• CloudWatch metrics show ReadThrottleEvents or WriteThrottleEvents > 0 for a sustained period.
• Auto Scaling target utilization remains > 70 % for > 10 minutes.
• Single partition key receives the majority of traffic (hot partition).

Diagnostic Table

Condition	Likely Cause	Check	Fix
Read/Write latency spikes	Insufficient read/write capacity units (RCU/WCU)	CloudWatch ReadThrottleEvents/WriteThrottleEvents	Increase provisioned units or adjust Auto Scaling target
High ProvisionedThroughputExceededException	Auto Scaling stalled or misconfigured	Auto Scaling policy history in console	Re‑enable Auto Scaling or tweak target utilization
Spikes only on one key value	Hot partition key	Query latency per key via DynamoDB Accelerator (DAX) or CloudWatch Insights	Redesign key, add hash spread, or use a composite key
Overall capacity appears adequate but errors persist	Large item size exceeding RCU/WCU limits	Check average item size via describe-table and CloudWatch	Reduce item size or increase capacity accordingly

Ordered Checks

1. Verify CloudWatch metrics – In the past 5 minutes, confirm ReadThrottleEvents and WriteThrottleEvents are > 0. Use the console or CLI:

   aws cloudwatch get-metric-statistics \
     --namespace AWS/DynamoDB \
     --metric-name ReadThrottleEvents \
     --statistics Sum \
     --period 60 \
     --start-time $(date -u -d '5 minutes ago' +%FT%TZ) \
     --end-time $(date -u +%FT%TZ) \
     --dimensions Name=TableName,Value=YourTableName
   

2. Check Auto Scaling status – In the DynamoDB console, open the Auto Scaling tab for the table. Look at target utilization history and scaling events. If utilization is consistently > 70 % and no scale‑up events occurred, Auto Scaling may be stalled.
3. Identify hot partitions – Run a lightweight query on the suspected key or use Query with ConsistentRead to measure latency per key. If latency spikes for a single key, you likely have a hot partition.
4. Examine item size – Use aws dynamodb describe-table --table-name YourTableName to pull TableSizeBytes and ItemCount. Divide to get average item size. Compare against RCU/WCU limits (1 RCU ≈ 4 KB read, 1 WCU ≈ 1 KB write).

Fixes Tied to Findings

Increase Provisioned Capacity

Adjust RCU/WCU manually or via Auto Scaling target:

# Manual increase
aws dynamodb update-table \
  --table-name YourTableName \
  --provisioned-throughput ReadCapacityUnits=200,WriteCapacityUnits=200

Or change Auto Scaling target to 80 %:

aws application-autoscaling put-scalable-target \
  --service-namespace dynamodb \
  --resource-id table/YourTableName \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --min-capacity 100 \
  --max-capacity 500 \
  --role-arn arn:aws:iam::123456789012:role/AutoScalingRole

Re‑enable or Re‑configure Auto Scaling

If scaling activity is stalled, check the policy in the console. Ensure the CloudWatch alarm that triggers scaling exists and is healthy. Re‑create the alarm if necessary.

Address Hot Partitions

Redesign the partition key or add a hash prefix. For example, if your key is UserID, change to hash(UserID) + UserID or use a composite key UserID#Timestamp. This spreads traffic across partitions.

Reduce Item Size

Strip unused attributes, compress large blobs, or move large data to S3 and store a pointer in DynamoDB. Re‑estimate RCU/WCU after the change.

Escalation Criteria

• After applying all fixes, ReadThrottleEvents/WriteThrottleEvents remain > 0 for > 15 minutes.
• Latency stays > 200 ms despite capacity adjustments.
• Auto Scaling has not scaled up even after a sustained increase in traffic.
• Hot partition persists after key redesign.

In these cases, open an AWS Support case. Provide metric screenshots, scaling logs, and a brief description of the steps already taken.

Verification Checklist

1. CloudWatch shows ReadThrottleEvents and WriteThrottleEvents = 0 for the last 15 minutes.
2. Latency for typical queries drops below 100 ms.
3. Auto Scaling target utilization stabilizes between 40‑60 %.
4. No new scaling events are pending in the console.

Caveats & Limits

• Guide applies only to tables in Provisioned Capacity Mode; On‑Demand tables behave differently.
• Auto Scaling must be enabled for scaling recommendations to work.
• Increasing capacity units can increase costs; review the pricing page.
• Hot partition detection requires detailed metrics; simple CloudWatch metrics may not reveal the hotspot.
• Changing the partition key requires a data migration and may impact existing queries.