Optimizing Messaging with Amazon SNS Subscription Filter Policies — AWS Certified Developer - Associate (DVA-C02) Study Notes

This guide explores how to use subscription filter policies in Amazon Simple Notification Service (SNS) to create efficient, decoupled, and cost-effective event-driven architectures.

Learning Objectives

Define the role of subscription filter policies in an SNS fan-out architecture.
Construct JSON-based filter policies using string and numeric matching.
Differentiate between message attribute filtering and message body filtering.
Analyze the cost and performance benefits of offloading filtering logic from downstream consumers to SNS.

Key Terms & Glossary

SNS Topic: A logical access point and communication channel used to group multiple endpoints.
Fan-out: A design pattern where a single message is sent to a topic and then pushed to multiple subscribers (SQS, Lambda, HTTPS, etc.).
Subscription Filter Policy: A JSON object assigned to a subscription that determines which messages are delivered to that specific endpoint.
Message Attributes: Metadata (key-value pairs) added to a message separate from the payload, used primarily for routing.
OR Logic: Implicitly applied when multiple values are listed in a single filter policy array.
AND Logic: Implicitly applied when multiple separate keys are present in a filter policy.

The "Big Idea"

In a traditional pub/sub model, every subscriber receives every message. This creates "noise" and forces downstream services (like Lambda functions or SQS queues) to write code to discard irrelevant data. Subscription Filter Policies move this logic into the SNS service itself. By filtering at the source, you reduce unnecessary compute cycles, lower data transfer costs, and simplify your application code. It is the "gatekeeper" of the fan-out pattern.

Formula / Concept Box

Feature	Description	Example Syntax
String Matching	Exact match of string values	`"store": ["amazon", "ebay"]`
Prefix Matching	Matches start of a string	`"city": [{"prefix": "San"}]`
Numeric Matching	Comparisons (<, >, =, between)	`"price": [{"numeric": [">", 0, "<=", 100]}]`
Anything-but	Excludes specific values	`"status": [{"anything-but": "cancelled"}]`
Exists	Checks if a key is present	`"priority": [{"exists": true}]`

Hierarchical Outline

SNS Messaging Basics
- Pub/Sub Model: Publishers send to topics; subscribers receive.
- Default Behavior: Every subscriber gets every message (broadcast).
The Filtering Mechanism
- Message Attributes: Metadata added by the producer (e.g., customer_type: "premium").
- Filter Logic: SNS compares attributes against the subscriber's JSON policy.
- Drop/Deliver: If the policy matches, the message is delivered; otherwise, it is silently dropped for that subscription.
Advanced Policy Syntax
- Matching Operators: Prefix, Numeric, Anything-but, Exists.
- Message Body Filtering: (Newer feature) Filtering based on the actual JSON content of the payload rather than just metadata.
Optimization Benefits
- Compute Savings: Lambda doesn't trigger for irrelevant events.
- Cost: No charge for filtered-out messages (standard SNS pricing applies to delivered messages).
- Simplicity: Removes if/else routing logic from microservices.

Visual Anchors

Fan-out with Subscription Filtering

Loading Diagram...

The Filtering Logic Gate

\begin{tikzpicture}[node distance=2cm, auto] \draw[fill=blue!10, dashed] (-1,-1) rectangle (5,3); \node at (2, 2.7) {\textbf{SNS Filtering Engine}}; \node (msg) at (-2,1) {\boxed{Message}}; \node (attr) at (0.5, 1) [circle, draw] {Attr?}; \node (policy) at (2.5, 1) [rectangle, draw, fill=white] {Match Policy?}; \node (drop) at (4.5, 0) [red] {Discard}; \node (deliver) at (4.5, 2) [green!60!black] {Deliver};

code

\draw[->, thick] (msg) -- (attr);
\draw[->, thick] (attr) -- (policy);
\draw[->, thick] (policy) |- (deliver) node[near start, right] {Yes};
\draw[->, thick] (policy) |- (drop) node[near start, right] {No};

\end{tikzpicture}

Definition-Example Pairs

Numeric Comparison: Filtering based on mathematical ranges.
- Example: An e-commerce system only notifies the "High Value" queue if the order_total attribute is {"numeric": [">=", 500]}.
Prefix Matching: Filtering strings based on how they start.
- Example: A logistics app routes all updates for the California region by checking if zip_code starts with {"prefix": "9"}.
Anything-but Matching: Filtering by excluding specific values.
- Example: A logging service wants all logs except those marked as "DEBUG" using "severity": [{"anything-but": "DEBUG"}].

Worked Examples

Scenario: Global Retail Event Routing

Requirement: We have a single SNS Topic called GlobalDeals. We need to route messages to three different regional SQS queues (US, UK, and EMEA) based on the region attribute and price thresholds.

Step 1: Producer Code (Python SDK) The producer must attach attributes to the message:

python

sns.publish(
    TopicArn='arn:aws:sns:us-east-1:123456789012:GlobalDeals',
    Message='Summer Sale details...',
    MessageAttributes={
        'region': {'DataType': 'String', 'StringValue': 'US'},
        'price': {'DataType': 'Number', 'StringValue': '45.00'}
    }
)

Step 2: US-Specific Subscription Filter Policy This policy ensures the subscriber only gets US deals under $50.

json

{
  "region": ["US"],
  "price": [{"numeric": ["<", 50]}]
}

Step 3: EMEA Subscription Filter Policy (Anything but UK)

json

{
  "region": [{"anything-but": "UK"}]
}

Checkpoint Questions

If a message has attributes {"color": "red", "size": "large"} and a filter policy is {"color": ["red"], "size": ["small"]}, will the message be delivered? (Answer: No, because it uses AND logic between different keys).
True or False: Subscription filter policies are applied by the publisher before sending the message to SNS.
What happens to a message if it does not match any subscription filter policies on a topic?
How does using a filter policy impact the cost of a Lambda function triggered by SNS?

[!TIP] Answer Key:

No (AND logic requires all keys to match).

False (They are applied by the SNS service upon delivery).

The message is not delivered to those specific subscribers (it may be lost if no subscribers match and no DLQ is configured).

It lowers cost by preventing the Lambda from executing unnecessarily (you don't pay for the invocation).