DynamoDB ProvisionedThroughputExceededException

TL;DR — You're reading/writing faster than the table or index can serve. Switch the table to on-demand capacity, raise provisioned RCU/WCU (or enable auto-scaling), keep the SDK's default exponential-backoff retries, and spread traffic so one partition key isn't hot.

What it means

ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.

On a provisioned-capacity table, you've exceeded the read/write capacity units — either overall, or (more often) on a single partition. It's an HTTP 400 but, unlike a ValidationException, it is retryable: the AWS SDKs retry it automatically with exponential backoff, so occasional ones are normal. Persistent ones mean real under-provisioning or a hot key. The error carries ThrottlingReason fields (e.g. TableReadProvisionedThroughputExceeded) plus the ARN of the affected resource, so you can tell which table or index throttled and on which operation type.

Why it happens

• Under-provisioned capacity for the actual traffic.
• A hot partition — traffic concentrated on one partition key, so a single partition's share of capacity is exhausted while the table looks under-utilized overall.
• Spiky traffic faster than auto scaling can react — it adjusts capacity in response to consumed-capacity metrics, so a sudden step change throttles before the scale-up lands.
• A large scan or bulk import consuming all capacity at once.
• A GSI whose capacity is lower than the write rate — a throttled GSI throttles the base table.

How to fix it

1. Switch to on-demand capacity if traffic is unpredictable — it scales automatically and this error effectively disappears (you pay per request instead).
2. Raise provisioned RCU/WCU or enable auto-scaling with a sane target utilization if you stay on provisioned.
3. Keep exponential-backoff retries — the SDK does this by default; don't disable it. Use adaptive retry mode for bursty workloads.
4. Fix the hot partition — increase key cardinality / write-shard the hot key so load spreads across partitions.
5. Throttle bulk jobs and cache hot reads (DAX or an app cache) to shed read pressure.

FAQ

How do I fix ProvisionedThroughputExceededException? You are reading or writing faster than the table or index can serve. Switch the table to on-demand capacity, raise provisioned RCU/WCU (or enable auto-scaling), keep the SDK default exponential-backoff retries, and spread traffic so a single partition key is not hot.

Reproduce it

Provision a table at 1 RCU, put one item just under 4 KB, then read it back strongly-consistent in a tight loop:

import boto3
ddb = boto3.client('dynamodb', region_name='us-east-1')
# table created with ProvisionedThroughput={'ReadCapacityUnits': 1, 'WriteCapacityUnits': 1}
ddb.put_item(TableName='my-table', Item={'pk': {'S': 'A'}, 'blob': {'S': 'x' * 3500}})
while True:
    ddb.get_item(TableName='my-table', Key={'pk': {'S': 'A'}}, ConsistentRead=True)

Real output:

ProvisionedThroughputExceededException: The level of configured provisioned throughput for the table was exceeded. Consider increasing your provisioning level with the UpdateTable API.
HTTP 400

It took 49 reads to trigger, on a freshly created table with SDK retries disabled. That number is the interesting part: a 1 RCU table does not fail on the second request, because DynamoDB lends you accumulated burst capacity first — so a load test that stops early will report a table as healthy that is not. The other half of the illusion is the SDK, which retries throttled requests for you by default; disable retries as above, or this error stays invisible until it is a latency problem instead.

Related errors

• ThrottlingException — account/control-plane rate limits.
• Throttled despite spare capacity (hot partition) — one partition key soaking up the traffic.
• On-demand throughput exceeded — the on-demand-mode equivalent.
• ItemCollectionSizeLimitExceededException
• Code example: BatchWriteItem in Node.js — the UnprocessedItems retry-with-backoff pattern.
• Learn: On-demand vs provisioned · Hot partitions

References

• Error handling with DynamoDB — Amazon DynamoDB Developer Guide
• Troubleshooting throttling in Amazon DynamoDB — Amazon DynamoDB Developer Guide
• Best practices for designing and using partition keys effectively in DynamoDB — Amazon DynamoDB Developer Guide
• Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide

Last verified 2026-07-13 against the official AWS documentation linked above.

Reproduced 2026-07-26 against the live DynamoDB service in us-east-1 via boto3 1.43.56, on a table provisioned at 1 RCU with SDK retries disabled — the output above is verbatim.