AWS SNS vs SQS完全比較｜メッセージング方式の違いと現場での使い分けガイド

SNSとSQSのどちらを使えばいいか、調べても調べても「状況による」という答えばかりで、結局どっちを選べばいいか分からない——そう悩んだことはありませんか。

AWSでイベント駆動型の設計をしようとすると、必ずといっていいほど直面するのがこの問いです。オンプレの世界では、アプリ間の連携はAPIコールやDBのポーリングで済んでいたかもしれません。しかしクラウドで非同期処理やマイクロサービスを構築するとなると、メッセージングサービスの選択が設計の根幹を左右します。

この記事では、Amazon SNSとAmazon SQSをオンプレ経験者にも分かりやすく比較し、どんなシナリオでどちらを選ぶべきか、組み合わせて使う方法まで体系的に解説します。

Amazon SNSとAmazon SQSの基本概念
1. Amazon SNS（Simple Notification Service）とは
2. Amazon SQS（Simple Queue Service）とは
SNS vs SQS：7つの違いを一覧比較
いつSNSを使い、いつSQSを使うべきか
1. Amazon SNSが向いているシナリオ
2. Amazon SQSが向いているシナリオ
ファンアウトパターン：SNS＋SQSを組み合わせて使う
SQSのFIFOキューとSNSのFIFOトピック
料金の仕組み（コスト感覚）
現場でハマりがちなポイント
よくある質問（FAQ）
本記事のまとめ
1. クラウドの非同期設計、次は実践で身につけませんか？

Amazon SNSとAmazon SQSの基本概念

まず「そもそも何者か」を整理しておきましょう。名前が似ているため混同しがちですが、役割は全く異なります。

Amazon SNS（Simple Notification Service）とは

Amazon SNSは、プッシュ型のメッセージング・通知サービスです。「トピック」と呼ばれる仮想的なチャンネルにメッセージを投げると、そのトピックを購読（サブスクライブ）している宛先すべてに、一斉にメッセージが配信されます。

・配信形式: プッシュ（送信側が主体的に配信）
・配信先（サブスクライバー）: SQSキュー、Lambda、HTTP/HTTPS、メールアドレス、SMS、モバイルプッシュ通知
・メッセージの保持: 配信後は保持しない（配信失敗時は再試行ポリシーに従う）
・代表的なユースケース: アラート通知、イベントのファンアウト配信、モバイルプッシュ

オンプレのアナロジーで言うと、「社内の一斉メール配信システム」に近いイメージです。1通のメールをトピックに送ると、登録者全員の受信箱に届く——そういう動きをします。

Amazon SQS（Simple Queue Service）とは

Amazon SQSは、プル型のメッセージキューサービスです。送信側がキューにメッセージを入れておき、受信側が自分のペースでメッセージを取り出す（ポーリングする）仕組みです。

・配信形式: プル（受信側が主体的に取り出す）
・配信先: キューにアクセスするコンシューマー（EC2、Lambda、ECS等）
・メッセージの保持: コンシューマーが取り出すまで最大14日間保持
・代表的なユースケース: 非同期ジョブ処理、バッファリング、マイクロサービス間の疎結合

オンプレのアナロジーで言えば、「社内の共有チケットシステム」です。誰かがチケットを登録しておき、担当者が空いたタイミングで取り出して処理する——そういう動きをします。

SNS vs SQS：7つの違いを一覧比較

両サービスの違いを整理すると、次のようになります。

比較ポイント	Amazon SNS	Amazon SQS
配信モデル	プッシュ型（Pub/Sub）	プル型（キュー）
受信者数	複数（1対多）	原則1（1対1）
メッセージ保持	保持しない	最大14日間保持
受信側の動作	即時プッシュ	ポーリングで取得
順序保証	保証なし（FIFOトピックで保証）	標準キューは保証なし（FIFOキューで保証）
重複配信	可能性あり	標準キューで可能性あり（FIFOキューで排除）
主な用途	通知・イベント一斉配信	非同期ジョブ・処理バッファ

いつSNSを使い、いつSQSを使うべきか

「結局どっちを使えばいいの？」という疑問に正面から答えます。

Amazon SNSが向いているシナリオ

複数のシステムに同じイベントを同時に届けたい場合がSNSの本領です。

例えば「注文が完了したら、在庫システム・請求システム・通知システムの3つに同時に知らせる」という要件があるとします。SNSのトピックに「注文完了」メッセージを1回投げるだけで、3つのサブスクライバーに自動的に配信されます。送信元は宛先を意識する必要がありません。

