AWS SNS (Simple Notification Service) is a fully managed messaging service provided by Amazon Web Services. It enables sending notifications or messages to users or systems. SNS supports a variety of subscribers, such as HTTP endpoints, email addresses, AWS Lambda functions, or SQS queues
SNS enables a range of messaging patterns, like fan-out messaging, which rapidly dispatches messages to a large number of recipients. This makes it particularly valuable for applications that rely on real-time notification updates, like transaction alerts in banking apps, or for broadcasting messages to control time-sensitive data processing across distributed systems.
AWS SQS (Simple Queue Service) is a scalable and secure hosted queue service designed to store messages traveling between different components of an application. SQS can help decouple components, making systems more fault-tolerant and scalable. Messages can be stored in queues for short durations while waiting to be processed, which helps manage workloads.
This service supports two types of queues. Standard queues offer maximum throughput, best-effort ordering, and at least-once delivery. FIFO (First-In-First-Out) queues ensure messages are processed once and in the exact order they are sent. This flexibility makes SQS suitable for various messaging applications, from simple task queues to complex workflows.
In this article
Here are some of the main differences between SNS and SQS.
AWS SNS operates primarily on a push-based messaging model. This means that messages are automatically pushed to the subscribers once they are available without requiring them to actively check or poll for the message. This simplifies the delivery process, especially when real-time communication is crucial.
AWS SQS uses a poll-based model to store the messages in a queue. The receiving components must actively poll the queue to retrieve messages. This model is beneficial for scenarios where the consuming application must process messages at its own pace, which can help manage workloads more effectively.
SNS is structured around topics. A topic is an access point for subscribers to subscribe to dynamically or unsubscribe from notifications. This allows SNS to serve as a centralized dispatcher to multiple recipients based on a publish-subscribe model.
SQS revolves around the concept of queues. Each queue acts as a buffer between the message producers and consumers, ensuring that messages are processed orderly, depending on the queue type. This setup is essential for maintaining the smooth data flow between different parts of an application that operate at varying speeds.
SNS provides a best-effort delivery mechanism. It does not guarantee that a message will be delivered to a subscriber, nor does it support native mechanisms to ensure that messages are received only once. This model is suitable for applications where the occasional loss of messages is tolerable.
SQS offers more robust delivery guarantees. For standard queues, SQS ensures delivery at least once, meaning messages might be delivered more than once. However, FIFO queues guarantee that messages will be delivered exactly once and in the order they were sent, which is crucial for many business applications requiring high reliability and precision.
SNS can support a vast number of subscribers for each topic. It is designed to facilitate the mass delivery of messages to many recipients through direct subscriptions or other AWS services like SQS and Lambda.
SQS is designed primarily for individual message handling between decoupled application components rather than broadcasting to a large number of receivers. Once a message is retrieved from the queue, it is processed by a single consumer, making it unsuitable for direct fan-out communication scenarios.
SNS is a many-to-many communication service, suitable for broadcasting messages. The service can instantly distribute notifications to many recipients across multiple protocols and AWS services.
SQS is a many-to-one or one-to-one communication service primarily used for message queuing. It is not intended for broadcasting but for ensuring that messages are reliably transmitted between different parts of an application without loss, even under system failure conditions.
SNS is suitable for scenarios requiring real-time, push-based notifications across many subscribers. Typical use cases include alarm notifications, transaction alerts, and time-sensitive information updates.
SQS is suited for applications that require reliable message queuing, where it’s critical to maintain the order of operations and manage varying loads. Common use cases involve decoupling application components, handling asynchronous tasks, and managing scheduled jobs within distributed systems.
Here are some of the limitations of SNS.
SNS messages can only have a payload of up to 256 KB. For applications needing to send larger payloads, additional mechanisms must be implemented to split messages or reference payloads stored elsewhere. This limitation can restrict the usability of SNS in scenarios where large data must be transmitted directly.
SNS’s limited message size requires developers to be methodical in how they structure their message payloads. This often necessitates the use of compression or external storage, complicating system architecture. For extensive data transfers, it may be useful to consider strategies like using S3 for storage alongside SNS.
While SNS ensures high availability and durability, it doesn’t provide redundancy in message delivery to multiple regions. Additional configurations and duplicate topics across regions might be necessary for critical systems requiring multi-region redundancy.
This aspect of SNS could lead to increased operational complexity and costs, particularly for global applications requiring robust failover and high availability across different geographical zones.
SNS does not offer built-in retry logic for messages not delivered to subscribers. If a message delivery fails, SNS does not automatically retry sending the message. Developers must implement their retry logic within their applications or handle failed deliveries manually, adding complexity to the application architecture.
Here are some of the limitations of SQS.
SQS handles message ordering differently depending on the type of queue used. Standard queues provide no guarantees regarding the order of message delivery, and although they offer high throughput, messages may be delivered in any order. This characteristic suits applications where the order is not critical, but processing speed and scalability are paramount.
FIFO queues are designed to ensure that messages are processed exactly as they were sent. For applications where transactions or event sequences need to be processed in a specific order to maintain data integrity and operational correctness, it’s important to ensure the use of FIFO queues.
SQS imposes throughput limits to manage the service’s performance. For standard queues, it offers nearly unlimited transactions per second, with each action (send, receive, or delete) counting as a transaction. This high throughput is suitable for applications requiring rapid processing of many messages.
For FIFO queues, the throughput limit is 300 messages per second without batching or up to 3,000 messages per second with batching. While these limits are sufficient for many applications, they can become a bottleneck for extremely high-volume systems. Users must plan their architecture to accommodate or work around these throughput limitations.
In SQS, dead letter queues (DLQs) are used to sideline messages that cannot be processed successfully after several attempts. While this feature is available for standard queues, FIFO queues do not have built-in support for automatic dead letter handling. If a message in a FIFO queue cannot be processed successfully after several attempts, it must be manually handled.
The absence of automatic DLQ support for FIFO queues requires developers to implement custom solutions to manage failed message processing. This might involve manually monitoring and rerouting messages to a separate queue for further investigation and processing, increasing the system’s complexity and management overhead.
When deciding between AWS SNS and SQS, it’s essential to consider the specific requirements of your application and the characteristics of each service. Here are some key considerations to guide your decision:
Lumigo is a cloud-native observability and troubleshooting tool. Lumigo automatically enriches traces with complete in-context request and response payloads and correlates them to the appropriate logs and metrics. This unified view of all troubleshooting data enables users to solve cloud native issues 80% faster than similar tools. Monitoring AWS SQS with Lumigo:
Get started with a free trial of Lumigo for your microservice applications.
