Why Your SNS Messages Silently Disappear
SNS filter policies live on subscriptions, not in your code, so publishes can 'succeed' while messages never arrive. Here's why it happens and how to catch it early.
Publishing a message to an AWS SNS topic and getting back a MessageId doesn't guarantee delivery. Filter policies are attached to subscriptions, not topics, and if a publish call omits a required message attribute (like eventType), SNS silently filters the message out — no error, no DLQ entry, just an incremented NumberOfNotificationsFilteredOut metric in CloudWatch. Code review, mocked unit tests, and even AI coding assistants all miss this because the filter policy lives in your AWS account, not your repository.
This is especially dangerous in event-driven architectures: the publish code looks correct, the subscription config looks correct, but the mismatch between them is invisible anywhere in the codebase. AI assistants fall into the same trap, often replicating the same missing attributes found in existing publish calls since they have no visibility into the actual filter policy.
The fix proposed here is to surface live infrastructure context — specifically subscription filter policies — directly to the AI assistant via MCP. A tool called infrawise scans SNS topics and subscriptions read-only, and exposes required message attributes through a get_topic_details call, letting the assistant query filter requirements before writing any publish code and generate the correct MessageAttributes block on the first try.
The takeaway for engineers: SNS filter mismatches are silent failures typically discovered only through customer complaints in production. Knowing whether FilterPolicyScope targets MessageAttributes or MessageBody, and making that contract visible at coding time rather than incident time, is the only reliable way to prevent this class of bug.