Hello Reader,

SNS versus SQS versus EventBridge is one of the most common comparison questions I see, both in Solutions Architect interviews and in real customer conversations. A lot has changed on the features recently.

In today's edition, I will level-set what these three services are, then compare them on every factor that matters. I have used these exact same factors when I designed world-scale applications as a Principal Solutions Architect at AWS. Let's get started.

The Foundation & Push Vs Pull

SNS is a pub/sub mechanism. You publish a message to a topic. Every subscriber to that topic receives it. Push mechanism.

SQS is a queuing system. Messages sit in a queue. Consumer services pull the messages out. Pull mechanism.

EventBridge is an event bus. Messages go to the bus, and multiple services can consume them based on rules. Push mechanism.

The push versus pull distinction matters more than most engineers realize. A lot of my students and customers get confused here.

With SQS, your application running on EKS, ECS, EC2, or Lambda can read directly from the queue using the SDK. Lambda makes this feel like SQS is pushing, but that is just an illusion. The Lambda service is continuously polling the queue on your behalf and invoking your function when messages arrive. If you are running on EKS, ECS, or EC2, you write the polling code yourself.

With SNS and EventBridge, it is the opposite. These services push to AWS services that their service team has integrated with. You cannot sit on EC2 and pull from an SNS topic. If you want your EKS, ECS, or EC2 application to receive from SNS or EventBridge, you have to expose an HTTPS endpoint (ALB, API Gateway) that is publicly reachable, and pay for that infrastructure. It works, but it is not as clean as SQS.

Now let's compare on the other factors.

Feature Comparison

1/ Targets and integrations

SNS targets: Lambda, SQS, HTTPS endpoints, SMS, mobile push, email, Kinesis Data Firehose.

SQS: any compute service can read from SQS. Lambda has a direct managed integration.

EventBridge: 30+ AWS service targets including Lambda, SQS, SNS, Kinesis Data Stream, Firehose, API Gateway, Step Functions, and more. EventBridge also has the strongest third-party producer integrations. Datadog, Epsagon, Zendesk, PagerDuty all publish into EventBridge natively, and EventBridge already knows the schema of their events, which makes your integration code much simpler.

Interview takeaway: If the question involves third-party SaaS producers, EventBridge is usually the right answer.

2/ Message ordering

SNS FIFO: maintains order.

SQS FIFO: maintains order.

EventBridge: does not maintain message order.

If ordered processing is a hard requirement, EventBridge is off the table.

3/ Scaling and concurrency control

All three scale automatically. The numbers differ.

SNS Standard: nearly unlimited throughput. FIFO has limits but they are high. Control downstream consumption with Lambda per-function concurrency.

SQS Standard: nearly unlimited throughput. Control downstream consumption with Lambda batch size and per-function concurrency.

EventBridge: soft quota of 100,000 transactions per second for PutEvents, and roughly 19,000 TPS for target invocations. These are soft and vary by region, so they can be raised via support.

For most enterprise workloads, all three are fine. For extreme-scale publishing, SNS and SQS have more headroom out of the box.

4/ Conditional message processing (this one got updated)

This is the section where engineers are giving outdated answers.

SNS (previously): could only route subscribers based on message metadata, which is information attached to the message, like the envelope of a letter, not the content.

SNS (now): can route subscribers based on values inside the message payload itself. This is a big change. Think of it as reading the letter, not just the address.

SQS: cannot route based on message content. You combine SNS plus SQS to achieve this pattern.

EventBridge: has supported detailed rule-based message filtering on payload content since day one.

Here is a concrete example. Your message has a "category" field with values like "clothing" or "chemical," and you want different Lambdas to process each. Previously only EventBridge could do this. Today, SNS can do it too. SQS still cannot, but SNS + SQS combination is a common fan-out pattern to achieve the same result.

