How do filter policy operators work?

Filter policies support several operators: exact string match (plain string values), prefix match ({"prefix": "value"}), numeric comparisons ({"numeric": [">", 100]}), anything-but ({"anything-but": ["value"]}), exists ({"exists": true}), and combinations. Within a single attribute, multiple values use OR logic — the message matches if any value matches. Across different attributes, AND logic applies — all attributes must match. This lets you build complex routing rules like 'event_type is order AND priority is greater than 5'.

SNS Filter Policy Builder

ServerlessAWS

Build SNS subscription filter policies with attribute matching and operators.

Last verified: May 2026

SNS Filter Policy Configuration

Filter Scope

Attribute 1

Attribute Name

Match Type

Values (comma-separated)

Generated SNS Filter Policy

Output will appear here...

About This Tool

SNS subscription filter policies let subscribers receive only the messages they care about, reducing unnecessary processing and cost. A filter policy is a JSON document that defines attribute-matching rules using exact values, prefix matching, numeric comparisons, existence checks, and logical operators. With SNS supporting both message-attribute filtering and message-body filtering (payload-based), choosing the right approach and constructing correct filter syntax is essential. The SNS Filter Policy Builder generates valid filter policy JSON with the correct operator syntax for common filtering patterns.

Real-World Scenario

Your team's SNS topic receives all order events; downstream subscribers (fulfillment, analytics, fraud detection) each need a different subset. Without filter policies, each subscriber processes ALL events and discards 80%. The builder generates per-subscription filter policies: fulfillment gets `event_type=[order_placed, order_cancelled]`, analytics gets all events, fraud detection gets `amount > 10000 OR is_first_order=true`. Lambda invocation cost drops 75% across the fleet because each consumer only sees relevant events.

When to Use This Tool

•Building filter policies that route order events to different SQS queues based on order type and priority attributes
•Creating numeric range filters that send only high-value transaction notifications to a processing Lambda
•Defining prefix-based filters that route events by region or service namespace to the appropriate subscribers
•Constructing compound filter policies with AND/OR logic across multiple message attributes

Pro Tips

TIP

Use attribute-based filtering whenever possible — it's faster and cheaper than payload-based. SNS evaluates attributes without parsing the message body. Add a few well-chosen attributes (event_type, region, priority) at publish time and filter on those instead of trying to filter on payload fields.

TIP

The `numeric` operator is the most-underused. Filtering 'high-value transactions over $10,000' is a one-liner with `{"numeric": [">", 10000]}` — much cleaner than fanning out to every subscriber and having them filter in Lambda code.

TIP

When a single subscriber needs OR logic across multiple attributes (e.g., 'priority=high OR vip_customer=true'), you can't do it in a single filter policy — that's AND across attributes. Either use two subscriptions OR add a derived attribute at publish time (e.g., `should_notify=true` set whenever either condition is met).

How It Works Under the Hood

The builder constructs SNS subscription filter policies as JSON documents. Within each attribute, multiple values use OR logic. Across attributes, AND logic applies. Output supports MessageAttributes scope (default, evaluates against publish-time attributes) and MessageBody scope (parses JSON body). Generated as the FilterPolicy parameter for `aws sns set-subscription-attributes` and as Terraform aws_sns_topic_subscription.filter_policy.

Frequently Asked Questions

What is the difference between attribute-based and payload-based filtering?: Attribute-based filtering (the default) matches against message attributes — key-value pairs set when publishing. Payload-based filtering matches against fields in the message body (JSON). Attribute-based filtering is more efficient because SNS evaluates attributes without parsing the message body. Payload-based filtering is useful when publishers cannot add message attributes or when the filtering criteria exist only in the message payload. You set the filter policy scope to MessageAttributes or MessageBody when creating the subscription.
How do filter policy operators work?: Filter policies support several operators: exact string match (plain string values), prefix match ({"prefix": "value"}), numeric comparisons ({"numeric": [">", 100]}), anything-but ({"anything-but": ["value"]}), exists ({"exists": true}), and combinations. Within a single attribute, multiple values use OR logic — the message matches if any value matches. Across different attributes, AND logic applies — all attributes must match. This lets you build complex routing rules like 'event_type is order AND priority is greater than 5'.

Related Learning Guides

SQS vs SNS vs EventBridge25 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.