Reserved concurrency is the best circuit breaker in AWS

Lambda scales out to meet demand. That’s the feature. It’s also how a burst of messages turns into a thousand simultaneous connections to a database that was sized for fifty.

The fix isn’t more retries or a bigger database. Lambda already has a dial for this, and most teams only touch it when something is throttled.

Concurrency is a shared pool

Every Lambda function in an account and region draws from one concurrency pool. The default quota is 1,000 concurrent executions per region, and you can request more. If one function suddenly uses most of it, other functions in the same account get throttled, including ones that have nothing to do with the spike.

Reserved concurrency does two things for a function at once:

1. It guarantees that function its share of the pool.
2. It caps that function at that number.

The cap is the part people overlook, and it’s the useful one.

Three ways to use it

Protect the thing behind the function. If a function writes to a database that handles 50 connections comfortably, reserve 40 concurrency. During a spike, extra invocations are throttled instead of piling onto the database. For asynchronous and queue-based invocations, the events wait and retry instead of failing.

For SQS triggers specifically, use the event source’s maximum concurrency setting. It limits how many functions the queue invokes and avoids the throttle-and-retry loop. Messages simply wait in the queue, which is what queues are for.

Isolate the noisy function. A batch job that fans out, or a webhook handler exposed to the internet, shouldn’t be able to starve checkout. Cap the noisy ones. The remaining pool stays available for everything else.

Turn it off, instantly. Setting reserved concurrency to 0 throttles every invocation of that function. No deploy, no code change, no deleted trigger. When a function is causing damage, such as a runaway loop, corrupting writes or hammering a partner API, this is the fastest stop button AWS offers:

aws lambda put-function-concurrency \
  --function-name orders-sync \
  --reserved-concurrent-executions 0

Write it into your runbooks before you need it. Deleting the reservation restores normal scaling.

Agents made this urgent

A growing share of Lambda invocations in 2026 don’t come from users. They come from AI agents calling tools: look up an order, query a table, send a message. An agent stuck in a loop retries a tool hundreds of times a minute without getting bored or embarrassed. Every function exposed as an agent tool should have a reserved concurrency cap sized for what’s behind it, and an alarm when the cap is hit. It’s the cheapest protection you can put between a confused model and your database.

What it is not

• It isn’t provisioned concurrency, which keeps instances warm to avoid cold starts and costs money while idle. Reserved concurrency is free.
• It isn’t a substitute for backpressure in the system you’re protecting. It’s a guardrail at the edge.
• It needs alarms. Alarm on the Throttles metric for every function with a cap, so a guardrail being hit becomes a ticket instead of a mystery.

Pick the number on purpose

For each function, write down what it talks to and what that dependency can handle, then set the cap from that. It takes an afternoon for a whole account. The result is that the busiest day of the year produces a queue and a slower afternoon, not a database outage.