RequestLimitExceeded
AWS RequestLimitExceeded is an account-level throttling error indicating that the total number of concurrent DynamoDB API calls (Control Plane) has reached the regional quota. It affects management operations across all tables in an account.
Last reviewed: March 21, 2026|Editorial standard: source-backed technical guidance
What Does Request Limit Exceeded Mean?
RequestLimitExceeded is a "global brake" for your AWS account. Unlike ProvisionedThroughputExceeded (which is about read/write units on a specific table), this error hits the "Control Plane" - operations that manage tables rather than the data inside them. If you call DescribeTable or ListTables too frequently across multiple services, AWS throttles the entire account to protect the regional management service.
Common Causes
- -Aggressive Polling: Health checks or monitoring tools calling
DescribeTableevery few seconds across hundreds of tables. - -Lambda Fan-out: High-concurrency Lambda functions calling
DescribeTableon every cold (or even warm) start without in-memory caching. - -Bulk Backup Bursts: Automated scripts triggering
CreateBackupfor all tables in a region at the exact same second. - -Infrastructure-as-Code (IaC) Storms: Massive CI/CD pipelines deploying and verifying dozens of DynamoDB stacks simultaneously.
How to Fix Request Limit Exceeded
- 1Implement Metadata Caching: Cache the results of
DescribeTablein a global variable (outside the handler in Lambda) with a TTL (e.g., 5-10 minutes). - 2Stagger Maintenance Jobs: Spread out backup or maintenance tasks using a queue with a slight delay between each table.
- 3Switch to Event-Driven: Instead of polling for table status, use EventBridge or DynamoDB Streams to detect changes.
- 4Use Standard Retry Mode: Ensure your AWS SDK is using "standard" or "adaptive" retry modes which handle 503/RequestLimitExceeded automatically with jitter.
Step-by-Step Diagnosis for Request Limit Exceeded
- 1Check CloudWatch Metrics: Look for
ThrottledRequestswhere theOperationdimension isDescribeTableorListTables. - 2Identify the Caller: Use CloudTrail to see which IAM User or Role is generating the highest volume of Control Plane API calls.
- 3Analyze Request Spikes: Correlate
RequestLimitExceededevents with Lambda scaling events or scheduled CRON jobs. - 4Verify the Error Code: Ensure it is
RequestLimitExceeded(Account) and notProvisionedThroughputExceededException(Table).
Control Plane vs. Data Plane Metrics
- -Control Plane (Account Limit):
DescribeTable,UpdateTable,ListTables,CreateBackup. (Threshold: Hard Account Quota). - -Data Plane (Table Limit):
GetItem,PutItem,Query,Scan. (Threshold: WCU/RCU Capacity).
Lambda Warm-Start Caching Strategy
- -Inefficient: Calling
DescribeTableinside the function handler (1 call per invocation). - -Optimized: Calling
DescribeTableoutside the handler and storing in a globalMap(1 call per container lifetime).
Implementation Examples
// Define cache OUTSIDE the handler
const metadataCache = new Map();
export const handler = async (event) => {
const tableName = "Orders";
let metadata = metadataCache.get(tableName);
if (!metadata || (Date.now() - metadata.ts > 300000)) {
const data = await ddbClient.send(new DescribeTableCommand({ TableName: tableName }));
metadata = { data: data.Table, ts: Date.now() };
metadataCache.set(tableName, metadata);
}
return metadata.data;
};aws cloudwatch get-metric-statistics \
--namespace AWS/DynamoDB \
--metric-name ThrottledRequests \
--dimensions Name=Operation,Value=DescribeTable \
--statistics Sum --period 60 --start-time `date -u -v-1H +%FT%TZ` --end-time `date -u +%FT%TZ`How to Verify the Fix
- -Monitor the
ThrottledRequestsmetric in CloudWatch; it should return to zero after implementing caching. - -Verify that
SuccessfulRequestLatencyfor management operations stays stable during peak load. - -Confirm that automated backup jobs no longer fail with "Rate Exceeded" messages.
How to Prevent Recurrence
- -Aggressive Caching: Treat table metadata as static data. Only fetch it once at startup or on a long TTL.
- -Service Quotas: If your architecture legitimately needs high control plane volume, request an increase via AWS Service Quotas.
- -Centralized Config: Store table schemas in SSM Parameter Store or environment variables to avoid runtime calls to
DescribeTable. - -Pro-tip: Never call
DescribeTablein a loop. If you need to check if a table is ready, use the AWS SDK "Waiter" functionality which has built-in efficient polling logic.
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.