DynamoDB returns RequestLimitExceeded when your application exceeds account-level throughput limits, which apply to all tables in your AWS account. This error occurs when the combined throughput across all DynamoDB tables in your account exceeds AWS-imposed limits, requiring quota management and workload distribution strategies.
The RequestLimitExceeded error in DynamoDB indicates that your AWS account has exceeded its overall throughput limits for DynamoDB operations. Unlike table-level throttling (ThrottlingException), this is an account-level limit that applies to the combined throughput across all DynamoDB tables in your account. This error typically occurs in several scenarios: 1. **Account-wide throughput limits**: AWS imposes default throughput limits per account for both provisioned and on-demand capacity modes 2. **Multi-table applications**: When multiple tables in the same account are experiencing high throughput simultaneously 3. **On-demand capacity spikes**: Sudden, unexpected traffic spikes across multiple on-demand tables 4. **Control plane operations**: Excessive administrative operations (CreateTable, UpdateTable, etc.) hitting account limits AWS implements account-level limits to ensure fair resource allocation across all customers and maintain service stability. When these limits are exceeded, DynamoDB returns RequestLimitExceeded with HTTP status code 400.
First, identify your current account limits and request increases if needed:
# Check Service Quotas for DynamoDB
aws service-quotas list-service-quotas \
--service-code dynamodb \
--region us-east-1
# Check specific quota for on-demand tables
aws service-quotas get-service-quota \
--service-code dynamodb \
--quota-code L-4BAB22A6 \
--region us-east-1
# Request quota increase
aws service-quotas request-service-quota-increase \
--service-code dynamodb \
--quota-code L-4BAB22A6 \
--desired-value 10000 \
--region us-east-1Key quotas to check:
- L-4BAB22A6: Maximum on-demand throughput per account
- L-4BAB22A7: Maximum provisioned throughput per account
- L-4BAB22A8: Maximum tables per account
- L-4BAB22A9: Maximum control plane operations per second
Best practices:
- Monitor quota usage in AWS Service Quotas console
- Request increases before reaching 80% of current limits
- Provide business justification for quota increase requests
Add account-aware rate limiting to prevent exceeding account limits:
// Account-level rate limiter
class AccountRateLimiter {
constructor(maxRequestsPerSecond = 1000) {
this.maxRequestsPerSecond = maxRequestsPerSecond;
this.requestCount = 0;
this.windowStart = Date.now();
this.windowSize = 1000; // 1 second in milliseconds
}
async acquire() {
const now = Date.now();
// Reset window if more than 1 second has passed
if (now - this.windowStart > this.windowSize) {
this.requestCount = 0;
this.windowStart = now;
}
// Check if we can proceed
if (this.requestCount >= this.maxRequestsPerSecond) {
const waitTime = this.windowStart + this.windowSize - now;
await new Promise(resolve => setTimeout(resolve, waitTime));
return this.acquire(); // Recursive call after waiting
}
this.requestCount++;
return true;
}
}
// Usage with DynamoDB client
const accountLimiter = new AccountRateLimiter(800); // 800 requests/second
async function makeDynamoDBRequest(operation, params) {
await accountLimiter.acquire();
return await dynamodb[operation](params).promise();
}
// Implement exponential backoff with jitter for account-level errors
const delay = (retryCount) => {
const baseDelay = 100; // 100ms
const maxDelay = 10000; // 10 seconds
const delay = Math.min(maxDelay, baseDelay * Math.pow(2, retryCount));
const jitter = delay * 0.2 * Math.random(); // Add 20% jitter
return delay + jitter;
};Implementation notes:
- Set conservative limits below your actual account quotas
- Use distributed rate limiting for multi-instance applications
- Implement circuit breakers to fail fast during sustained account-level throttling
For high-throughput applications, consider using multiple AWS accounts:
# Create new AWS account using AWS Organizations
aws organizations create-account \
--email "[email protected]" \
--account-name "DynamoDB-App-2" \
--iam-user-access-to-billing ALLOW
# Configure cross-account access
aws sts assume-role \
--role-arn "arn:aws:iam::NEW_ACCOUNT_ID:role/DynamoDBAppRole" \
--role-session-name "CrossAccountSession"
# Set up AWS Resource Access Manager (RAM) for shared resources
aws ram create-resource-share \
--name "DynamoDB-Shared" \
--resource-arns "arn:aws:dynamodb:us-east-1:MAIN_ACCOUNT_ID:table/SharedTable" \
--principals "NEW_ACCOUNT_ID"Workload distribution strategies:
1. Service-based isolation: Different services in different accounts
2. Tenant-based isolation: Different customer segments in different accounts
3. Region-based isolation: Different regions in different accounts for global applications
4. Environment-based isolation: Production, staging, development in separate accounts
AWS Organizations best practices:
- Use Service Control Policies (SCPs) to enforce security boundaries
- Implement AWS Control Tower for multi-account governance
- Set up AWS Budgets for cost monitoring per account
Set up comprehensive monitoring for account-level throughput:
# Create CloudWatch dashboard for account-level metrics
aws cloudwatch put-dashboard \
--dashboard-name "DynamoDB-Account-Metrics" \
--dashboard-body '{
"widgets": [
{
"type": "metric",
"properties": {
"metrics": [
["AWS/DynamoDB", "ThrottledRequests", { "stat": "Sum" }],
["AWS/DynamoDB", "ConsumedReadCapacityUnits", { "stat": "Sum" }],
["AWS/DynamoDB", "ConsumedWriteCapacityUnits", { "stat": "Sum" }]
],
"period": 300,
"stat": "Average",
"region": "us-east-1",
"title": "Account-Level Throughput"
}
}
]
}'
# Set up CloudWatch alarms for account limits
aws cloudwatch put-metric-alarm \
--alarm-name "DynamoDB-Account-Throttling-High" \
--alarm-description "Account-level throttling exceeds threshold" \
--metric-name "ThrottledRequests" \
--namespace "AWS/DynamoDB" \
--statistic "Sum" \
--period 300 \
--threshold 100 \
--comparison-operator "GreaterThanThreshold" \
--evaluation-periods 2 \
--alarm-actions "arn:aws:sns:us-east-1:ACCOUNT_ID:DevOps-Alerts"Key metrics to monitor:
- Account-level: ThrottledRequests, ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits
- Table-level: Provisioned/Consumed capacity for each active table
- Operation-level: SuccessfulRequestLatency, UserErrors, SystemErrors
- Cost: Estimated charges from AWS Cost Explorer
Alerting strategy:
- Set alarms at 70% of account limits
- Implement progressive alerting (Warning → Critical → Emergency)
- Integrate with incident management systems (PagerDuty, OpsGenie)
## Account-Level Throughput Architecture
### AWS Account Limits Structure:
DynamoDB enforces limits at multiple levels:
1. Account-level limits: Apply to all tables in the account
2. Table-level limits: Apply to individual tables
3. Partition-level limits: Apply to individual partitions within tables
### Default Account Limits (varies by region):
- On-demand tables: Typically 40,000 read units and 40,000 write units per account
- Provisioned tables: Varies based on account age and usage history
- Control plane: 500 operations per second per account
- Concurrent operations: Limits on BatchGetItem, BatchWriteItem, Query, and Scan operations
### When to Contact AWS Support:
1. Urgent quota increases for production emergencies
2. Suspected service issues affecting multiple accounts
3. Architecture reviews for high-throughput applications
4. Cost optimization consultations for multi-account setups
5. Performance troubleshooting that crosses account boundaries
### Best Practices Summary:
1. Monitor proactively: Set alarms at 70% of account limits
2. Design for scale: Use multiple accounts for high-throughput applications
3. Implement backpressure: Use rate limiting and queuing
4. Optimize queries: Reduce overall throughput requirements
5. Test at scale: Regularly test account-level limits
6. Document architecture: Maintain clear documentation of multi-account setup
7. Automate management: Use Infrastructure as Code for consistency
8. Review regularly: Quarterly reviews of account limits and usage patterns
ValidationException: The provided key element does not match the schema
How to fix "ValidationException: The provided key element does not match the schema" in DynamoDB
UnrecognizedClientException: The security token included in the request is invalid
How to fix "UnrecognizedClientException: The security token included in the request is invalid" in DynamoDB
TransactionCanceledException: Transaction cancelled
How to fix "TransactionCanceledException: Transaction cancelled" in DynamoDB
TableNotFoundException: Table not found
TableNotFoundException: Table not found in DynamoDB
InternalServerError: Internal Server Error
How to fix "InternalServerError" in DynamoDB