Lambda functions reserving more than 100 concurrent executions while peaking under half of it

Reserved concurrency is free but not harmless

Reserved concurrency sets both the maximum and the minimum number of concurrent instances for a function, and no other function can use what it reserves. AWS states that configuring it incurs no additional charges. Provisioned concurrency, the pre-warmed kind, does cost money; reserved does not.

What it costs is room. Lambda gives an account 1,000 concurrent executions per Region by default, and you can reserve up to the unreserved total minus 100, which is always left for functions without a reservation. A function reserving 500 and never going above 60 has taken 440 executions away from everything else; during a traffic spike, those other functions throttle.

Checking reservations against peaks

aws lambda get-function-concurrency --function-name my-fn

aws cloudwatch get-metric-statistics --namespace AWS/Lambda \
  --metric-name ConcurrentExecutions --dimensions Name=FunctionName,Value=my-fn \
  --statistics Maximum --period 3600 \
  --start-time 2026-08-26T00:00:00Z --end-time 2026-09-25T00:00:00Z

AWS recommends reading ConcurrentExecutions with the maximum statistic. It has one-minute granularity.

The over-reservation test

1. The function’s reserved concurrency, read from its configuration, is above 100.
2. ZopNight has at least 7 days of true hourly peaks for ConcurrentExecutions in the 30-day window.
3. The highest peak is under half the reservation.
4. The function has a known monthly cost.

Why no dollar finding is ever shown

All four checks run, but the result is never a cost recommendation. Lowering a reservation changes no line on the bill, and a recommendation that claims a saving would be wrong. So the rule does not produce one, permanently, rather than invent a figure. Use the checks above as an operational review instead; they identify functions hoarding account capacity.

What lowering the reservation buys

saving = $0 on the bill
capacity returned to the account pool = reserved concurrency - (peak x 2)

Keeping the reservation at twice the observed peak leaves room for growth while returning the rest.

Right-sizing a reservation

1. Confirm why the reservation exists: to guarantee capacity, or to cap a function that overloads a downstream database. A cap may be deliberate.
2. Set it closer to twice the observed peak: aws lambda put-function-concurrency --function-name my-fn --reserved-concurrent-executions 120
3. Or remove it if the function does not need a guarantee: aws lambda delete-function-concurrency --function-name my-fn
4. Watch the function’s Throttles metric for the following week.