Interview delight: When asked about EventBridge's unique advantages, candidates who say "payload-based filtering" are giving an outdated answer. Say instead that EventBridge still leads on schema discovery, registry, and message transformation, and that SNS has caught up on payload filtering.

5/ Message replay (also updated)

Previously, only EventBridge could archive messages and replay them, and it could do so for an unlimited period.

SNS now supports archive and replay for 365 days. Pretty significant.

Why does this matter? Say your consumer application has a bug. It processes a message, but the business logic is wrong. You fix the code. With SQS, the message is already gone, and the producer has to resend it to test. With SNS or EventBridge, you just replay the archive. The producer does not have to do anything.

One caveat: SNS archive is available only on FIFO topics, so factor that in for your design.

6/ EventBridge superpower: Schema Registry

This is where EventBridge still stands alone.

EventBridge automatically discovers the schema of messages flowing through it. It can tell you the fields, the types, everything. It will also generate code bindings for you to parse those messages in your consumer.

You can store all the schemas in a central schema registry, which makes onboarding new engineers and new teams significantly easier. Predefined schemas for AWS events and third-party SaaS events come out of the box.

With SNS and SQS, you are responsible for knowing the schema, documenting it, and writing the parsing code yourself.

7/ Message transformation

SNS: cannot transform messages.

SQS: cannot transform messages.

EventBridge: can transform messages before delivering them to a target.

This is another reason EventBridge is popular for integration-heavy workloads.

8/ Durability, encryption, and pricing

All three replicate messages across multiple Availability Zones within a region. Your messages are safe even if an AZ goes down.

Encryption: SNS, SQS, and Eventbridge all support both AWS-managed and customer-managed KMS keys at rest. This is added to Eventbridge now, it was not the case before.

Pricing: SNS and SQS are cheaper per request. They are designed for 64 KB chunks. EventBridge is designed for 256 KB chunks and priced accordingly.

For high-volume, low-payload workloads, SNS and SQS win on cost. For richer events with more metadata, EventBridge pricing is more reasonable than it looks.

9/ Persistence and DLQ behavior

SNS: no formal persistence. It retries for 23 days, then the message can go to a Dead Letter Queue, which is an SQS queue.

SQS: default message retention is 4 days, configurable from 60 seconds up to 14 days.

EventBridge: no formal persistence. It retries for 24 hours, then the message goes to a DLQ.

Pro tip I give my customers: For SNS and EventBridge message filtering, a very common production issue is when a message satisfies none of your rules. You only find out 23 or 24 hours later when it lands in the DLQ. The fix is to create a catch-all rule that processes unmatched messages and fires an alert, so you know the moment something is off. This one pattern has saved my customers real money.

SQS has a different model. Because it is pull-based, if a message is pulled but not processed successfully, it gets rolled back to the queue after the visibility timeout. SNS and EventBridge have no rollback. Once the message is delivered, it is gone.

Keep these requirements in mind to choose one vs another.

As a Solutions Architect, the interview-winning move is not picking one service. It is walking through the requirements with the interviewer, eliminating options with reasoning, and arriving at the right answer together.

Delight, don't meet.

Keep learning and keep rocking 🚀,

Raj

P.S - If you want to get an AWS Solutions Architect job without coding or learning every AWS service, the 8th cohort for AWS SA Bootcamp is launching on May 16th, 12 PM ET (Eastern Time) via live webinar. Please register for the webinar below:

Here’s what you get when you show up LIVE:

1. My exclusive Solutions Architect framework to prep you for today's job market! But if you’re not live, you won’t get it. No second chances.
2. Full bootcamp details, my new stealth product reveal to help you prepare better, AND a special offer for live participants only.
3. You will have the chance to interact with me and ask questions.

And good news - it already worked for last cohort's students who secured cloud jobs in top companies, including at AWS, Microsoft, Google, JPMorgan, Reddit, and some of them didn't even have cloud experience 💰.

Spots are limited, so don't miss it!