Lambda Concurrency
18 min
By default, every Lambda function in an AWS account shares one account-wide concurrency limit — a traffic spike on one function can starve every other function of capacity. Reserved concurrency carves out (and caps) a slice of that pool for one specific function: it's GUARANTEED that capacity even if everything else is maxed out, but it also can never scale beyond that reserved number, no matter how much headroom the rest of the account has.
def should_throttle(current_concurrent_executions, reserved_concurrency, account_limit):
limit = reserved_concurrency if reserved_concurrency is not None else account_limit
return current_concurrent_executions >= limit
The third example is the real point of this feature: a function reserved at exactly 3 throttles at 3 executions EVEN THOUGH the account limit is 1000 -- reservation caps a function's ceiling independently of how much room exists elsewhere in the account.
Write `should_throttle(current_concurrent_executions, reserved_concurrency, account_limit)`: if `reserved_concurrency` is set (not `None`), a function can never exceed IT specifically, regardless of the account-wide limit. If it's `None`, the function shares the account-wide `account_limit` instead. Return `True` if `current_concurrent_executions` has already reached whichever limit applies.
Why would you set RESERVED concurrency on a specific Lambda function, given it's usually a smaller number than the shared account-wide limit?
You can determine whether a Lambda invocation would be throttled under reserved vs. shared account-wide concurrency, and understand the guarantee/cap tradeoff reservation makes.