An order service publishes every order event to a single Amazon SNS topic. Three SQS queues subscribe to the topic, but an analytics queue should receive only events where the event message attribute orderStatus equals SHIPPED. Currently all three queues receive every event, and the team filters them inside the consumer, wasting consumer compute. The developer wants SNS to deliver only matching events to the analytics queue without changing the publisher. Which approach meets this requirement?
- AAttach an SNS subscription filter policy to the analytics subscription that matches the orderStatus message attribute equal to SHIPPED. Correct
- BCreate a second SNS topic dedicated to shipped events and reconfigure the order service to publish shipped events to it as well as the original topic.
- CEnable raw message delivery on the analytics subscription so SNS strips the envelope and forwards only the shipped events to the analytics queue.
- DSet a redrive policy on the analytics queue so events that do not match the shipped status are moved to a dead-letter queue instead of being processed.
Why A is correct: A subscription filter policy evaluates message attributes at the topic and delivers only matching messages to that subscription, so only shipped events reach the analytics queue without any publisher change.
Why B is wrong: A second topic works only if the publisher changes to route shipped events to it, which the requirement forbids, and it duplicates publishing logic the team is trying to avoid.
Why C is wrong: Raw message delivery changes the payload format passed to the queue but applies no condition, so the analytics queue still receives every event rather than only shipped ones.
Why D is wrong: A redrive policy routes messages to a dead-letter queue only after repeated processing failures, so it neither filters by attribute nor prevents non-matching events from arriving.