Spent a hair-wringing amount of time debugging this the other day and have arrived at the conclusion that there is a bug in SNS.
Given a topic, let's call it topic-a, create two subscriptions from that topic, one to lambda, and one to SQS, with the following MessageAttributes filter:
{ "attributeA": "something" }
Publish a notification to topic-a with the following MessageAttributes:
{ "attributeA": { "DataType": "String", "Value": "something"}, "attributeB": { "DataType": "String", "Value": "somethingElse"}}
Lambda will receive the message and is invoked. SQS does not receive the message, and the Cloudwatch NumberOfNotificationsFilteredOut-MessageAttributes attribute increases by 1. Remove the filter from the SQS subscription, publish the same notification again, and the message will be delivered to the queue.
I suspected this might have to do with the usage of KMS CMK's on the topic and queue, so I tried removing from both, to no avail.
This inability to use the filter when delivering to SQS has resulted in excessive usage charges, as we then need to filter messages out in memory while reading from the queue.
