What are the differences between SQS and SNS? A clear explanation of how to use and combine them effectively in AWS design.

Amazon SQS and Amazon SNS are both AWS messaging services, but their design roles are different. SQS is a service that holds messages in a queue and retrieves them when further processing is needed. SNS is a Pub/Sub type service that distributes published messages to multiple destinations.

Simply remembering the difference as "queue vs. notification" is insufficient for practical design decisions. The appropriate configuration will vary depending on where you handle sudden increases in processing volume, how you branch to multiple subsequent processes, and where you ensure reprocessing in case of failure.

This article compares SQS and SNS from the perspectives of delivery method, message retention, order guarantee, and use cases. It outlines cases where SQS is the right choice, cases where SNS is the right choice, and cases where both are combined, explaining the key decision-making criteria to avoid confusion when designing your AWS system.

SQS and SNS Basics

Amazon SQS and Amazon SNS are both AWS services used for messaging between systems. By communicating via messages rather than directly connecting applications, processing delays and the impact of failures can be isolated.

The difference between the two lies in how they handle messages. SQS holds messages in a queue and retrieves them when further processing is needed. SNS, on the other hand, delivers messages published to a topic to subscribers.

What is SQS?

Amazon SQS (Amazon Simple Queue Service) is a service that holds messages in a queue. A queue is a place where messages waiting to be processed are temporarily stored.

Using SQS allows you to separate the application itself from subsequent processing. For example, if you perform image conversion and thumbnail generation synchronously after an image upload, processing can become congested during periods of high traffic, affecting user response times. By sending the information to be converted to SQS, subsequent processing can retrieve messages from the queue and execute them according to processing capacity.

SQS is effective when you want to absorb peak processing loads or level out the load on subsequent systems. Because the sending and processing sides are separated, it is possible to create a configuration where temporary processing delays or failures are less likely to spread to the entire application.

SNSとは

Amazon SNS (Amazon Simple Notification Service) is a Pub/Sub type service that delivers messages to multiple recipients. The sender publishes a message to an SNS topic, and the message is delivered to recipients who are subscribed to that topic.

SNS is used when a single event needs to be delivered to multiple processes or notification recipients. For example, when an order is completed, it can trigger simultaneous email notifications to the user, notifications to administrators, inventory updates, and the sending of logs for analysis. Instead of the sender individually calling each process, the event is distributed via SNS.

You can specify delivery destinations such as email, SMS, AWS Lambda, SQS, and HTTP/S endpoints. Therefore, SNS is used not only for notifying people but also as a mechanism for disseminating events to multiple systems.

The big difference between SQS and SNS

The main difference between SQS and SNS is whether you "retain" or "distribute" messages.

SQS is a system that holds messages in a queue and retrieves them for subsequent processing at its own timing. It is chosen when you want to temporarily store processing, absorb increases in processing volume, or level out the load on subsequent processing.

Social networking services (SNS) are systems that distribute a single message to multiple recipients. They are chosen when you want to notify multiple processes of an event or deliver the same message to multiple services.

During the design phase, first determine whether "subsequent processing needs to be handled by a queue" or "events need to be distributed to multiple destinations." For the former, SQS is the standard; for the latter, SNS is the standard. If both requirements are met, consider a configuration where distribution is done via SNS and reception is handled by SQS.

Comparison of SQS and SNS

SQS and SNS are both AWS messaging services, but they have different uses. SQS holds messages in a queue, and recipients retrieve them according to their processing capacity. SNS delivers messages published to a topic to subscribers.

During the design phase, we differentiate between "whether to retain data," "whether to distribute data," and "how much control we want over order and duplication." The main differences are as follows:

Distribution method

SQS is a pull-type service. The sender places messages in a queue, and the receiver retrieves them from the queue according to its processing capacity. The sender does not directly control the receiver's processing timing.

This mechanism helps to level the load on subsequent processing. Even if there is a surge in access or processing delays, messages can be received in a queue, preventing the processing state from spreading to the entire application.

Social networking services (SNS) are push-based services. When a message is published to a topic, it is delivered to recipients who have subscribed to that topic. The SNS delivers the message to the recipients, rather than the recipient having to retrieve it themselves.

