ProvisionedThroughputExceededException
AWS ProvisionedThroughputExceededException means the request exceeded provisioned throughput for a DynamoDB table or index, so DynamoDB throttled the request (HTTP 400).
Last reviewed: March 21, 2026|Editorial standard: source-backed technical guidance
What Does Provisioned Throughput Exceeded Exception Mean?
DynamoDB throttled the request because provisioned capacity was exceeded on table or index partitions, so clients must retry with backoff while addressing hot-key and capacity pressure.
Common Causes
- -Read/write demand exceeds table or GSI provisioned capacity.
- -Hot partition keys concentrate traffic on a small subset of partitions.
- -Retry behavior without jitter amplifies throttling pressure.
- -Autoscaling settings lag behind sudden traffic spikes.
How to Fix Provisioned Throughput Exceeded Exception
- 1Apply exponential backoff with jitter and cap retry fan-out.
- 2Increase table/index capacity or enable/tune autoscaling where appropriate.
- 3Distribute traffic by improving partition key cardinality.
- 4Batch and smooth high-volume access patterns to reduce burst contention.
Step-by-Step Diagnosis for Provisioned Throughput Exceeded Exception
- 1Inspect CloudWatch metrics: ThrottledRequests, ConsumedRead/WriteCapacityUnits, and per-index pressure.
- 2Identify hot keys/partitions using access logs and key-distribution analysis.
- 3Trace retry amplification in clients, streams, and async workers.
- 4Correlate throttling windows with deploys, batch jobs, or traffic shifts.
DynamoDB Throughput Budget Review
- -Profile hot partitions and per-key request concentration (example: one partition key consumes a disproportionate write budget).
- -Trace retry fan-out and adaptive throttling controls (example: immediate retries saturate provisioned throughput repeatedly).
Capacity Mode and Auto Scaling Checks
- -Inspect table and GSI capacity mode plus target tracking behavior (example: autoscaling max write units capped below recurring peak demand).
- -Audit batch worker concurrency against partition heat, not just table totals (example: queue consumers scale out and hammer one key range).
How to Verify the Fix
- -Confirm throttled request metrics decline after capacity and key-distribution changes.
- -Validate latency and success rate stabilize under representative load.
- -Re-run load tests to confirm hot partition risk is reduced.
How to Prevent Recurrence
- -Design partition keys for even traffic distribution from the start.
- -Continuously monitor DynamoDB throttling and autoscaling behavior by table and index.
- -Load-test with realistic key distribution and retry strategies before major launches.
Pro Tip
- -enable ReturnConsumedCapacity and ReturnItemCollectionMetrics in diagnostic runs to pinpoint whether the bottleneck is throughput, schema, or partition growth.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
AWS ThrottlingException vs GCP RESOURCE_EXHAUSTED
Compare AWS ThrottlingException and GCP RESOURCE_EXHAUSTED to separate rate limiting from quota/resource exhaustion and choose the remediation path.
Playbook
Rate Limit Recovery Playbook (429 / ThrottlingException / RESOURCE_EXHAUSTED)
Use this playbook to separate transient throttling from hard quota exhaustion and apply retry, traffic-shaping, and quota-capacity fixes safely.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.