Amazon SQS / SNS
Simple Queue Service / Simple Notification Service
概要
Amazon SQS と SNS は、コンポーネント同士を疎結合にするためのフルマネージドなメッセージングサービスです。SQS はメッセージを一時的に蓄えるキューで、送信側（プロデューサー）と受信側（コンシューマー）の処理速度の差を吸収し、ピーク負荷をバッファリングします。SNS は Pub/Sub 型の通知サービスで、1つのメッセージを複数の購読者へ同時に配信（ファンアウト）します。両者を組み合わせることで、障害に強く、独立してスケールできるイベント駆動アーキテクチャを構築できます。
主要な概念
SQS の基本動作
SQS は送信されたメッセージをキューに保持し、コンシューマーがポーリングして取得・処理します。コンシューマーが処理に失敗してもメッセージはキューに残り、可視性タイムアウトの経過後に再度取得できるため、取りこぼしを防げます。処理が成功したら明示的に削除します。受信側が落ちている間も蓄積されるため、急増トラフィックの緩衝材になります。
標準キューとFIFOキュー
標準キューは非常に高いスループットを持ちますが、配信順序は保証されず、まれに重複配信が起こり得る（少なくとも1回配信）ため、冪等な処理設計が前提です。FIFO キューは順序保証と重複排除（正確に1回処理）を提供し、順序や重複の制御が重要な処理に向きますが、スループットには上限があります。
SNS のファンアウト
SNS はトピックに発行された1件のメッセージを、購読しているすべてのエンドポイントへ一斉配信します。購読先には複数の SQS キュー、Lambda、HTTP/S、Eメール、SMS などを指定できます。「SNS → 複数 SQS」のファンアウト構成にすると、1つのイベントを複数の処理系へ確実に届けつつ、各処理系を独立してスケール・再試行させられます。
デッドレターキュー（DLQ）
一定回数処理に失敗したメッセージを退避させる専用キューがデッドレターキューです。問題のあるメッセージが延々と再処理されてキューを詰まらせるのを防ぎ、後から原因を調査・再投入できます。信頼性の高いメッセージ処理パイプラインを設計する上で重要な仕組みです。
疎結合と適材適所
バッファリングしてワーカーが自分のペースで処理する「ジョブキュー」用途には SQS、1つのイベントを複数システムへ通知する「Pub/Sub」用途には SNS が適します。リアルタイムなストリーム集計や順序付き大量データには Kinesis が向くなど、要件によって使い分けます。同期HTTP直結より、これらで非同期化する方がスケールと耐障害性に優れます。
典型的なユースケース
- Webリクエストと重い後続処理をSQSで疎結合にし、急増負荷をバッファリングする
- SNS → 複数SQSのファンアウトで1イベントを複数の処理系へ確実に配信する
- FIFOキューで注文処理など順序と重複排除が重要なワークフローを実装する
- デッドレターキューで処理失敗メッセージを退避し、後から調査・再投入する
- SNSでシステムアラートをEメールやSMS、Lambdaなど複数チャネルへ一斉通知する
試験での出題観点
SQS / SNS は SAA・DVA でアプリケーション統合の中心として頻出します。「コンポーネントを疎結合にしたい」「急増トラフィックをバッファして取りこぼしを防ぎたい」という設問はSQSが鉄板の正解です。「1つのイベントを複数の処理系へ同時配信」ならSNS、「確実に届けつつ各処理を独立スケール」なら SNS + SQS のファンアウト構成が定番です。標準キュー（高スループット・順序非保証・少なくとも1回）とFIFO（順序保証・重複排除）の違い、可視性タイムアウトとDLQの役割はDVAで頻出です。Kinesis（順序付きストリーム集計）との切り分けも問われます。
関連サービス
最終更新日: 2026-06-24
本ページの内容は、AWS公式ドキュメントを基に作成し、運営者が編集・監修しています。詳しくは編集・品質管理方針をご覧ください。