For a system that instantly notifies multiple recipients of an event, we use social media.

Message storage

SQS holds messages in a queue. Even if subsequent processing cannot be performed immediately, messages remain in the queue and can be retrieved when processing becomes possible.

For tasks that take a long time to process, such as image conversion, batch processing, and external API integration, using SQS as an intermediary can level out the load on subsequent processes.

SNS is not a service for storing and retrieving messages later. Its role is to deliver published messages to subscribers. If you want to ensure that messages are processed reliably on the receiving end, specify SQS as the delivery destination in SNS, and the messages will be stored on the SQS side.

Delivery destination

In SQS, applications and worker processes retrieve messages from the queue. AWS Lambda, processes on EC2, and applications on ECS process the messages held in SQS sequentially.

Social networking services (SNS) can deliver messages to multiple recipients. Typical recipients include email, SMS, AWS Lambda, SQS, and HTTP/S endpoints.

The criteria for choosing between them are clear. If you want to reliably pass the data to a single subsequent process, choose SQS; if you want to deliver the same event to multiple processes or notification destinations, choose SNS.

Order guarantee and duplicate handling

When using SQS and SNS, you need to consider order guarantees and how to handle duplicates separately.

SQS offers two types of queues: standard queues and FIFO queues. Standard queues are suitable for high-throughput processing, but the order of messages is not strictly guaranteed. Use FIFO queues when the processing order is critical.

SNS also has standard topics and FIFO topics. For event delivery where ordering is required, choose a configuration that combines SNS FIFO topics with SQS FIFO queues.

However, using FIFO does not eliminate the need for application-side duplicate processing countermeasures. Messaging is designed with retries and redelivery in case of failures in mind. On the receiving end, it is necessary to incorporate processing ID management and duplicate checks to ensure that business data does not become inconsistent even if the same message is processed multiple times.

Primary use cases

The differences in roles between SQS and SNS become clear when viewed through use cases. SQS is used when you want to reliably execute subsequent processing, while SNS is used when you want to distribute events or notifications to multiple recipients.

The main use cases for SQS are as follows:

• 画像変換
• Backend processing after order
• Log processing
• Batch Integration
• External system integration

Even if the processing volume temporarily increases, receiving messages with SQS helps to level out the load on subsequent processing.

The main use cases for social networking services (SNS) are as follows:

• Order completion notification
• Outage notification
• Mobile notifications
• Initiating AWS Lambda
• Event distribution to multiple systems

If you need to deliver the same event to multiple processes or notification recipients, use SNS.

In practice, configurations combining SQS and SNS are also used. By distributing events to multiple destinations via SNS and receiving each process via SQS, multiple subsequent processes can be executed independently.

Cases where SQS is used

SQS is used when you want to receive subsequent processing in a queue and execute it according to the processing capacity of the receiving end. Because it separates the incoming application from the subsequent processing, it can minimize the impact on the entire system even if there is a surge in access or a temporary increase in load.

SQS is effective for tasks that take a long time to process, such as external system integrations and batch processing, where immediate completion is not essential.

If you want to stabilize asynchronous processing

If all processes in a web application are executed synchronously, delays in subsequent processes directly impact the user experience. For example, a configuration where the screen is returned only after image upload, image conversion, virus checking, and thumbnail generation are all completed will result in longer processing times.

In this scenario, the application sends the necessary information to SQS, and subsequent processing retrieves and executes the message from the queue. This separates user-facing response processing from time-consuming backend processing, thus maintaining the responsiveness of the application itself.

SQS is not simply a service for delaying processing. It is used to separate the input and execution parts of processing, creating a configuration where delays or temporary failures in subsequent processing do not spread to the entire system.

If you want to absorb a sudden surge in processing volume

Campaigns, sales, notification distribution, and high traffic can cause a large volume of processing to occur in a short period of time. If processing is routed directly to subsequent systems for each request, it will concentrate the load on the database, external APIs, and batch processing infrastructure.

By using SQS, processes that occur can be temporarily held in a queue. Subsequent processes retrieve messages according to their own processing capacity, so the queue can absorb sudden increases in processing volume.

