Choosing between EventBridge, SNS, and SQS for event-driven patterns
Table of contents
- 1. The scenario
- 2. EventBridge
- 2.1. Two short paragraphs on EventBridge
- 2.2. EventBridge rule
- 2.3. EventBridge use cases
- 3. SNS
- 3.1. About SNS - you can skip this if you're a pro
- 3.2. Fanout
- 3.3. SNS use cases
- 4. SQS
- 4.1. SQS basics
- 4.2. FIFO queues for order
- 4.3. When to use SQS
- 5. Considerations
- 5.1. SNS message filtering
- 5.2. EventBridge Pipes
- 5.3. Cost
- 6. Summary
- 7. Wrap up
- 8. Further reading
1. The scenario
EventBridge, SNS, and SQS can all be used to decouple services and provide the foundation for an event-driven architecture.
Our scenario involves Alice’s e-commerce application, which consists of several microservices. This article focuses on a small portion of the system, specifically order processing.
I’ll explore three specific tasks or challenges from the order processing business requirements and discuss which of the three AWS services is the most suitable choice for each.
2. EventBridge
Users can place three types of orders in this application: standard, express, and international. Alice decided to create different workflows for each order type, as they require distinct handling.
Express orders need immediate processing. Standard orders are less urgent and can be processed in batches at the end of the day. International orders require manual intervention.

Alice’s challenge is to route orders to their corresponding workflows based on the type
property of the order
event object.
A simplified version of the order
event might look like this:
{
"type": "express",
"customerId": "12345",
"items": [{
"itemId": 12345,
"itemName": "Fitness bar",
"quantity": 1,
"unitPrice": 129.99
}],
"totalAmount": 129.99,
// many more properties
}
EventBridge excels in this scenario!
2.1. Two short paragraphs on EventBridge
EventBridge is a serverless event router that performs content-based routing to assigned targets (up to five). We create rules that define the desired event pattern for each target. When a matching event arrives at the event bus (default or custom), EventBridge invokes the target with the event.
AWS services send events to the default event bus. You can create custom event buses for custom application events (non-AWS service events). While you can use the default event bus for custom events, I prefer separating the two, keeping the default event bus for AWS events only.
2.2. EventBridge rule
Consider the express order flow. We want to match every order
event where the order originates from the order-placement-service
, is newly placed
, and has a type
of express
.
The event pattern for this looks as follows:
{
"source": ["order-placement-service"],
"detail-type": ["order.placed"],
"detail": {
"type": ["express"]
}
}
The source
, detail-type
, and detail
fields enable the creation of complex rules for specific use cases.
In Alice’s application, the source
property represents service names, while detail-type
indicates the order status. The detail
field specifies the required property values in the order event object that must be matched.
When the event bus receives a matching event, EventBridge routes it to the assigned target, in this case, a Lambda function.
2.3. EventBridge use cases
EventBridge is a great choice for decoupling services when:
- You need to match complex event patterns.
- You want to react to AWS service and support third-party events in real time.
- You’re designing multi-region or multi-account event-driven architecture.
- You need to run scheduled jobs.
3. SNS
Alice’s next event-driven challenge is to notify multiple services (e.g., user notification service, order processing service) when a new order is placed.
The diagram shows only three services for simplicity, but in reality, many more services (e.g., warehouse, delivery, or marketing) may be interested in the order.placed
event.
Alice chooses SNS to meet these business requirements.
3.1. About SNS - you can skip this if you’re a pro
Simple Notification Service (SNS), as its name suggests, focuses on notifications.
The publisher (here, the order placement service) publishes a message to an SNS topic. The topic receives messages of the same type. Services interested in these messages can subscribe to the topic. Whenever a publisher sends a message to the topic, SNS broadcasts it to all subscribers.
SNS supports multiple subscriber protocols: email, text messages, HTTP, SQS, Lambda, and more. This allows direct notifications to users’ phones or email addresses, though I would prefer a dedicated notification service in this case.
If message order is critical, you can use a FIFO (first-in-first-out) topic. FIFO topics guarantee message order and exactly-once delivery, but they have lower throughput compared to standard topics.
3.2. Fanout
The diagram illustrates a scenario where a publisher sends a message to the topic, and SNS delivers it to multiple subscribers, including SMS, SQS, and Lambda protocols.
This is called the fanout pattern, a key tool in event-driven design. Standard topics support millions of subscribers, enabling wide fanouts with SNS.
In Alice’s application, the EventBridge target Lambda function publishes the event to the express workflow topic, and SNS notifies relevant services in real time.
The Lambda function requires the sns:Publish
permission in its execution role.
3.3. SNS use cases
Use SNS when:
- You need to notify a large number of subscribers in real time.
- You’re creating alarms, for example, in CloudWatch.
- You’re designing a pub/sub (publisher/subscriber) pattern with known targets (subscribers).
4. SQS
Alice’s final challenge is protecting a third-party API endpoint called by one of the services. Like many third-party integrations, the endpoint is rate-limited, say, to one request per second.
Issues arise when more orders flood the system than the API can handle. Alice wants to minimize throttling errors from the external service.
She needs a temporary message store to buffer messages, allowing the consumer compute resource to process them at a pace suitable for the downstream API.
One of AWS’s earliest services, SQS, serves this purpose.
4.1. SQS basics
Simple Queue Service (SQS) is a serverless queue service that decouples services by buffering messages. Messages can be stored in queues for up to 14 days.
Unlike SNS, SQS is a point-to-point service.

