SNS vs EventBridge: the 100-point cap nobody talks about

I've been digging into AWS in depth lately. At some point I got stuck on something: EventBridge and SNS seemed to do exactly the same thing. Both receive something, filter it, distribute it. Every article I read gave me "it depends on the use case" without ever showing a real, measurable limit.

So I stopped reading comparison posts and went straight to the AWS docs, plus a couple of GitHub issues. Here's what came out of it.

The simple case: yeah, they do the same thing

Let's get this out of the way first. If your need is filtering on two or three flat fields (country, priority, amount), SNS and EventBridge do strictly the same thing. No technical advantage of one over the other. The choice becomes a matter of organization, not technology.

The real question is where each one hits its ceiling, and whether your project will ever get close to it.

SNS has a mathematical limit AWS admits itself

On its SNS message filtering troubleshooting page, AWS states plainly that if your pattern matching needs exceed SNS's filtering capabilities, you should switch to EventBridge rules. That's not me inventing a hierarchy, it's written in their own docs.

And that ceiling is a points system. A kind of complexity budget you're not supposed to exceed.

The rules:

• a pattern with a single wildcard = 1 point
• a pattern with multiple wildcards = 3 points per wildcard

Example. "pay*" has one wildcard, that's 1 point. "pay*ment*" has two wildcards in the same pattern, that's 2 x 3 = 6 points.

You add all of that up field by field, then across all fields, and the total can't exceed 100 points for the whole policy. Go over that, and AWS simply refuses to create your filter policy.

Take two fields:

{
  "country": ["CM*", "US*", "FR*"],
  "reference": ["INV-*-2024-*", "ORD-*-2024-*"]
}

country: 3 patterns with 1 wildcard each = 3 points.
reference: 2 patterns with 2 wildcards each = 2 x 6 = 12 points.
Total: 15 points out of the 100 allowed.

You can see how in 95% of real cases you'll never get close to this limit. But it exists, it's documented on the filter policy constraints page, and EventBridge has nothing comparable.

That same page lists other hard numbers: 5 keys max per filter policy, 256 KB max size, 200 filter policies per topic by default (10,000 per account).

Nested JSON, where I was half wrong

My starting line was "SNS can't filter nested JSON, EventBridge can." Wrong, or at least incomplete.

SNS has two filtering modes. The default mode, based on message attributes, genuinely doesn't support nested structures, that's stated clearly in the constraints doc mentioned above. But since 2022 there's a second mode, based on the entire message body (FilterPolicyScope: MessageBody), that lets you filter on nested fields without duplicating that data into separate attributes. CloudToolStack breaks it down well.

So the honest answer is: SNS can, as long as you turn on the right mode. And to complicate things further, there's an open issue on AWS SAM's GitHub repo documenting a specific bug: when a filter policy mixes fields at different nesting depths (say a flat status field alongside a nested before.owner field in the same policy), the deployment tool fails at creation time, even though SNS itself is supposed to support this. The kind of detail you only find by digging, never in a generic blog comparison.

What's actually still different: the vocabulary of the filter

Even with the MessageBody mode turned on, a real gap remains. EventBridge supports "or"-style logical combinations across multiple fields, something like "match if country = CM and priority = high, or if amount > 1000". SNS has no inter-field combination operator like that.

SNS also has a syntax constraint: you can't mix an anything-but operator with a prefix operator in the same element, they need to be separate objects in the array. EventBridge additionally supports matching on IP ranges in CIDR notation, which SNS doesn't have at all.

Subscriber count, a number that's easy to misread

A comparison by Ashish Patel on Medium gives numbers that reset the picture. EventBridge: 300 rules per bus, 5 targets per rule. SNS: up to 2,500,000 subscriptions per standard topic, 100 per subscription on FIFO.

On paper this would make EventBridge look "small". It's actually the opposite: SNS crushes it on raw volume of identical subscribers, which makes it a great fit for massive fan-out to consumers that all do the same thing (thousands of identical SQS queues, for instance).

SNS's real limit isn't volume, it's the variety of target types. SNS can only target SMS, email, Lambda, SQS, HTTP, and mobile push. EventBridge, on the other hand, is natively wired to over 130 event sources and can directly target more than 35 AWS services (Step Functions, Kinesis, ECS, CodePipeline, API Gateway...) without going through an intermediary.

What SNS does better, no bias here

SNS sends an SMS or an email directly to a human. EventBridge can't do that on its own, it has to delegate to SNS or to a Lambda that calls SES.

SNS also has a FIFO variant that guarantees strict delivery order and no duplicates. Those FIFO topics only deliver to FIFO SQS queues, which makes it a solid fit for ordered fan-out to multiple pipelines. EventBridge doesn't guarantee any ordering, not even approximate.

How I'd actually decide

Simple filtering, few wildcards, few combined fields → SNS is enough, no reason to overcomplicate.

Risk of going past 100 points, or need for "or" operators across fields → EventBridge becomes necessary.

Need to target varied services beyond Lambda/SQS → EventBridge.

Need guaranteed delivery order with no exceptions → SNS FIFO, the only valid option between the two.

Multiple teams that need to subscribe without ever having to ask you → EventBridge, because they create their own rules on the bus without going through you.

Bottom line

My initial skepticism held up on the simple case, but falls apart as soon as you push on filtering complexity or target diversity. And the most interesting part of this whole research trip is that the answer was already there, in the official docs, with exact numbers, just buried under layers of articles that prefer "it depends on the use case" over actually going and checking.