RequestLimitExceeded

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 DescribeTable every few seconds across hundreds of tables.
• -Lambda Fan-out: High-concurrency Lambda functions calling DescribeTable on every cold (or even warm) start without in-memory caching.
• -Bulk Backup Bursts: Automated scripts triggering CreateBackup for 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

1. 1Implement Metadata Caching: Cache the results of DescribeTable in a global variable (outside the handler in Lambda) with a TTL (e.g., 5-10 minutes).
2. 2Stagger Maintenance Jobs: Spread out backup or maintenance tasks using a queue with a slight delay between each table.
3. 3Switch to Event-Driven: Instead of polling for table status, use EventBridge or DynamoDB Streams to detect changes.
4. 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

1. 1Check CloudWatch Metrics: Look for ThrottledRequests where the Operation dimension is DescribeTable or ListTables.
2. 2Identify the Caller: Use CloudTrail to see which IAM User or Role is generating the highest volume of Control Plane API calls.
3. 3Analyze Request Spikes: Correlate RequestLimitExceeded events with Lambda scaling events or scheduled CRON jobs.
4. 4Verify the Error Code: Ensure it is RequestLimitExceeded (Account) and not ProvisionedThroughputExceededException (Table).

// 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 ThrottledRequests metric in CloudWatch; it should return to zero after implementing caching.
• -Verify that SuccessfulRequestLatency for 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 DescribeTable in 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.

Related Errors

Decision Support

Official References

• -Optimizing DynamoDB Control Plane Requests
• -AWS SDK Retry Modes
• -AWS DynamoDB Service Quotas & Limits
• -AWS Official Documentation