SQS
Amazon Simple Queue Service (SQS) is a message queue that enables decoupling and reliable communication between distributed systems.
SQS is a poll-based message queue service for decoupling services, supporting A2A communication and message retention.
SNS
Amazon Simple Notification Service (SNS) is a pub/sub (publish/subscribe) messaging service that allows you to send messages to multiple subscribers.
SNS is a push-based notification service for real-time messaging, supporting both A2A and A2P communication.
What is Amazon SQS?
Amazon Simple Queue Service (SQS) is a fully managed message queueing service that facilitates communication between software components. SQS uses queues to decouple microservices, enabling you to create asynchronous workflows in your applications.
SQS involves three core components
Producers: These are applications that send messages to the queue.
Queues: A queue stores messages until they are processed. The retention period for these messages can be set anywhere from 60 seconds to 14 days.
Consumers: These are services that receive the messages from the queue.
Two types of message queues:
Standard queues offer unlimited throughput, at-least-once delivery (i.e., a message will always be delivered), and best-effort-ordering.
FIFO queues offer high throughput, exactly-once processing, and first-in-first-out delivery (i.e., messages are received in the exact order they are sent).
Amazon SQS is designed with message persistence to safely store all messages until they are processed, ensuring no message loss. SQS first allows several retries to process a given message. If a message cannot be processed after exhausting all tries, you can store unprocessed messages in a dead-letter queue, which can then be reviewed and reprocessed.
By decoupling applications, Amazon SQS boasts a number of benefits. It accommodates high message throughput, ensuring high performance even with greater traffic loads. Moreover, it provides independent scaling, ensuring that each service gets sufficient resources based on its individual needs. It also enhances security and durability by encrypting messages and storing them in multiple servers.
What is Amazon SNS?
Amazon Simple Notification Service (SNS) is a fully managed messaging service that supports application-to-application (A2A) and application-to-person (A2P) communication. It is designed for real-time notifications and delivers messages to applications and end users in a scalable and efficient manner.
Similar to SQS, Amazon SNS supports message persistence by letting users create dead-letter queues to store messages that cannot be processed.
Amazon SNS uses a publish/subscribe (pub/sub) messaging model and comprises 3 parts:
Publisher: A publisher is a system that creates and sends messages to an SNS topic.
Topic: A topic is an access point that enables message delivery to multiple endpoints.
Subscriber: A subscriber, or consumer, is an endpoint that receives a message from the topic.
SNS is highly performant and can send messages to multiple subscribers simultaneously. For A2A communication, SNS can deliver messages to AWS Lambda, Amazon Kinesis Firehose, and even Amazon SQS. For A2P communication, SNS can send messages directly to users via text, email, or push notifications.
If you’d like to master AWS and be able to integrate many of its services to create optimal solutions, consider taking the AWS Cloud Technology and Services course.
Features, including alerting systems, fan-out architectures, and real-time notifications, contribute to Amazon SNS's high robustness and reliability. Due to its high message throughput and capacity for A2A and A2P communication, SNS is often an integral component in event-driven architectures.
When to Use SQS
SQS is the preferred option for a cloud architecture when the message delivery system needs:
- A polling system - consumers can choose when to poll messages.
- Asynchronous processing - services can process messages independently.
- Message retention - messages can be stored for up to 14 days.
- Guaranteed message delivery - no messages in the queue are lost.
- Batching - services process messages in groups.
Consider the following real-life example: An e-commerce platform wants to process customers’ orders, which entails storing the data pertaining to the order in an RDS database.
In this workflow, customers submit orders, which enter the SQS queue. The lambda function (i.e., the consumer) polls the queue, receives the messages, and then writes the data to the RDS database.
There are several benefits to using SQS for this use case. Since SQS decouples the process, customers can submit orders even when the database is not operational. Since SQS offers at-least-once delivery, all orders will be processed without risk of message loss. Finally, SQS supports batching, which allows messages to be processed in groups, thereby improving efficiency.
Amazon SNS would not work here as it does not retain messages and would instead immediately push messages to the lambda function regardless of the database's status. So, if the database becomes unavailable, messages can be lost. Also, since SNS does not support batching, it would process messages one at a time, making for a less optimal solution.
When to Use SNS
SNS is the preferred option for a cloud architecture when the message delivery system needs:
- Real-time notifications - messages are immediately pushed to subscribers at low latency.
- Fan-out distribution - multiple subscribers can receive the same message simultaneously.
- Multiple notification subscribers - messages can be sent to applications (e.g., AWS Lambda) and end users (e.g., email).
Consider a scenario where a developer monitors the CPU usage of their EC2 instance. To ensure that the usage remains low, they want to monitor the CPU utilization metric on Cloudwatch and receive a notification whenever it exceeds a given threshold.
Amazon SNS would greatly aid the developer in creating a solution since it pushes notifications in real time and supports both A2A and A2P processes. Using its fan-out pattern, SNS can immediately send notifications to lambda functions that can work on alleviating the issue and to the developer via email to inform them about the triggered alarm.
Architecture diagram of a system using Amazon SNS for monitoring—image by Author.
Amazon SQS would be a less effective tool for this job due to its message retention. If developers wish to respond to threshold breaches, they would need to receive real-time alerts, which would not be possible if the messages were stored in queues. Furthermore, since SQS uses a polling system, messages are only accessed when polled by consumers, which increases the latency.
AWS SNS (Simple Notification Service)
Pros
- Fast, Real-Time Delivery
Pushes messages instantly to multiple subscribers (e.g., HTTP, Lambda, SQS, SMS, email). - Multiple Protocol Support
Supports a variety of endpoints like SMS, email, HTTP/S, Lambda, and SQS. - Scalable and Serverless
Can handle thousands of messages per second without managing infrastructure. - Message Fan-Out
Enables broadcasting of messages to many receivers using a single publish action. - Event-Driven Integration
Great for triggering downstream processes in event-driven architectures.
Cons
- No Message Persistence
If no subscribers are available, messages are lost (unless delivered to an SQS queue or another durable target). - Limited Message Size
Messages are limited to 256 KB in size. - No Retry Logic at Source
Failed delivery to some protocols (like HTTP endpoints) requires setting up retries or DLQs separately.
AWS SQS (Simple Queue Service)
Pros
- Reliable Message Delivery
Messages are persisted until processed or expired (up to 14 days). - Decoupling of Services
Producers and consumers operate independently, enabling scalable and resilient systems. - Dead Letter Queues (DLQs)
Helps capture and analyze failed messages for retry or debugging. - Flexible Delivery Semantics
Choose between:- Standard Queue (high throughput, at-least-once delivery)
- FIFO Queue (ordered, exactly-once delivery)
- Backpressure Handling
Helps buffer spikes in message volume between services.
Cons
- Polling Overhead
Consumers need to poll the queue, which can incur extra latency or cost (unless using long polling). - Complex Retry Management
You must manually implement retry logic and visibility timeouts. - Latency (Compared to SNS)
Slower delivery compared to SNS's immediate push.
Message Size Limit
Also limited to 256 KB (though you can use Amazon S3 for payload offloading).
SNS + SQS Together (Fan-out Pattern)
Pros
- Durable Fan-Out: Ensures all messages reach SQS queues even if downstream services are offline.
- Asynchronous & Scalable: Enables multiple services to consume the same event independently.
- Fault Tolerance: SQS ensures no message loss, and consumers can process at their own pace.
- Decoupling: Perfect for microservices and serverless patterns.
Cons
- Increased Complexity: More moving parts to monitor, secure, and manage.
- Higher Cost: Additional cost for using both services and data transfer.
- Potential for Duplication: SQS (standard) may deliver the same message multiple times.
Total Features of AWS-SNS and SQS Services
Conclusion
Both AWS SNS and AWS SQS are essential tools for building resilient, scalable, and loosely coupled applications. SNS is ideal for broadcasting messages to multiple systems, while SQS is perfect for reliable message processing and service decoupling. Together, they form a powerful messaging backbone for event-driven architectures on AWS.
If you're designing a cloud-native system, understanding and leveraging SNS and SQS can drastically improve the scalability and maintainability of your application.