Typically, there is one producer and one consumer.
While multiple producers can technically send to the same queue, I recommend creating separate queues for each producer to maintain clear responsibilities. Multiple producers for a single queue can complicate debugging and tracing. As a serverless service, SQS is billed by the number of requests, and you pay nothing when it’s unused. SQS also offers a generous free tier, so there’s little reason not to create multiple queues in these scenarios.
Similarly, multiple consumers can be assigned to a queue, but they will compete for messages, meaning not every consumer processes every message. This can cause issues if the consumers implement different business logic.
The consumer must delete a message from the queue after successful processing; otherwise, it becomes visible again for reprocessing.
SQS has a default retry policy, delivering unsuccessfully processed messages to a dead-letter queue (DLQ) after the maximum retry attempts. Teams can configure alarms on queue length and investigate issues when messages reach the DLQ.
4.2. FIFO queues for order
SQS queues come in two types: standard and FIFO, with principles similar to SNS FIFO topics.
Standard queues offer higher throughput but don’t guarantee message order and provide at-least-once delivery, requiring consumers to implement idempotency mechanisms.
FIFO queues ensure that messages enter and leave in the same order and guarantee exactly-once delivery.
Alice’s application uses an SQS queue to protect the third-party (e.g., delivery partner) endpoint in the scenario described.
4.3. When to use SQS
SQS is ideal for:
- Temporarily storing messages to protect downstream resources.
- Implementing reliable message delivery and processing with retries.
- Isolating unprocessed messages for debugging.
SQS pairs well with Lambda functions. Lambda polls the queue for messages (polling invocation model) and automatically deletes processed messages.
5. Considerations
Let’s discuss some additional considerations.
5.1. SNS message filtering
SNS supports message filtering, allowing subscribers to receive only messages matching specific attributes. By attaching a filter policy to a subscription, subscribers receive a subset of messages. Without a filter policy, subscribers receive all messages published to the topic.
I have seen using SNS and EventBridge interchangeably, especially with the SNS message filtering feature. It’s not easy to decide which one to use in some cases. I prefer EventBridge when the problem is more routing-focused, like the one with the different order types. I choose SNS when I want the message to be broadcast and received by other interested entities.
5.2. EventBridge Pipes
EventBridge Pipes combines aspects of EventBridge and SQS. It reacts to AWS service events in a point-to-point manner and offers filtering and message enrichment capabilities. It can provide a good alternative solution for these services in some cases.
5.3. Cost
Since EventBridge, SNS, and SQS serve different use cases — while all help decouple (micro)services — I don’t find it relevant to compare their costs.
Cost management for each service could be the topic of a separate article (or three, one for each), so I won’t discuss it here.
I’ve linked the corresponding pricing pages at the bottom of the post. You can also use the Pricing Calculator to estimate costs for your workload if needed.
6. Summary
The following table summarizes the key differences between EventBridge, SNS, and SQS.
Feature | EventBridge | SNS | SQS |
---|---|---|---|
Primary purpose | Content-based event routing | Real-time notifications | Message buffering |
Communication pattern | Many-to-many with filtering | One-to-many (fanout) | Point-to-point |
Use cases | Complex event pattern matching, AWS service events, scheduled jobs | Notifying multiple subscribers in real time, alarms, pub/sub pattern | Protecting downstream resources, reliable message delivery with retries |
Delivery guarantee | At-least-once | At-least-once (standard), exactly-once (FIFO) | At-least-once (standard), exactly-once (FIFO) |
Message retention | No retention (unless archived) | No retention | Up to 14 days |
Integration with Lambda | Asynchronous invocation model | Asynchronous invocation model | Polling invocation model |
Special capabilities | Event pattern matching, cross-account/region routing | Message filtering with subscription policies | Message buffering, throttling protection |
7. Wrap up
EventBridge, SNS, and SQS are core AWS services that enable architects and developers to design and implement event-driven architectures.
This post discussed when to use each service and provided examples for each use case in a fictional application.
8. Further reading
Event bus concepts in Amazon EventBridge - Everything about event buses
Event bus targets in Amazon EventBridge - Targets supported by EventBridge
Creating rules that react to events in Amazon EventBridge - How to create EventBridge rules
Creating a subscription to an Amazon SNS topic - Straightforward guidance from the documentation
Amazon SNS message filtering - More details on message filtering
Amazon EventBridge pricing - Pricing details for EventBridge
Amazon SNS pricing - Pricing details for SNS
Amazon SQS pricing - Pricing details for SQS