AWS SAA-C03 SQS/SNS/EventBridgeの違い｜3分で判断できる使い分け表

AWS
2026.01.17

SQS/SNS/EventBridgeは「何を運ぶか」で3分判断できる

SAA-C03で頻出の SQS / SNS / EventBridge は、見た目が似ているせいで混乱しがちです。ですが、試験では「要件に合う“役割”」を当てられるかがすべて。先に1行定義で頭を固定すると一気に解けるようになります。

  • SQS：処理待ちの仕事（ジョブ）を貯める“キュー”
  • SNS：複数に同時通知する“配信（Fanout）”
  • EventBridge：起きた出来事（イベント）を条件で振り分ける“イベントルーター”

ここで大事なのは、SNSはキューではないという点です。SNSは「通知・配信」が得意で、受け取った側が確実に“後で処理する”仕組みが必要なら、SQSと組み合わせるのが王道になります。
一方のEventBridgeは「通知」よりも、イベントの種類に応じて宛先を柔軟に切り替えるのが得意です。AWSサービスのイベント（例：EC2の状態変化、CodePipeline、ECR等）や、アプリが発行するイベントをルールでルーティングするイメージです。

この記事は、次の順で読めば “3分で判断”→“例題で確信” まで一直線です。

  1. 使い分け表で結論を決める
  2. フローチャートで迷いを消す
  3. 例題（頻出パターン）で反射的に選べるようにする

3分で判断できる「使い分け表」＋ フローチャート

使い分け表

観点SQSSNSEventBridge
役割キュー（仕事の待ち行列）通知・Fanout（同報配信）イベントのルーティング（条件分岐）
基本モデルProducer → Queue → ConsumerPublisher → Topic → SubscribersSource → Event bus → Rules → Targets
“貯める”得意（処理が詰まってもOK）基本は貯めない（配信中心）イベントを流して振り分け（用途次第）
順序FIFOで順序保証（要件が出たら強い）原則「順序」が主目的ではないルーティングが主目的（順序は中心テーマではない）
リトライ/再処理コンシューマ側設計＋DLQが鉄板配信失敗時の扱いは設計要ルール・ターゲット連携で設計（アーカイブ/リプレイ等の発想）
典型ユースケースワーカー処理、バッチ、非同期化、バックプレッシャー複数宛先へ同時通知、SQS/Lambdaへ配信AWSイベント駆動、サービス連携、条件分岐ルーティング
よくある正解コンビ–SNS → SQS（Fanout＋確実な後処理）EventBridge →（Lambda/StepFunctions/SQS等）

3分判断フローチャート

  1. **「処理待ちの仕事を貯めて、ワーカーが順番にさばく」**が主目的？
    　→ Yes：SQS
  2. **「同じメッセージを複数の購読者へ一斉配信」**したい？
    　→ Yes：SNS（処理の確実性が要るなら SNS→SQS）
  3. 「イベント種類や内容に応じて、宛先をルールで振り分けたい」？（AWSサービスイベント/アプリイベント）
    　→ Yes：EventBridge
  4. それでも迷うなら：
    　- “ジョブ（処理）”が主語 → SQS
    　- “通知（配信）”が主語 → SNS
    　- “出来事（イベント）”が主語 → EventBridge

試験で刺さるキーワード辞典

  • SQS：非同期ワーカー、バックプレッシャー、処理の平準化、キュー、DLQ、FIFO、可視性（見えなくして再配信）
  • SNS：Topic、サブスク、Fanout、複数宛先、通知、モバイル/メール、SQSへ配信
  • EventBridge：イベントバス、ルール、パターンマッチ、AWSサービスイベント、SaaS連携、クロスアカウント、（必要なら）Pipes

SQSを選ぶべき要件｜“処理待ちの仕事”を確実にさばく

SQSが正解になる問題は、主語がだいたい「処理」です。例えば次のような要件が出たら、ほぼSQSを疑ってOKです。

SQSがドンピシャな要件

  • ピーク時の負荷を平準化したい（処理が詰まってもメッセージを貯める）
  • 非同期にしたい（フロントは即応答、裏でワーカーが処理）
  • ワーカーが複数台で並列処理したい（疎結合にしてスケール）
  • 失敗したメッセージを隔離したい（DLQの発想）
  • 順序が重要（→ FIFOが候補に上がる）

標準キュー vs FIFO

  • FIFOが必要になる典型ワード：
    「順序を保証」「重複を許さない」「同じ注文を二重処理したくない」
  • それ以外（多くのケース）は 標準キュー の発想でOKです。
    試験では「順序」や「重複排除」が明示されない限り、無理にFIFOを選ばないほうが安全です。

DLQ（デッドレターキュー）は“失点回避の鉄板”

SQS問題でありがちな落とし穴は、「失敗時にどうする？」が書かれているのにDLQを選ばないこと。
一定回数リトライしてダメなら隔離して調査、が試験の王道パターンです。

