Lambda reserved concurrency as a safety limit

Reserved concurrency sets the maximum number of simultaneous executions for one Lambda function, and also reserves that capacity for it. Setting it deliberately protects downstream systems, keeps one function from consuming the account's capacity, and puts a ceiling on what a flood of requests can cause.

What it does

AWS defines concurrency as the number of in-flight requests a function is handling. Reserved concurrency acts as both a lower and an upper bound: it sets aside that capacity exclusively for the function and also stops the function from scaling beyond it. It costs nothing to configure. Provisioned concurrency is a different feature, which keeps pre-initialized environments ready to cut cold starts, and does cost extra.

You can reserve up to the unreserved account concurrency minus 100, so that other functions keep some capacity. Reserving for one function reduces what the rest of the account shares.

Why this is a security control

Serverless scales to meet demand. That is great for traffic and awkward for attacks and mistakes:

• A public endpoint can be hammered, so cost and downstream load rise with it.
• A bug that makes a function trigger itself can multiply invocations.
• A compromised function that is invoked at scale can do more damage faster.
• A database behind the function may have a connection limit far below what Lambda can reach. AWS notes that upstream and downstream dependencies might not scale like Lambda does, and recommends reserved concurrency to limit how high a function can scale.

A cap turns an unbounded risk into a bounded one.

The emergency stop

AWS documents that setting reserved concurrency to 0 intentionally throttles a function, stopping it from processing any events until you remove the limit. During an incident, that is a quick way to halt a function you suspect is compromised or misbehaving, without deleting it or its configuration.

How to pick a number

Use CloudWatch data. The ConcurrentExecutions metric shows concurrency over time. AWS gives a rough formula: concurrency equals average requests per second multiplied by average request duration in seconds. If the function is critical and you do not want to drop requests, set the value at or above the observed peak. If protecting a downstream system is the goal, set it from that system's limit instead.

Trade-offs

1. Too low a cap throttles real users once traffic reaches it.
2. A cap on one function does not limit the account total. Pair it with budget alerts.
3. It is not authentication. A cap limits volume, not who may call.
4. Reserving capacity reduces what other functions can use. Do not reserve broadly.

A short routine

1. List public facing functions and functions that talk to limited backends.
2. Set a reserved concurrency from observed peaks plus headroom.
3. Alert on throttle metrics, so a cap hit shows up as a signal.
4. Write the zero setting into your incident runbook.

Quick check

Sources

• Configuring reserved concurrency for a Lambda function, AWS documentation

Last reviewed: 19 October 2026.