Comparisons: SQS vs SNS in AWS — Simple Notification Service and Simple Queue Service.

SNS and SQS with Event Bridge

SQS and SNS are important components for scalable, large scale, distributed, cloud-based applications:

SNS is a distributed publish-subscribe service.

SQS is distributed queuing service.

SNS (Simple Notification Service)

Amazon SNS is a fast, flexible, fully managed push notification service that lets you send individual messages or to bulk messages to large numbers of recipients. Amazon SNS makes it simple and cost effective to send push notifications to mobile device users, email recipients or even send messages to other distributed services.

SNS is a distributed publish-subscribe system. Messages are pushed to subscribers as and when they are sent by publishers to SNS.

SNS supports several end points such as email, sms, http end point and SQS. If you want unknown number and type of subscribers to receive messages, you need SNS.

With Amazon SNS, you can send push notifications to Apple, Google, Fire OS, and Windows devices , as well as to Android devices in China with Baidu Cloud Push. You can use SNS to send SMS messages to mobile device users in the US or to email recipients worldwide.

SQS (Simple Queue Service)

Amazon SQS is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications.

SQS is distributed queuing system. Messages are not pushed to receivers. Receivers have to poll SQS to receive messages. Messages can be stored in SQS for short duration of time (max 14 days).

Messages can’t be received by multiple receivers at the same time. Any one receiver can receive a message, process and delete it. Other receivers do not receive the same message later. Polling inherently introduces some latency in message delivery in SQS unlike SNS where messages are immediately pushed to subscribers.

Key Differences

Entity Type
SQS : Queue (similar to JMS, MSMQ).
SNS : Topic-Subscriber (Pub/Sub system).

Message consumptionSQS : Pull Mechanism — Consumers poll messages from SQS.
SNS : Push Mechanism — SNS pushes messages to consumers.

PersistenceSQS : Messages are persisted for some duration is no consumer available. The retention period value is from 1 minute to 14 days. The default is 4 days.
SNS : No persistence. Whichever consumer is present at the time of message arrival, get the message and the message is deleted. If no consumers available then the message is lost.

In SQS the message delivery is guaranteed but in SNS it is not.

Consumer TypeSQS : All the consumers are supposed to be identical and hence process the messages in exact same way.
SNS : All the consumers are (supposed to be) processing the messages in different ways.

Use Cases

Choose SNS if:

• You would like to be able to publish and consume batches of messages.
• You would like to allow same message to be processed in multiple ways.
• Multiple subscribers are needed.

Choose SQS if:

• You need a simple queue with no particular additional requirements.
• Decoupling two applications and allowing parallel asynchronous processing.
• Only one subscriber is needed.

We can design fanout pattern by using both SNS and SQS. In this pattern, a message published to an SNS topic is distributed to multiple SQS queues in parallel.

Comparisons: AWS EventBridge vs AWS SNS.

Amazon EventBridge and Amazon SNS have many similarities, both can be used to decouple publishers and subscribers. However, there are differences in the list of targets and features for each service, and your choice of service depends on the needs of your use-case.

EventBridge provides more features.

Amazon EventBridge

Awesome Cloud: Amazon EventBridge

Amazon EventBridge is a serverless, fully managed, and scalable event bus that enables integrations between AWS services, Software as a services (SaaS), and your applications.

EventBridge delivers a stream of real-time data from AWS services, SaaS applications and your own applications to different types of targets without writing code. The publisher sends a JSON event to an event bus, and to receive events, you create a rule. If the published event matches with a rule, the event is routed to up to five targets. EventBridge is directly integrated with over 130 event sources and over 35 targets.

EventBridge Features

• Advanced event rules filtering.
• Content-based event filtering.
• Schema registry.
• Message transformation.
• Custom events.
• Archive and replay events.
• SaaS apps integration.
• API destinations.

Amazon EventBridge builds upon and extends CloudWatch Events.

Amazon SNS

Awesome Cloud: Amazon SNS

Amazon SNS is a fully managed service that provides message delivery from publishers (producers) to subscribers (consumers). Publishers communicate asynchronously with subscribers by sending messages to a topic, which is a logical access point. Clients can subscribe to the SNS topic and receive published messages using a supported endpoint type.

