MENU
試験勉強のメモ
  1. ホーム
  2. AWS Certified Cloud Practitioner
  3. 【AWS Certified Cloud Practitioner】Amazon SQS と Amazon SNS の違いをやさしく整理｜使い分け・具体例・試験頻出ポイント

【AWS Certified Cloud Practitioner】Amazon SQS と Amazon SNS の違いをやさしく整理｜使い分け・具体例・試験頻出ポイント

AWS Certified Cloud Practitioner

Amazon SQS と Amazon SNS の違いをやさしく整理

Amazon SQS と Amazon SNS は、どちらも AWS の代表的なメッセージングサービスです。AWS Certified Cloud Practitioner では、両者の役割の違いを理解しているかが問われやすく、名前が似ているぶん混同しやすい分野でもあります。

結論から言うと、Amazon SQS は「メッセージをためて後で処理する仕組み」、Amazon SNS は「メッセージを複数の宛先へ一斉配信する仕組み」です。ここを軸に覚えると、試験問題でも判断しやすくなります。

目次

まずは一言で整理

  • Amazon SQS：キューにメッセージをため、受信側が取りに行って処理するサービス
  • Amazon SNS：トピックに publish されたメッセージを、複数の購読先へ配信するサービス

イメージとしては、SQS は「仕事を並べる待ち行列」、SNS は「同じ連絡を一斉に伝える放送」です。

SQS と SNS の違いを表で比較

項目Amazon SQSAmazon SNS
基本の役割メッセージをキューに保持して非同期処理するメッセージを複数の購読先へ配信する
配信方式受信側が取得する（ポーリング）購読先へ押し出す（Pub/Sub）
向いている用途疎結合化、負荷平準化、バックグラウンド処理通知、一斉配信、イベントのファンアウト
代表的な接続先EC2、Lambda、コンテナ、アプリケーションワーカーSQS、Lambda、HTTP(S)、Email、SMS など
試験での見分け方「ためる」「後で処理」「再試行」「ワーカーで処理」「通知」「複数配信」「購読」「一斉送信」

Amazon SQS とは何か

Amazon SQS（Simple Queue Service）は、アプリケーション間でメッセージを受け渡すためのマネージドキューサービスです。送信側はメッセージをキューへ入れるだけでよく、受信側は自分のタイミングでメッセージを取り出して処理できます。

この仕組みの利点は、送信側と受信側を強く結び付けずに済むことです。これを疎結合といいます。たとえば注文受付システムがすぐ応答し、その後の重い処理を別ワーカーが順に処理する、といった設計に向いています。

SQS の具体例

EC サイトで注文が入った場面を考えます。注文 API がその場で在庫更新、請求処理、配送連携まで全部実行すると、どこか1つが遅いだけで全体が遅くなります。

そこで、注文内容を SQS キューに入れておけば、注文受付は素早く終えられます。後続のワーカーがキューからメッセージを受け取り、順番に処理できます。ピーク時のアクセスにも耐えやすくなり、処理失敗時の再試行もしやすくなります。

SQS の試験ポイント

  • 負荷平準化：アクセス集中時でもメッセージをためて後で処理できる
  • 疎結合化：送信側と受信側を分離しやすい
  • 再処理しやすい：失敗した処理をやり直しやすい
  • 可視性タイムアウト：受信中のメッセージを一時的に他から見えなくする
  • DLQ（Dead-Letter Queue）：何度も失敗するメッセージを隔離できる

Standard キューと FIFO キュー

SQS には主に Standard と FIFO の2種類があります。

  • Standard キュー：高スループット重視。順序は厳密ではなく、重複配信の可能性もある
  • FIFO キュー：順序を守りたい処理向け。重複排除機能を使い、より厳密な制御ができる

試験では、「順序が重要」、「重複を避けたい」とあれば FIFO を疑うのが基本です。たとえば決済、在庫引当、会計処理などでは FIFO が適しています。

Amazon SNS とは何か

Amazon SNS（Simple Notification Service）は、Publish/Subscribe モデルでメッセージを配信するマネージド通知サービスです。メッセージを Topic に publish すると、その Topic を購読している複数の宛先へ同時に配信できます。

SNS は、「1つのイベントを複数の相手にすばやく知らせたい」場面に向いています。

SNS の具体例

会員登録完了イベントが発生したとします。このとき、次のような複数処理が必要になることがあります。

  • ユーザーへ確認メール送信
  • 運用担当へ通知
  • Lambda で初期設定処理を開始
  • 分析システムへイベント連携

このような場合、1つの SNS Topic にイベントを publish すれば、複数の購読先へ一斉配信できます。これが ファンアウト です。

SNS の試験ポイント

  • Pub/Sub モデルのサービスである
  • 複数の購読先へ同時配信できる
  • 購読先として SQS、Lambda、HTTP(S)、Email、SMS などを利用できる
  • メッセージフィルタリングにより、購読先ごとに受け取る条件を分けられる

実務でよくある組み合わせ：SNS → SQS

実際の AWS 設計では、SQS と SNS を組み合わせることがよくあります。これは Cloud Practitioner でも理解しておく価値があります。

たとえば「注文確定」というイベントを 1 回発行し、それを複数システムで使いたい場合を考えます。

  • 請求処理用の SQS キュー
  • 在庫連携用の SQS キュー
  • 分析処理用の SQS キュー

この構成では、SNS が一斉配信を担当し、SQS が各システムごとの非同期処理を担当します。つまり、「配るのは SNS、ためて処理するのは SQS」です。

この組み合わせは、試験でも非常に重要です。問題文で「同じイベントを複数のシステムに渡したい」「ただし各システムは自分のペースで処理したい」とあれば、SNS と SQS の連携を考えると正解しやすくなります。

試験での見分け方

SQS を選びやすいキーワード

  • 非同期処理
  • キューにためる
  • ワーカーが順次処理
  • 負荷平準化
  • 再試行
  • DLQ

SNS を選びやすいキーワード

  • 通知
  • 複数宛先へ同時配信
  • 購読
  • ファンアウト
  • Email / SMS / Lambda / HTTP(S)

よくある誤解

誤解1：通知系は全部 SNS

通知という言葉だけで SNS を選ぶのは危険です。たしかに一斉通知は SNS の得意分野ですが、後で確実に処理したい作業なら SQS が向いています。用途が「連絡」なのか「処理待ち」なのかで分けると整理しやすくなります。

誤解2：SQS と SNS はどちらか片方だけ使う

実務では両方を一緒に使うことが珍しくありません。SNS で広く配り、SQS で各処理を安定して受け止める構成は非常に典型的です。

誤解3：順序制御は SQS だけの話

Cloud Practitioner ではまず SQS の FIFO を押さえるのが先ですが、SNS にも FIFO トピックがあります。順序や重複排除が重要な高度な連携では、SNS FIFO と SQS FIFO を組み合わせる構成もあります。ただし、初学者はまず 「順序重視なら FIFO」 を理解すれば十分です。

試験直前のまとめ

  • SQS はメッセージをためて後で処理するサービス
  • SNS はメッセージを複数宛先へ一斉配信するサービス
  • 処理待ち・再試行・バッファリングなら SQS
  • 通知・購読・ファンアウトなら SNS
  • 両方を組み合わせると、一斉配信しつつ各システムが自分のペースで処理できる
  • 順序や重複回避が重要なら FIFO を検討する

参考にした AWS 公式情報

AWS Certified Cloud Practitioner
aws AWS Certified Cloud Practitioner Cloud Practitioner FIFO PubSub SNS SQS メッセージング 非同期処理
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！
目次