Order taking, email sending, inventory updates, and log aggregation don't always need to be completed immediately. Using SQS allows you to separate the load of entry-level processing from that of subsequent processing, maintaining the overall stability of the system.

If you want to execute subsequent processes in order

SQS is also a viable option when the order of subsequent processing is critical. In particular, if you need to maintain the order in which messages are processed, use an SQS FIFO queue.

For example, if the same order involves processes such as "order acceptance," "payment," "inventory update," and "shipping preparation," a disruption in the processing order can lead to data inconsistencies. In such cases, a configuration that processes messages in a sequential manner is necessary.

However, using SQS doesn't solve all processing order problems. Standard queues cannot guarantee strict order, so for processes where order is critical, it's necessary to use FIFO queues and also design consistency on the application side.

Cases where SNS is used

SNS is used when you want to distribute a message to multiple recipients. While SQS is a system that receives messages in a queue, SNS distributes messages published to a topic to subscribers.

Social networking services (SNS) are effective when a single event triggers multiple notifications and subsequent processes. They are used not only for notifying individuals but also as a mechanism for sharing events between systems.

If you want to notify multiple recipients

If you need to send the same message to multiple recipients, choose SNS. For example, when a failure occurs, you might send an email to the operations team, simultaneously triggering AWS Lambda to notify other systems as well.

In this configuration, the sender does not need to individually call each recipient. The sender publishes the message to an SNS topic, and SNS delivers it to its subscribers. Adding recipients can also be done without significantly changing the sender's implementation.

When communicating the same event to multiple systems, directly connecting the sender and receiver makes the configuration increasingly complex as the number of recipients increases. By using social networking services (SNS) as an intermediary, the event's source and receiver can be separated.

If you want to trigger a process based on an event

SNS is also used when triggering subsequent processes based on an event. For example, events such as order completion, file upload completion, and monitoring alert occurrence are sent to SNS, and the processes that receive these events are then executed.

SNS plays the role of distributing events as they occur. Configurations can be implemented such as executing processing using AWS Lambda upon receiving the event, or passing the message to SQS to asynchronously handle subsequent processing.

The key point is that SNS is not a place to store processing data, but a place to communicate events. SNS is used to communicate events to multiple processes, while SQS is used to receive subsequent processing in a queue; the roles are divided accordingly.

If you want to deliver via email, SMS, AWS Lambda, etc.

SNS supports multiple delivery destinations, including email, SMS, AWS Lambda, SQS, and HTTP/S endpoints. A key feature is its ability to handle both user notifications and system processing triggers from the same event.

For example, one possible configuration would involve notifying the responsible person via email when a failure is detected, triggering an automated recovery process using AWS Lambda, and passing a message to SQS to execute subsequent processing.

However, if you want to ensure that subsequent processing is handled reliably, you shouldn't rely solely on SNS. Specify SQS as the delivery destination, distribute the event via SNS, and store the message in SQS. By separating the roles of notification and queuing, you can achieve both delivery flexibility and processing stability.

Cases combining SQS and SNS

You don't necessarily have to choose one over the other. In practice, a common configuration is to distribute events via social media and use SQS as the distribution destination.

SNS distributes events to multiple recipients, while SQS holds messages until they are received by subsequent processing. By combining the two, a single event can be branched into multiple processes, each of which can be executed independently.

Fan-out configuration

A typical pattern for combining SQS and SNS is the fan-out configuration. Fan-out refers to a configuration where a single message is delivered to multiple recipients.

For example, you can publish an order completion event to an SNS topic and set up multiple SQS queues as destinations for that event.

• SQS queue for inventory updates
• SQS queue for sending emails
• SQS queue for analysis logs
• SQS queue for external system integration

In this configuration, multiple processes can run in parallel, starting from a single event: order completion. Since each process receives messages in a separate SQS queue, delays in email sending will not directly affect inventory updates or analysis log processing.

SNS alone can deliver messages to multiple recipients. However, if you want to control the timing of receiving messages and reprocessing at each stage, you should combine it with SQS. By delivering messages via SNS and receiving them with SQS, you can achieve both delivery flexibility and stability in subsequent processing.

Branching for multiple processes