ひっかけ：SNSと混ぜて考える問題

よくある設問：
「複数のコンシューマに同じメッセージを届けたい」
この時、**SQS単体だと“取り合い”**になりやすく、「同じメッセージを全員が受け取る（Fanout）」には向きません。
ここでの正解は多くが SNS→複数SQS（後述）です。

SNSを選ぶべき要件｜“同報配信”が主役ならSNS

SNSが正解になる問題は、主語が「通知」です。例：注文が入った・登録完了・アラート発生などを、複数の宛先へ一斉に届けたい。

SNSがドンピシャな要件

  • **1つの発行元から複数の宛先へ同時に配信（Fanout）**したい
  • 宛先が 複数種類（例：SQS、Lambda、HTTPエンドポイント等）
  • 「購読者（サブスクライバー）」という発想が出てくる
  • 通知・配信が主で、処理待ち行列を作るのが主目的ではない

最頻出の正解コンボ：SNS → SQS

SAA-C03ではこの組み合わせが本当に出ます。理由はシンプルで、SNSは配信が得意、SQSは貯めて処理が得意だからです。

  • SNS：同じメッセージを複数に配る（Fanout）
  • SQS：各システムが自分のペースで確実に処理（詰まっても貯められる）

典型シナリオ：

  • 「注文イベントを 請求・在庫・配送 の3システムに配りたい」
    → SNSで配信し、各システムは自分専用SQSで処理するのが定番解です。

SNSのフィルタ（メッセージ属性）も試験で使う

「Aの通知はAチームへ、Bの通知はBチームへ」みたいな要件が出たら、SNSのサブスク側での振り分け（フィルタ）の発想が刺さります。
ただし「イベントの種類に応じてルールで柔軟に分岐」まで行くと、次のEventBridgeの土俵になってきます。

EventBridgeを選ぶべき要件｜“出来事を条件で振り分ける”ならこれ一択

EventBridgeが正解になる問題は、主語が「イベント（出来事）」です。SNSの“通知”と似ていますが、EventBridgeは特に ルールでのルーティング が中心です。

EventBridgeがドンピシャな要件

  • AWSサービスのイベントをトリガーに処理したい
    例：リソース状態変化、デプロイ、各種サービスのイベント
  • イベント内容（フィールド）に応じて宛先を分岐したい（ルール・パターンマッチ）
  • 複数ターゲットへイベントを流したい（ただし主役は“ルールで振り分け”）
  • 疎結合なイベント駆動アーキテクチャを作りたい
  • さらに踏み込むと：外部SaaS連携、クロスアカウント連携、イベントの追跡・再実行の発想

SNSとの境界：こう書かれていたらEventBridge寄り

  • 「イベントバス」「ルール」「パターン」「特定のイベントのみ」
  • 「サービスAのイベントはLambda、サービスBのイベントはStep Functionsへ」
  • 「将来宛先が増減しても、コード変更を最小化したい（ルール追加で対応）」

SNSもフィルタはできますが、試験では「イベント駆動のルーティング」という匂いがしたらEventBridgeを優先しやすいです。

頻出ミニ例題

  1. Webの注文受付は即応答、裏で請求処理を非同期化 → SQS
  2. 1つの通知を、メールとLambdaとSQSへ同時配信 → SNS
  3. 注文イベントを請求・在庫・配送の3チームがそれぞれ確実に処理 → SNS→各SQS
  4. EC2の状態変化イベントで自動処理を起動 → EventBridge
  5. “イベント種別”がAならLambda、BならStep Functionsへ分岐 → EventBridge
  6. 処理が追いつかない時でも落とさず貯めたい → SQS
  7. 「順序が重要」「二重処理禁止」→ SQS FIFO
  8. 外部SaaSのイベントを受けて社内処理へルーティング → EventBridge
  9. 同じメッセージを複数システムが“それぞれ”受け取る必要 → SNS（必要ならSQS併用）
  10. マイクロサービス間をイベントで疎結合にし、宛先をルールで増減 → EventBridge

まとめ

SQS/SNS/EventBridgeは、SAA-C03で「似ている選択肢」として出やすい一方、主語を見抜けば3分で決着します。ポイントはこれだけです。

  • SQS＝ジョブ（処理待ち）を貯めるキュー：非同期ワーカー、平準化、DLQ、（順序が要れば）FIFO
  • SNS＝通知を複数へ同時配信：Fanoutが主役。確実な後処理が必要なら SNS→SQS が王道
  • EventBridge＝出来事（イベント）をルールで振り分ける：AWSサービスイベントやアプリイベントを、条件分岐でターゲットへルーティング

試験では「通知」「処理待ち」「イベントルール」といったキーワードが露骨に混ざります。迷ったら、“何を運んでいる？”（ジョブ/通知/出来事） に戻って選べば正答率が上がります。

SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇

SAA-C03対策｜Udemyのおすすめ講座を見る
タイトルとURLをコピーしました