A 911-adjacent callback API on Lambda must keep consistently low latency; the agency accepts paying for idle warm capacity. Which setting addresses cold starts?
Select an answer to reveal the explanation.
Short Explanation
When every millisecond on a callback API matters and idle cost is OK, provisioned concurrency keeps engines warm—like firefighters sleeping at the station. Zero reserved concurrency is the opposite of low latency.
Full Explanation
A 911-adjacent callback API on Lambda that must keep consistently low latency—and where the agency accepts paying for idle warm capacity—should configure provisioned concurrency so execution environments stay initialized and cold starts do not violate the latency SLO. Provisioned concurrency keeps a pool ready, removing init-time surprises when urgent callbacks arrive after quiet periods. For emergency-adjacent citizen communications, that cost trade is often justified and should be explicit in the architecture.
Setting reserved concurrency to zero to serialize all emergency callbacks creates throttling and queues—the opposite of low latency. Disabling the function’s execution role during off-peak hours breaks invocations. Removing all memory from the function to minimize billing is invalid and harmful to CPU allocation.
Exam caveat: provisioned concurrency differs from reserved concurrency—provisioned addresses cold starts; reserved guarantees/caps concurrency. You often combine both thoughtfully. Scale provisioned schedules if call volume is diurnal, and still keep handlers warm-path lean.
Operational check: set provisioned concurrency to meet the p99 latency SLO; load-test after idle periods; monitor ProvisionedConcurrencyUtilization; pair with appropriate reserved concurrency; and review monthly cost against the emergency UX requirement.