The combination of SQS and SNS is also effective when triggering multiple processes from a single event. In configurations where the sender individually calls multiple subsequent processes, the implementation and operation become more complex as the number of processes increases.

By using SNS as an intermediary, the sender only needs to publish the message to the SNS topic. If you need to add further processing, add a new SQS queue as a subscriber for SNS.

For example, a system that initially only sends emails after an order is completed may later require the addition of inventory updates, CRM integration, and sales analysis. By combining SNS and SQS, you can add these processes without significantly changing the existing sending logic.

When branching multiple processes, the basic principle is to separate SQS queues according to their purpose, rather than receiving each process together in the same queue. Separating queues for each process allows you to design reprocessing, monitoring, and scaling individually in case of failure.

Combining notifications and queuing

Combining SNS and SQS allows you to separate the roles of notification and queuing. SNS delivers events, while SQS holds the messages until they are received by subsequent processing.

For example, one possible configuration involves issuing a fault detection event to SNS, notifying operations personnel via email, and simultaneously distributing a recovery message to SQS. In this case, SNS handles both the notification to people and the distribution to the system, while SQS acts as a receptacle to ensure that the recovery process reliably receives the message.

When dealing with a mix of processes that require immediate notification and processes that need to run reliably, use SNS and SQS together. By using SNS for notifications and SQS for holding and reprocessing subsequent data, you can create a configuration with clearly defined roles.

However, you don't need to use both in every configuration. If there's only one subsequent process and you just need to store and process the messages, SQS alone is sufficient. Choose the combination of SNS and SQS when you want to deliver to multiple destinations simultaneously or when you want separate queues for each process.

How to choose between SQS and SNS

The choice between SQS and SNS depends not on the service name, but on how messages are handled. The service you should choose depends on whether you need to retain messages until they are passed on to subsequent processing, or whether you need to distribute events to multiple recipients.

The criteria for judgment are as follows:

Criteria for choosing SQS

The criterion for choosing SQS is whether you want to hold messages in a state where subsequent processing can receive them. If processing needs to be queued and retrieved at the receiving end's timing, then choose SQS.

Image conversion, log processing, post-order backend processing, and external API integration don't always need to be completed immediately. By separating these processes from the main application, you can maintain responsiveness to the user while ensuring stable execution of subsequent processes.

SQS is also effective when a surge in access or processing volume is anticipated. Instead of sending requests directly to subsequent systems, accumulating them in SQS before processing allows the queue to absorb fluctuations in load.

The main criteria for choosing SQS are as follows:

• I want to temporarily hold off on processing.
• We want to level out the load on subsequent processing.
• I want to process it at the recipient's pace.
• I want to create a configuration that allows retries if the process fails.
• I want to consider the processing order.

If these requirements are met, SQS should be the first choice.

Criteria for choosing a social networking service (SNS)

The key criterion for choosing a social networking service (SNS) is whether you want to send a single message to multiple recipients. If you need to simultaneously notify multiple systems or recipients in response to an event, choose an SNS.

In some cases, email notifications, AWS Lambda function activations, and SQS integrations are triggered by events such as order completion, file upload completion, failure detection, and monitoring alerts. In these cases, it is simpler to publish a message to an SNS topic and distribute it to subscribers rather than having the sender individually call each recipient.

SNS is not a service for storing information for later processing. Its role is to deliver events and notifications to subscribers. If you want to retain messages for later processing, you should integrate SQS into your distribution destination, rather than using SNS alone.

The main criteria for choosing a social networking service (SNS) are as follows:

• I want to send the same message to multiple recipients.
• I want to be notified immediately when an event occurs.
• I want to inform people via email or SMS.
• I want to deliver data to multiple AWS services, such as AWS Lambda and SQS.
• We want to reduce the dependency between the sender and receiver.

If these requirements are met, consider using social media platforms.

Criteria for deciding whether to use SQS and SNS together

Using SQS and SNS together is ideal when you need to deliver messages to multiple destinations while ensuring stable processing for each. SNS delivers events, while SQS maintains separate message storage for each recipient. Combining the two allows for both delivery flexibility and processing stability.

For example, an order completion event might trigger inventory updates, email notifications, sales analysis, and integration with external systems. In this case, by distributing the event via social media and creating an SQS queue for each recipient, you can create an independent configuration for each process.

