A bursty 311 webhook invokes AWS Lambda and occasionally throttles during storm-related spikes. What should the architect do to meet burst concurrency needs?
Select an answer to reveal the explanation.
Short Explanation
Storm day 311 traffic is a flash mob at the door—Lambda needs enough concurrency tickets. Reserved or provisioned concurrency sized for the burst stops throttles. Zeroing concurrency, killing the API, or lowering account limits makes the outage worse.
Full Explanation
Bursty 311 webhooks on AWS Lambda need enough concurrency headroom so storm-day spikes are not throttled. Right-sizing reserved concurrency or using provisioned concurrency where cold starts and burst matter lets invocations run instead of failing or queuing behind account limits. Meeting burst concurrency needs is therefore a direct Task 3.2 performance action for event-driven civic integrations that spike with weather and outages. Setting reserved concurrency to zero on the function to silence webhooks fails because it intentionally blocks useful traffic and creates an outage rather than absorbing the storm spike. Removing API Gateway so clients retry against a closed endpoint fails conceptually: it removes the managed entry point and does not increase Lambda’s ability to run concurrent invocations. Lowering the account concurrency limit below observed peak invocations fails because it guarantees more throttling exactly when 311 demand peaks. Exam caveat: reserved concurrency both protects and caps a function—set it high enough for the burst but leave account concurrency for other critical municipal functions; provisioned concurrency has cost and needs warm-up planning. Operational check: review CloudWatch throttles during prior storms, set reserved or provisioned concurrency above peak concurrent executions with headroom, retest with a synthetic spike, and alert on Throttles and IteratorAge or API 429s.