TooManyRequestsException - Too Many Requests

What Does Too Many Requests Mean?

This exception is Lambda's "Air Traffic Control" signal. It triggers when the number of concurrent executions exceeds the allowed quota (default 1,000 per region). Unlike a 504 Timeout, the code never runs, saving you from compute costs but failing the request. It can be caused by account-wide exhaustion (unreserved pool) or reaching a specific function's Reserved Concurrency cap.

Common Causes

• -Account-Level Exhaustion: A single "runaway" Lambda function consumes all 1,000 regional slots, throttling every other function in your account.
• -Reserved Concurrency Ceiling: The function has a hard cap (e.g., 50) that is too low for sudden traffic bursts, even if the account has free capacity.
• -Burst Limit Violations: Scaling up too fast (e.g., from 0 to 3,000 in seconds) exceeds the per-minute burst increase limit of the region.
• -Upstream Over-Fanout: SQS or Kinesis triggers spawning Lambda instances faster than the function is allowed to scale.

How to Fix Too Many Requests

1. 1Increase Regional Quota: Use AWS Service Quotas to request a limit increase if your baseline concurrency is consistently above 80% of the limit.
2. 2Adjust Reserved Concurrency: Ensure critical functions have enough reserved capacity to handle spikes without being throttled by "noisy neighbors."
3. 3Implement Jittered Backoff: Ensure calling services (API Gateway, SDKs) don't retry instantly, which creates a "retry storm" that sustains the throttle.
4. 4Limit SQS Batch Size: Reduce the concurrency of the Event Source Mapping to smooth out the processing rate.

Step-by-Step Diagnosis for Too Many Requests

1. 1Check CloudWatch Metrics: Look for Throttles and ConcurrentExecutions at both the function and account level.
2. 2Verify "UnreservedConcurrentExecutions": If this is near zero, your account is exhausted; find the "noisy neighbor" function.
3. 3Identify Burst Throttling: If ConcurrentExecutions is below the limit but Throttles is high, you are scaling faster than the regional burst limit allows.
4. 4Check Usage Plans: Ensure API Gateway isn't the source of the 429 error before it even reaches Lambda.

// Lambda throttles are transient; retrying with jitter is key
const config = {
  maxAttempts: 5,
  retryStrategy: new ConfiguredRetryStrategy(5, (attempt) => {
    return Math.min(100 * Math.pow(2, attempt) + Math.random() * 50, 5000);
  })
};

import boto3
client = boto3.client('lambda')

# Check if we have reserved concurrency set
response = client.get_function_concurrency(FunctionName='my-function')
print(f"Reserved Concurrency: {response.get('ReservedConcurrentExecutions')}")

How to Verify the Fix

• -Monitor the Throttles metric in CloudWatch; it should return to a steady zero.
• -Verify that the ConcurrentExecutions peaks remain safely below your new Service Quota limits.
• -Test with an upstream load generator to ensure exponential backoff logic is effectively smoothing the traffic.

How to Prevent Recurrence

• -Set CloudWatch Alarms: Trigger alerts when concurrency hits 70% of the regional or reserved limit.
• -Use Provisioned Concurrency: For marketing campaigns or scheduled events where traffic spikes are known in advance.
• -Leaky Bucket Pattern: Use API Gateway Throttling/Usage Plans to reject excess traffic at the edge before it hits Lambda.
• -Pro-tip: Never set Reserved Concurrency to 0 unless you want to "kill-switch" a function during an incident.

Related Errors

Decision Support

Official References

• -AWS Blog: Operating Lambda at Scale
• -Lambda Scaling Limits
• -AWS Lambda Developer Guide — Managing Concurrency
• -AWS Official Documentation