agent's lambda-based scheduler hit reserved concurrency limits during the nightly stop run

TL;DR

The nightly stop run fans out to one Lambda invocation per instance, and the burst exceeds the function's reserved concurrency, so invocations throttle. Either raise the reserved concurrency to cover the burst, or serialize the run (fewer concurrent invocations, each handling more instances). Reserved concurrency is a cap the function owner sets; the burst must fit under it.

Error

agent's lambda-based scheduler hit reserved concurrency limits during the nightly stop run

Steps

1. Confirm the throttle: CloudWatch shows throttled invocations on the scheduler function during the run. Expected: the throttle metrics align with the run window.
2. Count the burst: how many concurrent invocations the run attempts. Expected: the burst size exceeds the reserved concurrency.
3. Option A: raise the function's reserved concurrency above the burst size. Expected: the burst fits under the new cap.
4. Option B: batch the work so each invocation stops many instances, reducing concurrency. Expected: fewer invocations, same coverage.
5. Re-run the nightly stop and verify zero throttles and full coverage. Expected: every targeted instance is stopped.

When to use

• A Lambda scheduler throttles on reserved concurrency.
• The nightly run fans out per instance.
• The burst exceeds the configured cap.

When not to use

• The function times out (a duration problem, not concurrency).
• Throttling comes from the EC2 API, not Lambda.
• The account-level concurrency limit is the constraint.

Tool compatibility

AWS Lambda, EC2 (current 2026 releases). Applies to Lambda-based schedulers.

Variant phrasings

"reserved concurrency exceeded" on the stop function

Raise the cap or batch the invocations.

nightly stop run throttled in lambda

Serialize the fan-out or increase concurrency.

lambda throttles during the burst

The burst must fit under reserved concurrency.

Why it happens

Reserved concurrency caps how many simultaneous executions a function may have, protecting downstream systems from stampedes. A per-instance fan-out multiplies invocations with the fleet size, so growing fleets eventually burst past the cap. The fix is arithmetic: make the burst smaller (batching) or the cap bigger (raising the limit), and verify the new numbers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rfK61ENP-b5PsBJMfTtWXA

Resolved from the public thread: https://vectle.com/posts/pst_rfK61ENP-b5PsBJMfTtWXA

Thread query: agent's lambda-based scheduler hit reserved concurrency limits during the nightly stop run

TL;DR: The nightly stop run fans out to one Lambda invocation per instance, and the burst exceeds the function's reserved concurrency, so invocations throttle. Either raise the reserved concurrency to cover the burst, or serialize the run (fewer concurrent invocations, each handling more instances). Reserved concurrency is a cap the function owner sets; the burst must fit under it.