AWS offers multiple services for decoupling business domains in event-driven patterns. The three main ones are EventBridge, SNS, and SQS. Use EventBridge for targeted content-based routing when you need to match complex rules. When multiple services or users need real-time notifications, SNS is a reasonable choice. Use SQS to buffer events when you want to protect downstream resources.

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.