In this configuration, delays in email sending will not directly affect inventory updates or sales analysis. Retrying, monitoring, and scaling can be designed individually for each process.

The main criteria for deciding whether to use SQS and SNS together are as follows:

• I want to branch a single event into multiple processes.
• I want to have a separate queue for each process.
• We don't want delays in some subsequent processes to spill over into other processes.
• I want to trigger notifications and backend processing from the same event.
• I want a configuration that allows me to add distribution destinations and processing later.

If there is only one subsequent process, SQS alone may suffice. If you only need to notify multiple recipients simultaneously, SNS alone may suffice. Using both SQS and SNS is necessary when you want to simultaneously achieve event distribution and stable subsequent processing.

Common misconceptions about SQS and social media

SQS and SNS are both used for asynchronous processing and inter-system communication, so their roles are often confused. In particular, designing with the understanding that "SNS is for asynchronous processing," "SQS is fine for notifications," or "you don't have to worry about duplicate processing with FIFO" will result in insufficient measures against delays in subsequent processing, duplicate processing, and missed deliveries.

Here, we'll clarify some common misconceptions to be aware of when choosing between SQS and SNS.

Asynchronous processing isn't limited to social media.

Even when implementing asynchronous processing, you don't necessarily have to use social networking services (SNS). SNS are services that deliver events and messages to subscribers. If you want to queue subsequent processing and have the recipient process it at their own timing, you would choose SQS.

For example, image conversion, log processing, and backend processing after an order is often more stable when queued and processed sequentially rather than executed immediately. In these cases, using SQS allows you to control the load and timing of subsequent processing.

On the other hand, if you need to notify multiple recipients of events such as order completion or system failures, social media (SNS) is a viable option. Don't judge solely based on the term "asynchronous processing"; you need to distinguish between wanting to retain the message and wanting to distribute it to multiple recipients.

SQS is not suitable if you only need notifications.

SQS is a queue service for holding messages, not a service for delivering notifications to multiple destinations. To deliver the same message to email, SMS, AWS Lambda, SQS, etc., you should use SNS.

In SQS, the receiving end retrieves the message from the queue. Therefore, it is not suitable for sending notifications to multiple recipients simultaneously. The more recipients there are, the more complex the design becomes for both the sending and processing sides.

For example, if you need to send an email to operations personnel in the event of a failure, simultaneously trigger an AWS Lambda function, and coordinate with other systems, a configuration that distributes the information from an SNS topic to each recipient is suitable. SQS is used as one of the distribution destinations to reliably handle subsequent processing.

Even with FIFO, consideration for duplicate processing is necessary.

SQS and SNS have mechanisms that support FIFO. FIFO is effective for handling message order and duplicate removal, but it is dangerous to think that "you don't have to think about duplicate processing at all if you use FIFO."

Messaging-based designs assume network failures, processing errors, and retries. If the receiving end fails to process the message midway, it may need to process the same message again. Therefore, the application must be designed to avoid inconsistencies even if it receives the same message multiple times.

In processes where duplicate execution is a problem, such as order processing and payment integration, managing processed IDs and ensuring idempotency are essential. While FIFO (First-In, First-Out) supports ordering and duplicate removal, it does not automatically guarantee the integrity of business data. It is necessary to consider not only the functionality of SQS or SNS, but also the reprocessing design on the application side.

Summary

Amazon SQS and Amazon SNS are both AWS messaging services, but their design roles are different. SQS holds messages in a queue and retrieves them when further processing is needed. SNS distributes messages published to a topic to multiple subscribers.

SQS is used when you want to stabilize asynchronous processing or absorb sudden spikes in processing volume. SNS is used when you want to distribute a single event to multiple destinations. Furthermore, by distributing an event via SNS and receiving it in an SQS queue for each destination, multiple subsequent processes can be executed independently.

If you're unsure whether to use SQS or SNS, determine whether you want to retain the message or send it to multiple recipients. Use SQS if you want stable subsequent processing, SNS if you want to communicate the event to multiple recipients, or consider using both SQS and SNS to achieve both stable delivery and processing.