SNSは分散型publish-subscribeシステムです。メッセージは、パブリッシャからSNSに送信されるときと同じように、サブスクライバにプッシュされます。
SQSは配布されていますキューイングシステム。メッセージは受信者にプッシュされません。受信者はポーリングまたはプルからのメッセージをSQSにする必要があります。メッセージを複数の受信者が同時に受信することはできません。どの受信者もメッセージを受信し、それを処理して削除できます。他の受信者は後で同じメッセージを受信しません。メッセージが即時に加入者にプッシュされるSNSとは異なり、ポーリングは本質的にSQSのメッセージ配信に遅延をもたらします。 SNSは電子メール、SMS、httpエンドポイント、SQSなどのいくつかのエンドポイントをサポートします。未知の数と種類の購読者にメッセージを受信させたい場合は、SNSが必要です。
SNSとSQSを常に組み合わせる必要はありません。 SQSとは別に、SNSにメッセージを電子メール、SMS、またはHTTPエンドポイントに送信させることができます。 ＳＮＳをＳＱＳと結合することには利点がある。あなたは外部サービスがあなたのホストに接続することを望まないかもしれません（ファイアウォールは外部からあなたのホストへのすべての入って来る接続をブロックするかもしれません）。あなたのエンドポイントは大量のメッセージのためにちょうど死ぬかもしれません。電子メールとSMSは、メッセージを迅速に処理するための選択ではないかもしれません。 SNSとSQSを組み合わせることで、自分のペースでメッセージを受信できます。これにより、クライアントはオフラインになり、ネットワークやホストの障害に耐えることができます。あなたは保証された配達も達成します。 httpエンドポイント、電子メール、またはSMSにメッセージを送信するようにSNSを設定した場合、メッセージの送信に失敗するとメッセージが破棄されることがあります。
SQSは主にアプリケーションの分離やアプリケーションの統合に使用されます。メッセージは短期間（最大14日間）SQSに保存できます。 SNSはメッセージの複数のコピーを複数の加入者に配布します。たとえば、アプリケーションによって生成されたデータを複数のストレージシステムに複製したいとします。 SNSを使用してこのデータを複数の加入者に送信し、それぞれが受信したメッセージをさまざまなストレージシステム（s3、ホスト上のハードディスク、データベースなど）に複製することができます。
これが2つの比較です。
エンティティタイプ
- SQS：キュー（JMSと同様）
- SNS：トピック（Pub/Subシステム）
メッセージ消費
- SQS：プルメカニズム - コンシューマはSQSからメッセージをポーリングしてプルします
- SNS：プッシュメカニズム - SNSはメッセージをコンシューマにプッシュします
ユースケース
- SQS：2つのアプリケーションを分離して並列非同期処理を可能にする
- SNS：Fanout - 同じメッセージを複数の方法で処理する
持続性
- SQS：利用可能なコンシューマがない場合、メッセージは一定の（設定可能な）期間保持されます
- SNS：永続性はありません。メッセージ到着時にどちらのコンシューマが存在していてもメッセージを受信し、メッセージは削除されます。利用可能なコンシューマがない場合、メッセージは失われます。
消費者タイプ
- SQS：すべてのコンシューマは同一であるため、まったく同じ方法でメッセージを処理します。
- SNS：消費者はさまざまな方法でメッセージを処理する可能性があります
サンプルアプリケーション
- SQS：Jobs framework：ジョブはSQSに送信され、反対側の消費者はジョブを非同期に処理できます。仕事の頻度が増えれば、消費者の数を増やしてスループットを向上させることができます。
- SNS：画像処理誰かが画像をS3にアップロードしてからその画像に透かしを入れる場合は、サムネイルを作成して、ありがとうのメールも送ってください。その場合、S3は3人の消費者がそれを聞いているSNSトピックに通知を発行できます。 1人目が画像に透かしを入れ、2人目がサムネイルを作成し、3人目がThank You Eメールを送信します。それらはすべて同じメッセージ（画像URL）を受け取り、それらの処理を並行して行います。
Awsのドキュメントから：
Amazon SNSでは、アプリケーションは「プッシュ」メカニズムを介してタイムクリティカルなメッセージを複数のサブスクライバに送信できるため、定期的に更新を確認または「ポーリング」する必要がなくなります。
Amazon SQSは、ポーリングモデルを介してメッセージを交換するために分散アプリケーションで使用されるメッセージキューサービスです。各コンポーネントを同時に使用可能にすることなく、送受信コンポーネントを分離するために使用できます。
http://docs.aws.Amazon.com/sns/latest/dg/SendMessageToSQS.html
AWS SNSは、発行者購読者ネットワークで、購読者はトピックを購読でき、発行者がそのトピックを発行するたびにメッセージを受信します。
AWS SQSはキューサービスで、メッセージをキューに格納します。 SQSはメッセージを配信できません。SQSをポーリングしてSQSからメッセージを取得するには、外部サービス（ラムダ、EC2など）が必要です。
SNSとSQSは、さまざまな理由で一緒に使用できます。
後でポーリングを介して使用するために、一部のユーザがメッセージの即時配信を必要とし、一部のユーザがメッセージの存続を必要とするさまざまな種類のユーザが存在する場合があります。これを参照してください link 。
「ファンアウトパターン」これはメッセージの非同期処理用です。メッセージがSNSに発行されると、メッセージを複数のSQSキューに同時に配布できます。これは、画像が公開されているときに、サムネイルをアプリケーションに並行して読み込むときに便利です。これを参照してください link 。
固定記憶域。メッセージを処理しようとしているサービスが信頼できないとき。このような場合、SNSが通知をサービスにプッシュし、そのサービスが利用できないと、通知は失われます。したがって、SQSを永続ストレージとして使用し、その後それを処理することができます。
このスレッドに関する回答は少し古くなっているので、2セント追加することにしました。
あなたはSNSをあなたが複数の購読者を持つことができる伝統的なトピックとして見ることができます。たとえば、LambdaやSQSなど、1つの特定のSNSトピックに対して異種のサブスクライバを持つことができます。 SNSを使用して、SMSメッセージを送信したり、箱から出して電子メールを送信することもできます。 SNSで考慮すべきことの1つは、一度に1つのメッセージ（通知）しか受信されないため、バッチ処理を利用することはできません。
SQSは、一方で、メッセージを保存して1人のコンシューマを購読するQueueに他なりません（はい、N人のコンシューマを持つことができます）。 SQSキューは1つですが、すべてのコンシューマが少なくとも1回メッセージを読む必要があることを考えると、非常に早く手間がかかり管理が困難になるため、SNSがSQSと組み合わせてSNSに通知をプッシュするほうが賢明です。 Ｎ個のＳＱＳ待ち行列および各待ち行列は、これらのメッセージを処理するためにただ１人の加入者を有するであろう。 2018年6月28日現在、 AWSはSQS のLambdaトリガーをサポートしています。つまり、投票する必要はありませんもうメッセージ用。さらに、失敗した場合にメッセージを送信するようにソースSQSキューにDLQを構成できます。成功した場合、メッセージは自動的に削除されるので（これはもう1つの大きな改善です）、手動で削除するのを忘れた場合に既に処理済みのメッセージが再度読み込まれることを心配する必要はありません。それがどのように機能するかをよりよく理解するために、 Lambda Retry Behavior を見ることをお勧めします。 SQSを使用することの大きな利点の1つは、バッチ処理が可能になることです。各バッチには最大10個のメッセージを含めることができます。したがって、SQSキューに100個のメッセージが同時に到着すると、10個のLambda関数が起動し（Lambdaのデフォルトの自動スケーリング動作を考慮）、これらの100個のメッセージが処理されます。これが実際には幸せな道だということを心に留めておいてください、もっと多くのLambda関数がバッチで10メッセージ以下を読むことをスピンアップするかもしれません、しかしあなたは考えを得ます）。しかし、これと同じ100個のメッセージをSNSに投稿すると、100個のLambda関数がスピンアップし、不必要にコストが増加し、Lambdaの同時実行性が使い果たされることになります。ただし、従来のサーバー（EC2インスタンスなど）をまだ実行している場合は、メッセージをポーリングして手動で管理する必要があります。
また、メッセージの配信順序を保証するFIFO SQSキューもあります。これはLambdaによるサポートされたトリガーではありません、従ってこのタイプのキューを選択するとき、手動でメッセージを削除しなければならないと同時にポーリングがまだ必要であることに留意して下さい。
ユースケースには重複がありますが、SQSとSNSの両方に独自のスポットライトがあります。
次の場合は、SNSを使用してください。
- 複数の加入者が必要条件です
- 箱から出してSMS/Eメールを送信すると便利です
次の場合は、SQSを使用してください。
- 必要な加入者は1人だけです
- バッチ処理は重要です
簡単に言うと、SNS - プッシュメカニズムを使用してプルを必要とせずにメッセージを加入者に送信します。 SQS - ポーリングモデルを介してメッセージを交換するために分散アプリケーションで使用されるメッセージキューサービスで、送受信コンポーネントを分離するために使用できます。
一般的なパターンは、SNSを使用してメッセージをAmazon SQSキューにパブリッシュし、メッセージを1つ以上のシステムコンポーネントに非同期的に確実に送信することです。 https://aws.Amazon.com/sns/faqs/ からの参照