・EC2障害アラートをOpsチームのSlack・PagerDuty・メールに同時送信したい
・新規ユーザー登録時に、ウェルカムメール・CRM登録・分析DBへの書き込みを並行実行したい
・モバイルアプリにプッシュ通知を送りたい（iOS/Androidを問わず）

Amazon SQSが向いているシナリオ

処理速度が違うシステム間のバッファとして使いたい場合がSQSの出番です。

例えば画像アップロードサービスを考えます。ユーザーが大量に画像をアップロードすると、バックエンドのサムネイル生成処理が追いつかなくなります。SQSをバッファに挟むことで、アップロードAPI側はキューに入れるだけで即時レスポンスを返せ、サムネイル生成ワーカーは自分のペースで処理できます。

・APIのリクエストを受け付けて、重い処理は非同期で行いたい（即時レスポンスを確保したい）
・バッチ処理のジョブを溜めておいて、夜間に処理したい
・コンシューマーがダウンしても、メッセージをロストしたくない（最大14日間の保持）
・マイクロサービス間を疎結合にして、障害が連鎖しないようにしたい

ファンアウトパターン：SNS＋SQSを組み合わせて使う

実務でよく使われるのが、SNSとSQSを組み合わせた「ファンアウトパターン」です。

SNSだけを使うと、配信先（LambdaやHTTPエンドポイント）が瞬間的に大量のメッセージを処理しきれない場合に問題が起きます。そこでSNSの配信先をSQSキューにすることで、メッセージをバッファリングしながら複数のシステムに届けられます。

設計イメージは次のとおりです。

# ファンアウトパターンの構成例注文完了イベント │ ▼ SNSトピック（注文完了） ├── SQSキュー（在庫更新ワーカー向け） ├── SQSキュー（請求処理ワーカー向け） └── SQSキュー（通知ワーカー向け） # SNS → SQS のサブスクリプション設定（AWS CLIの例） aws sns subscribe \ --topic-arn arn:aws:sns:ap-northeast-1:123456789012:order-completed \ --protocol sqs \ --notification-endpoint arn:aws:sqs:ap-northeast-1:123456789012:inventory-queue

このパターンの利点は3つです。

・イベントの一斉配信（SNSの強み）: 1つのSNSトピックに送るだけで複数キューに配信される
・処理速度の分離（SQSの強み）: 各ワーカーが自分のペースでキューから取り出して処理できる
・耐障害性の向上: 一部のワーカーがダウンしても、メッセージはSQSに保持されるのでロストしない

Eコマースや金融系のシステムで特に多用される設計パターンです。

SQSのFIFOキューとSNSのFIFOトピック

標準のSQSキューは処理順序が保証されません。これが問題になるケースがあります。例えば「口座残高を増やす処理」と「残高を減らす処理」が順序逆転すると、残高がマイナスになる可能性があります。

そのような場合はFIFOキュー（First In, First Out）を使います。

比較ポイント	標準キュー	FIFOキュー
順序保証	なし（ベストエフォート）	あり（厳密なFIFO）
重複排除	なし（少なくとも1回配信）	あり（厳密に1回配信）
スループット	無制限	300 TPS（バッチで最大3,000 TPS）
命名規則	任意	.fifo サフィックスが必須
料金	低コスト	標準の約2倍

FIFOキューを使う場合は、メッセージにMessageGroupIdを付与する必要があります。同じグループ内ではFIFO順が保証されます。

# FIFOキューにメッセージを送信する（AWS CLIの例） # キュー名は必ず .fifo で終わる必要がある aws sqs send-message \ --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/payment-queue.fifo \ --message-body '{"action": "debit", "amount": 1000}' \ --message-group-id "account-12345" \ --message-deduplication-id "txn-abc-001"

料金の仕組み（コスト感覚）

どちらも月間100万リクエストまで無料で使えます（AWS無料利用枠）。

Amazon SNS の料金（2026年3月時点、東京リージョン）

・APIリクエスト: 最初の100万回/月は無料、以降$0.50 / 100万リクエスト
・SQSへの配信: 無料
・HTTPへの配信: 100万回以降$0.60 / 100万回
・SMSへの配信: 国によって異なる（日本向けは$0.07〜 / 通）
・モバイルプッシュ: 最初の100万通/月は無料、以降$0.50 / 100万通

Amazon SQS の料金（2026年3月時点、東京リージョン）

・標準キュー: 最初の100万リクエスト/月は無料、以降$0.40 / 100万リクエスト
・FIFOキュー: 最初の100万リクエスト/月は無料、以降$0.50 / 100万リクエスト
・データ転送: 同一リージョン内の転送は無料

注意点として、SQSはロングポーリングを使わずにポーリング頻度を高めると、APIリクエスト数が増えてコストが膨らみます。ロングポーリング（WaitTimeSeconds=20）を設定することで、空振りのポーリングを減らしコストを抑えられます。

