A Lambda function is throttled during a sale. The account is well under its regional concurrency quota. This function's reserved concurrency is set to 10, and the sale is driving far more concurrent executions than that. What should change?
Select an answer to reveal the explanation.
Short Explanation
Reserved concurrency is both a reservation and a ceiling. You set the ceiling at 10, and the sale is taller than the ceiling. You raise it or take the cap off, and a NAT gateway does not add Lambda concurrency.
Full Explanation
Reserved concurrency limits how many executions of that function may run at once, even when the account has unused concurrency. A setting of 10 throttles the 11th concurrent call. Raising it, or removing the reservation if you do not need a cap, matches the sale. A NAT gateway and S3 versioning do not change this limit. Lowering it to 1 throttles sooner. Caveat: unreserved account concurrency must still be able to absorb the new number, and a function with reserved concurrency cannot use the unreserved pool above its own cap. Operational check: the function's throttle metric should fall after the cap is raised, and concurrent executions should be allowed to pass the old value of 10. Reserved concurrency of 10 means the function will not run an 11th execution even if the account has thousands free. Throttles show up as 429s to callers and as the Throttles metric. Raising the reservation, or setting it to none, lets the function use the account pool up to the new cap. Do not burn the account's unreserved floor by reserving every function at a high number without a reason.