SNS is used for both application-to-application (A2A) and application-to-person (A2P) communication. The A2A pub/sub functionality provides topics for high-throughput, push-based, many-to-many messaging between distributed systems, microservices, and event-driven serverless applications. Using Amazon SNS topics, your publisher systems can fan-out messages to a large number of subscriber systems.

SNS Features

• Nearly unlimited throughput.
• Very low latency (typical under 30 msec).
• Many subscribers, high message fanout (SNS Standard support 100,000 Standard topics and each topic supports up to 12.5M subscriptions).

Key Differences: AWS EventBridge vs AWS SNS

Targets

• EB: Lambda, SQS, SNS, Kinesis Streams, Kinesis Firehose (over 15 AWS services available as event targets).
• SNS: Lambda, SQS, Kinesis Firehose, HTTP/S endpoints, Email, SMS, Mobile Push. (Only possible subscriber type for a FIFO topic is an SQS FIFO queue)

EventBridge has a lot more targets options.

Number of targets/subscriptions**

• EB: 300 rules per event bus and 5 targets per rule.
• SNS: 2,500,000 subscriptions per Standard topic and 100 per subscriptions FIFO topic.

Message filtering

• EB: Message Content-based filtering.
• SNS: Message Attribute-based filtering.

SNS can’t filter messages by their content. If you want to filter messages, you have to add message attributes because SNS can not inspect the payload of messages. On the other hand, EventBridge gives you a way to pattern match against the event content.

Availability SLA

• EB: 99.99%.
• SNS: 99.9%.

Input transformation

• EB: Supported. (In specific use cases, you might want to customize the text of event fields before passing them to a target)
• SNS: Not supported.

FIFO Ordering

• EB: Not supported.
• SNS: Supported (with SNS FIFO Topics).

A schema defines the structure of events that are sent to EventBridge. EventBridge provides schemas for all events that are generated by AWS services. You can also create or upload custom schemas or infer schemas directly from events on an event bus.

SaaS integration
EB: Supported.
SNS: Not supported.

EventBridge is the only event-based service that integrates directly with third-party SaaS partners.

Message replay
EB: Supported (with Archive and Replay feature).
SNS: Not supported.

**Cross-region
**EB: Route events from any commercial AWS Region to other supported Regions (US East (N. Virginia), US West (Oregon), and Europe (Ireland).SNS: Supports cross-region delivery of notifications to SQS queues and to Lambda functions.

Publish throughput
EB: Varies by Region and adjustable quota.
SNS: Varies by Region and adjustable quota.

Dead-letter queues
EB: Supported.
SNS: Supported.

Max message size
EB: 256 KB.
SNS: 256 KB.

Encryption at rest and transit
EB: Supported (Not supported with KMS yet).
SNS: Supported.

Use Cases

Choose EventBridge if:

• You want to build an application that reacts to events from SaaS applications, AWS services or Custom applications.
• You want to publish messages to multiple subscribers, and use the event data itself to match targets interested certain patterns (content-based filtering: by creating rules that are applied across the entire event body/message content).
• You want input transformation support based on your need.
• You want to set up scheduled events using the popular Unix cron syntax.
• You want to use unique features like built-in schema discovery capabilities, archive and replay events, etc.
• You want a lot more targets and integration with a wider variety of services as a target.

EventBridge is the only event-based service that integrates directly with third-party SaaS partners.

Choose SNS if:

• You want to build an application that reacts to high throughput or low latency messages published by other applications or microservices.
• You want to publish messages to multiple subscribers with a single action (very high fan-out, thousands or millions of endpoints).
• You want strict message ordering (first-in-first-out) (with FIFO Topics).
• You want to publish and consume batches of messages.
• You want built-in delivery subscriptions for SMS, email, mobile push and HTTP endpoints (that EventBridge does not provide).

Alternatives

• Amazon MQ (RabbitMQ and ActiveMQ) — Not recommended for new cloud native applications.

Summary

Amazon EventBridge and Amazon SNS, both can be used to develop event-driven applications, and your choice will depend on your specific needs. It is recommended using SNS for applications that react to high throughput or low latency messages. On the other hand, EventBridge has the potential to be a key ingredient in a modern, highly distributed microservices architecture, and SaaS/AWS Services integration. Now a days, EventBridge has become a popular alternative.