How to fix ProvisionedThroughputExceededException: The level of configured provisioned throughput for the table was exceeded in DynamoDB

DynamoDBINTERMEDIATEHIGHUpdated Dec 29, 2025· 130 views

This error occurs when your application's request rate exceeds the read or write capacity units (RCU/WCU) provisioned for your DynamoDB table. DynamoDB will reject excess requests with throttling, causing failures in your application.

Quick fix

Fixes ProvisionedThroughputExceededException

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";

const client = new DynamoDBClient({
  region: "us-east-1",
  // Exponential backoff is enabled by default
  maxAttempts: 3, // Retry up to 3 times
});
  1. Implement exponential backoff and retry logic
  2. Increase provisioned capacity
  3. Switch to on-demand capacity mode
  4. Enable DynamoDB auto scaling
dynamodb — error
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
const client = new DynamoDBClient({
  region: "us-east-1",
  // Exponential backoff is enabled by default
  maxAttempts: 3, // Retry up to 3 times
});
ProvisionedThroughputExceededException: The level of configured provisioned throughput for the table was exceeded

What this error means

The "ProvisionedThroughputExceededException" error means your DynamoDB table or global secondary index (GSI) has received more requests than the provisioned capacity can handle. DynamoDB enforces strict rate limits based on your configured Read Capacity Units (RCU) and Write Capacity Units (WCU). When you exceed these limits, DynamoDB rejects requests to prevent overload and maintain performance for all users. This is different from exceeding soft limits—it's a hard rejection that requires immediate attention. The error occurs at the partition level: each partition in your table can handle up to 1000 WCU or 3000 RCU per second. If a "hot partition" receives too many requests, it can be throttled even if your table has sufficient overall capacity.

Typical symptoms

  • Application receives 'ProvisionedThroughputExceededException' errors when executing read or write operations
  • Errors occur sporadically or under specific load conditions
  • CloudWatch metrics show request rate spiking above provisioned capacity
  • Batch operations fail with some items unprocessed
  • API latency increases significantly when errors occur
  • Application can't scale to meet demand without changing capacity

Common causes

  1. Application sends requests faster than provisioned capacity allows
  2. Sudden spike in traffic or load test exceeds baseline capacity
  3. Hot partition: specific partition keys receive disproportionate traffic
  4. Inefficient query patterns using full table scans instead of targeted queries
  5. Burst capacity exhausted: temporary spikes exceeded the burst buffer
  6. Provisioned capacity too low for production workload
  7. Global Secondary Index (GSI) has separate capacity from main table

How to fix "ProvisionedThroughputExceededException: The level of configured provisioned throughput for the table was exceeded"

1Implement exponential backoff and retry logic

DynamoDB requests that hit throttling should be retried with progressive delays. AWS SDKs handle this automatically, but verify your client configuration:

For AWS SDK v3 (JavaScript/Node.js):

javascript
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";

const client = new DynamoDBClient({
  region: "us-east-1",
  // Exponential backoff is enabled by default
  maxAttempts: 3, // Retry up to 3 times
});

For Python (boto3):

python
import boto3
from botocore.config import Config

config = Config(
    retries = {
        'max_attempts': 3,
        'mode': 'adaptive'  # Uses exponential backoff
    }
)
dynamodb = boto3.client('dynamodb', config=config)

For Java:

java
AmazonDynamoDB client = AmazonDynamoDBClientBuilder
    .standard()
    .withRegion(Regions.US_EAST_1)
    .build();
// Automatic retries are built-in
2Increase provisioned capacity

If you're consistently hitting limits, increase your provisioned capacity via the AWS Console or CLI:

Using AWS CLI:

bash
aws dynamodb update-table \
  --table-name YourTableName \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=200,WriteCapacityUnits=200

Using AWS Console:
1. Open DynamoDB → Tables → Select your table
2. Go to "Capacity" tab
3. Change "Provisioned capacity" values
4. Click "Save changes"

Note: Capacity increases take a few seconds to apply. Decreases can only happen every 4 hours.

3Switch to on-demand capacity mode

On-demand mode scales automatically based on traffic, eliminating throttling at the cost of variable pricing:

Using AWS CLI:

bash
aws dynamodb update-billing-mode \
  --table-name YourTableName \
  --billing-mode PAY_PER_REQUEST

Using AWS Console:
1. Open DynamoDB → Tables → Select your table
2. Go to "Billing settings"
3. Select "On-demand" mode
4. Confirm the change

Best for: Unpredictable workloads, spike handling, or during testing. Costs more per request but no capacity planning needed.

4Enable DynamoDB auto scaling

Auto Scaling automatically adjusts capacity based on CloudWatch metrics:

Using AWS CLI:

bash
# Enable auto scaling for read capacity
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id table/YourTableName \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --min-capacity 5 \
  --max-capacity 200