現場でハマりがちなポイント

1. SNSからSQSへの配信はキューのアクセスポリシー設定が必要

SNSがSQSキューにメッセージを送るには、SQSキューのリソースポリシーでSNSからの送信を許可する必要があります。コンソールでサブスクリプションを作成すれば自動設定されますが、TerraformやCloudFormationで手動構築する場合は漏れやすいポイントです。

2. SQSの可視性タイムアウトとLambdaの実行タイムアウト

LambdaがSQSをトリガーとして処理する場合、Lambdaの実行タイムアウトよりもSQSの可視性タイムアウトを長く設定する必要があります。Lambdaのタイムアウトが可視性タイムアウト内で完了しない場合、同じメッセージが別のLambdaインスタンスに再配信されてしまいます。

推奨設定：可視性タイムアウト = Lambdaの最大実行時間 × 6

3. デッドレターキュー（DLQ）を設定しないと処理失敗メッセージが消える

SQSで処理に失敗したメッセージは、最大受信回数を超えるとキューから削除されます。DLQ（Dead Letter Queue）を設定しておくと、失敗したメッセージをDLQに移動して後から原因調査ができます。本番環境では必ず設定しましょう。

# DLQを設定したSQSキューの作成例（AWS CLIの例） # まずDLQ自体を作成 aws sqs create-queue --queue-name order-processing-dlq # 次にメインキューにDLQを紐付ける（最大受信数3回） aws sqs set-queue-attributes \ --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/order-processing \ --attributes '{ "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:ap-northeast-1:123456789012:order-processing-dlq\",\"maxReceiveCount\":\"3\"}" }'

4. SNSからHTTPエンドポイントへ配信する場合、サブスクリプション確認が必要

SNSからHTTPS/HTTPのエンドポイントにサブスクリプションを作成した直後、エンドポイントには確認リクエスト（SubscribeURL付き）が送られます。エンドポイント側でこのURLにGETリクエストを投げて確認しないと、サブスクリプションが有効化されません。テスト環境での初期設定でよく詰まるポイントです。

よくある質問（FAQ）

Q: SNSでSQS以外に何を購読できますか？
A: Lambda、HTTP/HTTPS、メールアドレス、SMS、Amazon Kinesis Data Firehoseをサブスクライバーとして設定できます。モバイルプッシュ通知（APNs/FCM）にも対応しています。

Q: SQSはサーバーレス環境（Lambda）で使えますか？
A: はい。SQSをLambdaのイベントソースマッピングに設定することで、キューにメッセージが入ると自動でLambdaが起動します。この場合、LambdaがSQSのポーリングを内部的に行うため、コンシューマー側のポーリングコードを書く必要がありません。

Q: SQSメッセージの最大サイズはいくつですか？
A: 1メッセージあたり最大256KBです。それ以上のデータを送る場合は、実データをS3に保存してSQSにはS3のパスだけを送る「S3ポインター」パターンを使います。

Q: SNSでメッセージフィルタリングはできますか？
A: できます。サブスクリプションフィルターポリシーを設定することで、特定の属性を持つメッセージだけを特定のサブスクライバーに配信できます。例えば「region=tokyo」の属性があるメッセージだけを東京担当のSQSキューに届けるといった使い方ができます。

Q: オンプレのRabbitMQやActiveMQをAWSに移行する際、SQSに置き換えられますか？
A: 移行先としてAmazon MQも検討してください。Amazon MQはRabbitMQとActiveMQのマネージドサービスで、既存のメッセージングコードを最小限の変更で移行できます。SQSはAPIが異なるため、既存コードの修正が必要です。

本記事のまとめ

・SNS（プッシュ型）: 1つのイベントを複数のシステムに同時通知したいとき
・SQS（プル型）: 非同期処理のバッファとして、受信側のペースで消化させたいとき
・SNS＋SQSのファンアウトパターン: 複数システムへの配信＋バッファリングが同時に必要なとき
・FIFOキュー: 処理順序と重複排除が必須なとき（スループットの上限に注意）
・DLQは本番必須: 処理失敗メッセージのロストを防ぐためにDLQは常に設定する

オンプレではアプリ間の連携に専用のメッセージングミドルウェアを自前で立てる必要がありましたが、AWSではSNSとSQSを組み合わせることで、フルマネージドなメッセージングインフラを数分で構築できます。

設計の第一歩として「受信側が複数か1つか」「メッセージをバッファリングする必要があるか」の2点を確認すると、SNSかSQSかの選択がスムーズになります。

Linuxサーバー上でPythonやJavaを使ったメッセージングの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。