A sudden open-enrollment spike exhausts account concurrency and starves an unrelated payroll Lambda in the same account. How should critical capacity be protected?
Select an answer to reveal the explanation.
Short Explanation
Reserve a quiet lane for payroll so the open-enrollment parade can't block the city's paychecks. Reserved concurrency fences critical functions (and can cap noisy ones). Deleting payroll, sharing one uncapped pool, or tweaking timeout won't protect account concurrency.
Full Explanation
When a sudden open-enrollment spike exhausts account concurrency and starves an unrelated payroll Lambda in the same account, protect critical capacity by setting reserved concurrency on the payroll function (and optionally limiting the noisy neighbor). Reserved concurrency guarantees payroll a concurrency budget that enrollment bursts cannot consume. You can also set a lower reserved (or max) concurrency on the bursty function so it cannot monopolize the account unreserved pool.
Deleting the payroll function during open enrollment abandons a critical municipal workload. Moving both functions to the same infinite unreserved pool with no caps leaves noisy-neighbor risk unchanged. Disabling account concurrency limits by raising only the enrollment function’s timeout misunderstands throttling—timeout does not grant more concurrent executions.
Exam caveat: reserved concurrency both guarantees and caps that function’s concurrency; set it high enough for payroll SLA but not so high that enrollment is needlessly throttled if they share a tight account limit. Request account concurrency increases when overall demand is legitimately higher.
Operational check: reserve concurrency for payroll; optionally cap enrollment; load-test concurrent spikes; monitor Throttles metrics per function; and document why payroll is prioritized during benefits season.