# Create scaling policy
aws application-autoscaling put-scaling-policy \
  --service-namespace dynamodb \
  --scalable-dimension dynamodb:table:ReadCapacityUnits \
  --resource-id table/YourTableName \
  --policy-name MyTableReadScaling \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration TargetValue=70,PredefinedMetricSpecification={PredefinedMetricType=DynamoDBReadCapacityUtilization}

Using AWS Console:
1. Open DynamoDB → Tables → Select your table
2. Go to "Capacity" tab
3. Enable "Autoscaling"
4. Set minimum and maximum capacity
5. Set target utilization (70% is typical)

5Identify and fix hot partitions

Use CloudWatch Contributor Insights to find which partition keys are causing throttling:

1. Open CloudWatch → Logs → Contributor Insights
2. Create a rule for your DynamoDB table
3. View "LeadingKeys" to see most-accessed partition keys

For example, if user_id=123 receives 80% of traffic while others get 20%, that's a hot partition.

Solutions:
- Add randomness to partition keys (sharding): user_id#123#shard_1, user_id#123#shard_2
- Distribute traffic across multiple items: Use sort keys or secondary keys
- Cache frequently accessed items in ElastiCache or DAX

Example with sharding:

javascript
// Instead of: partition key = "user_123"
// Use: partition key = "user_123#shard_" + Math.floor(Math.random() * 10)

const userId = "user_123";
const shardId = Math.floor(Math.random() * 10);
const partitionKey = `${userId}#shard_${shardId}`;
6Optimize query patterns

Inefficient queries can cause throttling. Optimize your access patterns:

Bad: Full table scan (expensive)

javascript
const params = {
  TableName: "Users",
  FilterExpression: "age > :age",
  ExpressionAttributeValues: { ":age": { N: "25" } },
};
// Scans all items, very inefficient

Good: Query with GSI if available

javascript
const params = {
  TableName: "Users",
  IndexName: "AgeIndex", // Global Secondary Index
  KeyConditionExpression: "age > :age",
  ExpressionAttributeValues: { ":age": { N: "25" } },
};
// Only reads relevant items

Best practices:
- Use Query instead of Scan when possible
- Create indexes for commonly filtered attributes
- Use projection expressions to fetch only needed columns
- Batch operations to combine multiple requests

7Check GSI capacity separately

Global Secondary Indexes (GSIs) have their own provisioned capacity, separate from the base table:

Verify GSI capacity:

bash
aws dynamodb describe-table --table-name YourTableName | grep -A 10 GlobalSecondaryIndexes

Update GSI capacity:

bash
aws dynamodb update-table \
  --table-name YourTableName \
  --global-secondary-index-updates \
  "[{\"Update\": {\"IndexName\": \"YourGSI\", \"ProvisionedThroughputUpdate\": {\"ReadCapacityUnits\": 100}}}]"

GSI throttling appears as the same error but affects queries on that index only.

Advanced notes

Burst Capacity: DynamoDB provides burst capacity for temporary spikes. You can accumulate unused capacity as "burst capacity" which allows brief overages without throttling. However, burst capacity is limited and exhausts quickly under sustained load.

Partition Management: DynamoDB automatically splits partitions when they exceed capacity, but this takes time. During the split, throttling can still occur. If you know you'll need high capacity, request a quota increase in advance.

Cost Considerations:
- Provisioned: Cheaper for predictable, steady workloads. Pay per RCU/WCU per hour.
- On-demand: More expensive per request but scales automatically. Good for variable traffic.
- Auto Scaling: Middle ground, but doesn't respond instantly to sudden spikes.

Monitoring: Set up CloudWatch alarms for:
- ConsumedReadCapacityUnits > 80% of provisioned
- ConsumedWriteCapacityUnits > 80% of provisioned
- UserErrors (throttling exceptions) > 0

Regional Quotas: Default per-region quotas are 40,000 RCU and 40,000 WCU. Request increases via AWS Support if needed.

Frequently asked questions

What does "ProvisionedThroughputExceededException" mean?
The "ProvisionedThroughputExceededException" error means your DynamoDB table or global secondary index (GSI) has received more requests than the provisioned capacity can handle. DynamoDB enforces strict rate limits based on your configured Read Capacity Units (RCU) and Write Capacity Units (WCU). When you exceed these limits, DynamoDB rejects requests to prevent overload and maintain performance for all users.
How do I fix "ProvisionedThroughputExceededException"?
This error occurs when your application's request rate exceeds the read or write capacity units (RCU/WCU) provisioned for your DynamoDB table. DynamoDB will reject excess requests with throttling, causing failures in your application.
What causes "ProvisionedThroughputExceededException"?
Application sends requests faster than provisioned capacity allows Sudden spike in traffic or load test exceeds baseline capacity Hot partition: specific partition keys receive disproportionate traffic
Is the "ProvisionedThroughputExceededException" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading