An SNS topic fans citywide alerts, but the parks department Lambda should only process messages tagged department=parks. How should invocations be reduced?
Select an answer to reveal the explanation.
Short Explanation
Don't wake every department Lambda for every citywide shout. Put a subscription filter on SNS so parks only gets department=parks. Fewer useless invokes, happier parks code.
Full Explanation
When an SNS topic fans citywide alerts but the parks department Lambda should only process messages tagged department=parks, attach an SNS subscription filter policy so that Lambda receives only matching messages. Filter policies reduce unnecessary invokes, cost, and noise at the infrastructure layer instead of waking every municipal Lambda to drop messages in code.
Subscribing every municipal Lambda and filtering inside each function after invoke wastes concurrency and cost on discarded messages.
Deleting the SNS topic and hard-coding parks alerts into Lambda source removes the citywide notification bus.
Raising reserved concurrency to absorb every citywide alert blindly papers over missing filters with more capacity spend.
Exam caveat: SNS subscription filter policies are the Associate-level tool for attribute-based message selection.
Operational check: Add a filter policy on department=parks, publish sample messages for parks and other departments, confirm only parks invokes occur, and monitor parks Lambda invoke counts during a citywide drill. Keep the civic/municipal context in mind: citywide alert storms should not wake every department's compute when attributes already identify the audience.