🚨 AWS Error: 'TooManyRequestsException: Rate Exceeded' (Lambda) — Cause, Fix, and Troubleshooting Guide

Overview

Lambda throttles invocations when concurrent executions exceed an available limit. It rejects the call with TooManyRequestsException (HTTP 429) and a Reason such as ConcurrentInvocationLimitExceeded. Because concurrency is a shared, per-account/region pool (default 1,000), one busy function or a low reserved-concurrency setting can starve others.

You will see it from a caller or an SDK:

An error occurred (TooManyRequestsException) when calling the Invoke operation (reached max retries: 2): Rate Exceeded.

The response headers/logs often name the reason:

Reason: ConcurrentInvocationLimitExceeded

It occurs when concurrent executions hit the account limit, a function’s reserved concurrency cap, or the burst ramp-up limit — or when a downstream service applies backpressure.

Symptoms

• Synchronous callers get 429 Rate Exceeded; API Gateway returns 429/502 to clients.
• Asynchronous/event-source invocations are throttled and retried (SQS messages return to the queue, event age climbs).
• CloudWatch shows the function’s Throttles metric > 0.
• Throttling spikes during traffic bursts even though average load is modest.

Common Root Causes

1. Account concurrency limit reached

Total concurrent executions across all functions hit the account/region limit (default 1,000).

2. Reserved concurrency set too low

The function has a reserved-concurrency cap smaller than its demand, throttling it in isolation.

3. Burst concurrency limit during a spike

Concurrency can only ramp so fast; a sudden burst exceeds the instantaneous burst limit before scaling catches up.

4. One function hogging the unreserved pool

Another function without reserved concurrency consumes the shared pool, starving this one.

5. Downstream backpressure

The function is up, but a downstream (DynamoDB, RDS, a throttled API) slows executions so concurrency piles up and trips the limit.

How to diagnose

Step 1: Check the account concurrency limit and headroom

aws lambda get-account-settings \
  --query 'AccountLimit.[ConcurrentExecutions,UnreservedConcurrentExecutions]' --output table

Step 2: Check the function’s reserved concurrency

aws lambda get-function-concurrency --function-name app-handler \
  --query 'ReservedConcurrentExecutions'

A low value here throttles the function regardless of account headroom.

Step 3: Quantify the throttling in CloudWatch

aws cloudwatch get-metric-statistics --namespace AWS/Lambda --metric-name Throttles \
  --dimensions Name=FunctionName,Value=app-handler \
  --start-time "$(date -u -d '30 min ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 60 --statistics Sum --output table

Correlate with ConcurrentExecutions to see whether you hit a per-function or account ceiling.

Fixes

Raise the account concurrency quota

aws service-quotas request-service-quota-increase \
  --service-code lambda \
  --quota-code L-B99A9384 \
  --desired-value 5000

(L-B99A9384 is “Concurrent executions.”)

Reserve concurrency for the critical function

aws lambda put-function-concurrency --function-name app-handler \
  --reserved-concurrent-executions 200

This guarantees capacity and prevents other functions from starving it.

Smooth bursts with provisioned concurrency

aws lambda put-provisioned-concurrency-config --function-name app-handler \
  --qualifier prod --provisioned-concurrent-executions 50

Buffer spikes and add backoff

Put an SQS queue (or Kinesis) in front so bursts are absorbed and drained at a controlled rate, and ensure synchronous callers retry 429s with exponential backoff.

What to watch out for

• Reserving concurrency for one function subtracts from the shared unreserved pool — over-reserving can throttle everything else.
• Async and event-source invokes retry throttles automatically; synchronous callers must implement backoff themselves.
• Burst limits mean a sudden spike throttles even with account headroom — provisioned concurrency pre-warms capacity.
• A throttle can be a downstream symptom: if executions run long because DynamoDB/RDS is slow, fix the backpressure, not just the limit.

Related

• AWS Error: Kinesis ‘ProvisionedThroughputExceededException’ — throttling on a common Lambda event source.
• AWS Error: ‘Throttling: Rate exceeded’ / RequestLimitExceeded — control-plane throttling and adaptive-retry patterns.
• AWS Error: Lambda ‘ResourceConflictException … update is in progress’ — the deploy-time counterpart on the same functions.