SNSとSQSをいつ使用するのかわからないのですが、なぜそれらは常に一緒に結合されているのですか？
回答:
SNSは、分散パブリッシュ/サブスクライブシステムです。メッセージは、パブリッシャーからSNSに送信されたときにサブスクライバーにプッシュされます。
SQSは分散キューイングシステムです。メッセージは受信者にプッシュされません。受信者はSQSからメッセージをポーリングまたはプルする必要があります。メッセージを複数の受信者が同時に受信することはできません。1人の受信者がメッセージを受信し、処理して削除できます。他の受信者は後で同じメッセージを受信しません。ポーリングでは、メッセージがすぐにサブスクライバーにプッシュされるSNSとは異なり、SQSでのメッセージ配信に遅延が発生します。SNSは、電子メール、SMS、HTTPエンドポイント、SQSなどのいくつかのエンドポイントをサポートしています。不明な数とタイプのサブスクライバーがメッセージを受信できるようにするには、SNSが必要です。
SNSとSQSを常に結合する必要はありません。SQSとは別に、SNSにメッセージを電子メール、SMS、またはHTTPエンドポイントに送信させることができます。SNSをSQSと結合することには利点があります。外部サービスがホストに接続することを望まない場合があります（ファイアウォールが外部からのホストへのすべての着信接続をブロックする場合があります）。大量のメッセージが原因で、エンドポイントが停止する可能性があります。電子メールとSMSは、メッセージを迅速に処理するというあなたの選択ではないかもしれません。SNSとSQSを組み合わせると、自分のペースでメッセージを受信できます。これにより、クライアントはオフラインになり、ネットワークとホストの障害に耐えることができます。また、保証付き配達も実現します。メッセージをhttpエンドポイント、電子メール、またはSMSに送信するようにSNSを構成した場合、メッセージの送信にいくつか失敗すると、メッセージがドロップされる可能性があります。
SQSは主にアプリケーションの分離またはアプリケーションの統合に使用されます。メッセージは、短い期間（最大14日間）SQSに保存できます。SNSは、メッセージの複数のコピーを複数のサブスクライバーに配布します。たとえば、アプリケーションによって生成されたデータを複数のストレージシステムに複製するとします。SNSを使用してこのデータを複数のサブスクライバーに送信し、それぞれが受信したメッセージをさまざまなストレージシステム（s3、ホストのハードディスク、データベースなど）に複製できます。
2つの比較を以下に示します。
エンティティタイプ
メッセージの消費
使用事例
持続性
消費者タイプ
サンプルアプリケーション
aws docから：
Amazon SNSを使用すると、アプリケーションはタイムクリティカルなメッセージを「プッシュ」メカニズムを介して複数のサブスクライバーに送信できるため、更新を定期的にチェックまたは「ポーリング」する必要がなくなります。
Amazon SQSは、ポーリングモデルを介してメッセージを交換するために分散アプリケーションによって使用されるメッセージキューサービスであり、各コンポーネントを同時に使用可能にする必要なく、送信コンポーネントと受信コンポーネントを分離するために使用できます。
http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html
AWS SNSはパブリッシャーサブスクライバーネットワークであり、サブスクライバーはトピックにサブスクライブでき、パブリッシャーがそのトピックにパブリッシュするたびにメッセージを受信します。
AWS SQSは、キューにメッセージを格納するキューサービスです。SQSはメッセージを配信できません。SQSをポーリングしてSQSからメッセージを取得するには、外部サービス（lambda、EC2など）が必要です。
SNSとSQSは、いくつかの理由で一緒に使用できます。
一部のサブスクライバには、メッセージをすぐに配信する必要がある場合と、ポーリングで後で使用するためにメッセージを保持する必要がある場合があります。このリンクを参照してください。
「ファンアウトパターン」。これは、メッセージの非同期処理用です。メッセージがSNSにパブリッシュされると、メッセージを複数のSQSキューに並行して配信できます。これは、画像が公開されているときに、アプリケーションでサムネイルを並行してロードする場合に最適です。このリンクを参照してください。
永続的なストレージ。メッセージを処理するサービスが信頼できない場合。このような場合、SNSがサービスに通知をプッシュし、そのサービスが利用できない場合、通知は失われます。したがって、SQSを永続ストレージとして使用し、後で処理することができます。
このスレッドの答えは少し古いので、2セント追加することにしました。
SNSは、複数のサブスクライバーを持つことができる従来のトピックとして見ることができます。たとえば、LambdaやSQSなど、1つの特定のSNSトピックの異種サブスクライバーを持つことができます。SNSを使用して、SMSメッセージや電子メールを送信することもできます。SNSで考慮すべきことの1つは、一度に受信されるメッセージ（通知）が1つだけであるため、バッチ処理を利用できないことです。
一方、SQSはQueueにすぎず、メッセージを格納して1つのコンシューマーをサブスクライブします（そうです、1つのSQSキューにN個のコンシューマーを持つことができますが、乱雑になり、すべてのコンシューマーを考慮して管理するのがはるかに難しくなります。はメッセージを少なくとも1回は読み取る必要があるため、SNSとSQSを組み合わせてこのユースケースを使用する方がよいでしょう。この場合、SNSは通知をN個のSQSキューにプッシュし、すべてのキューには1人のサブスクライバーのみがこれらのメッセージを処理します。2018年6月28日の時点で、AWSはLambda Triggers for SQSをサポートしています。つまり、ポーリングする必要はありません。メッセージのためにもう。さらに、障害が発生した場合にメッセージを送信するようにソースSQSキューにDLQを構成できます。成功した場合、メッセージは自動的に削除されます（これはもう1つの大きな改善です）。手動で削除するのを忘れた場合に、すでに処理されたメッセージが再度読み取られることを心配する必要はありません。ラムダの再試行動作を確認することをお勧めしますそれがどのように機能するかをよりよく理解するために。SQSを使用する大きな利点の1つは、バッチ処理が可能になることです。各バッチには最大10個のメッセージを含めることができるため、SQSキューに一度に100個のメッセージが到着すると、10個のLambda関数がスピンアップし（Lambdaのデフォルトの自動スケーリング動作を考慮）、これらの100個のメッセージを処理します（保持実際にはこれがハッピーパスであることに注意してください。実際には、さらにいくつかのLambda関数がバッチ内の10個未満のメッセージを読み取ってスピンアップする可能性があります。ただし、同じ100個のメッセージをSNSに投稿した場合、100個のLambda関数が起動し、不必要にコストが増加し、Lambdaの同時実行性が使い果たされます。ただし、従来のサーバー（EC2インスタンスなど）をまだ実行している場合でも、メッセージをポーリングして手動で管理する必要があります。
また、メッセージの配信順序を保証するFIFO SQSキューもあります。これはLambdaでサポートされているトリガーではないため、このタイプのキューを選択する場合は、ポーリングが依然として必要であり、メッセージを手動で削除する必要があることに注意してください。
ユースケースにはいくつかのオーバーラップがありますが、SQSとSNSの両方に独自のスポットライトがあります。
次の場合はSNSを使用します。
次の場合はSQSを使用します。
簡単に言えば、SNS-プッシュメカニズムを使用してサブスクライバーにメッセージを送信し、プルする必要はありません。SQS-分散アプリケーションがポーリングモデルを介してメッセージを交換するために使用するメッセージキューサービスであり、送信コンポーネントと受信コンポーネントを分離するために使用できます。
一般的なパターンは、SNSを使用してメッセージをAmazon SQSキューに発行し、1つ以上のシステムコンポーネントに非同期でメッセージを確実に送信することです。https://aws.amazon.com/sns/faqs/からの参照
visibilityTimeoutが設定されている場合、他のシステムで処理されると、他のどのシステムもメッセージを消費できなくなります。