AWS Lambda "TooManyRequestsException" or a silent DLQ? Two throttles, two fixes

A Lambda 429 TooManyRequestsException looks like one problem. It's two — with opposite fixes. And the async version doesn't even return an error: it returns 202 Accepted and then silently drops your event.

Two throttles, two fixes

• Rate throttle: invocations arrive faster than Lambda's scale rate (1000 instances / 10s, or the 10,000 req/s burst) — even when you're below the concurrency ceiling. Fix: smooth the arrival (put SQS/a queue in front, or use provisioned concurrency to pre-warm).
• Ceiling throttle: you hit the function's reserved-concurrency limit, or exhausted the account's unreserved pool (default 1000/region). Fix: raise reserved concurrency (PutFunctionConcurrency) or request an account limit increase.

The silent one: async throttling

This is the dangerous case. An async (event) invocation that's throttled returns NO 429 to the caller — the invoke returns 202 Accepted. Lambda retries the event twice (up to MaximumEventAge, ~6h), then drops it to the DLQ / OnFailure destination. From your side it 'succeeded.' The Lambda function itself didn't fail — the log shows a success. [tag: false-success]

1. Don't trust the 202 — configure a DLQ / OnFailure destination and ALARM on it plus the Throttles metric (your only signal).
2. Fix the underlying throttle (raise reserved concurrency / smooth arrival).
3. Make the handler IDEMPOTENT — the twice-retry can double-process.

Snapback's serverless family diagnoses both — diagnose_infra_error tells you which throttle you hit and that an async failure is in the metrics, not the response.