SAA SQS/SNS/EventBridge 設計パターン4選｜キュー・ファンアウト・イベント駆動の要件別選択基準
AWS SAA-C03 でのメッセージングサービスを攻略する設計パターン4選。SQS Standard vs FIFO の使い分け、SNS ファンアウトパターン、EventBridge イベント駆動アーキテクチャ、デッドレターキュー（DLQ）活用まで、要件キーワードから即断できる粒度で解説。「疎結合・非同期処理」問題はこの4パターンで完全網羅できる。
「非同期処理・疎結合・イベント駆動」の問いに、SAA-C03 は4パターンしか答えを持っていない。 SQS・SNS・EventBridge は全て「コンポーネントを切り離す」サービスだが、「1対1でキューに溜める」「1対多でプッシュ通知する」「イベントパターンでルーティングする」の3軸で役割が明確に異なる。攻略の核心は**「誰が誰にどう届けるか（プル vs プッシュ）」「順序・重複の保証が必要か（Standard vs FIFO）」「複数の宛先に届けるか（ファンアウト）」「イベント内容で振り分けるか（EventBridge）」の4軸**で要件を振り分けることだ。本記事では、SAA-C03 の「疎結合・非同期処理」問題を即断できる4設計パターンを、要件キーワードから逆引きできる粒度で解説する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：SQS/SNS/EventBridge は「キュー・ファンアウト・イベントルーティング」で分類できる
- SQS の基本構造（Standard vs FIFO）
- SNS の基本構造（ファンアウト・メッセージフィルタリング）
- EventBridge の基本構造（イベントバス・ルール・スケジュール）
- パターン1：SQS デカップリング（プロデューサー × コンシューマー 疎結合）
- パターン2：SQS FIFO で順序保証・重複排除
- パターン3：SNS ファンアウト（1対多プッシュ）
- パターン4：EventBridge イベント駆動アーキテクチャ
- 要件キーワード早見表
- 頻出ひっかけパターンと正しい打ち手
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：3サービスの役割分担
SAA-C03 のメッセージング問題を最短で解く骨格は、「誰が、いつ、どこへ、どのように届けるか」を3つの軸で独立して判断することだ。
| サービス | 配信モデル | メッセージ保持 | 主なユースケース |
|---|---|---|---|
| SQS | プル型（コンシューマーが取りに行く） | 最大14日間 | コンポーネント間の疎結合・バッファ |
| SNS | プッシュ型（トピックが全員に送る） | 保持なし | 1対多の通知・ファンアウト |
| EventBridge | イベントバス型（ルールで振り分け） | 保持なし（24時間リプレイ可） | イベント駆動・SaaS連携・スケジュール |
3サービスの違いを整理するだけで、SAA のメッセージング問題は4パターンに絞れる。「非同期にしたい」だけで SQS を選ばず、「1対多か」「順序が必要か」「イベント内容で振り分けるか」を先に判断することが正解への近道だ。
2. SQS の基本構造（Standard vs FIFO）
SQS Standard キュー
SQS Standard キューはほぼ無制限のスループットを持つ高速キューだ。
- 配信保証： At-Least-Once（少なくとも1回配信。重複あり）
- 順序： ベストエフォート（順序は保証されない）
- スループット： ほぼ無制限 TPS
- Visibility Timeout： メッセージを受け取ったコンシューマーが処理中の間、他のコンシューマーに見えなくなる（デフォルト30秒）
- Dead Letter Queue（DLQ）： 処理に繰り返し失敗したメッセージを別キューに隔離
SQS FIFO キュー
SQS FIFO キューは厳密な順序保証と重複排除を持つキューだ。
- 配信保証： Exactly-Once（重複なし）
- 順序： FIFO（First-In-First-Out）。MessageGroupId ごとに順序が保たれる
- スループット： 300 TPS（バッチ処理で最大3,000 TPS）
- 制約： Standard キューより低スループット。キュー名は
.fifoサフィックス必須
| 評価項目 | Standard | FIFO |
|---|---|---|
| 配信保証 | At-Least-Once（重複あり） | Exactly-Once（重複なし） |
| 順序 | ベストエフォート（保証なし） | 厳密な FIFO 順序（MessageGroupId 単位） |
| スループット | ほぼ無制限 TPS | 300 TPS（バッチで最大3,000 TPS） |
| 主なユースケース | メール送信・ログ収集・バッファリング | 金融取引・在庫更新・コマンド処理 |
| SNS との連携 | ○ SNS → SQS Standard | ○ SNS FIFO → SQS FIFO のみ |
Dead Letter Queue（DLQ）の役割
DLQ は処理失敗メッセージの隔離先だ。
通常フロー：
プロデューサー → SQS キュー → コンシューマー（処理成功）→ メッセージ削除
失敗フロー：
コンシューマーが処理失敗 → Visibility Timeout 経過後にキューに戻る
→ maxReceiveCount 回失敗 → DLQ（別キュー）に移動
→ DLQ のメッセージを調査・デバッグ3. SNS の基本構造
SNS（Simple Notification Service）の仕組み
SNS はトピックにメッセージをパブリッシュすると、全サブスクライバーに同時プッシュ配信するサービスだ。
- サブスクライバー： SQS・Lambda・HTTP/HTTPS・Email・SMS・Kinesis Data Firehose
- メッセージ保持： なし（配信失敗時のリトライは行うが、恒久的な保存はしない）
- ファンアウト： 1つのトピックに複数のサブスクライバーを登録することで、1発行で全員に届く
SNS メッセージフィルタリング
サブスクライバーごとにフィルターポリシーを設定することで、全メッセージではなく条件に一致するメッセージのみを受け取れる。
例：注文処理システムのフィルタリング
SNS トピック「orders」
↓
├── SQS キュー「pay-queue」 ← フィルター: {type: "payment"}
├── SQS キュー「ship-queue」 ← フィルター: {type: "shipment"}
└── SQS キュー「notify-queue」← フィルター: {type: "notification"}4. EventBridge の基本構造
EventBridge（旧 CloudWatch Events）の仕組み
EventBridge はイベントバスを通じて、ソースから発生したイベントをルールに基づいてターゲットに振り分けるサービスだ。
-
イベントバスの種類：
- デフォルトバス： AWS サービスのイベント（EC2 起動・S3 オブジェクト作成等）が自動的に流れる
- カスタムバス： アプリケーションの独自イベントを流す
- パートナーバス： SaaS（Datadog・Zendesk 等）のイベントを直接受け取る
-
ルールの種類：
- イベントパターンルール： イベントの内容（source・detail-type・detail フィールド）に一致したときに発火
- スケジュールルール： cron/rate 式で定期実行（CloudWatch Events のスケジューラ機能の後継）
-
ターゲット： Lambda・SQS・SNS・Step Functions・API Gateway・Kinesis 等250種以上
5. パターン1：SQS デカップリング（プロデューサー × コンシューマー 疎結合）
要件のキーワード
- 「Web アプリが注文を受け付けるが、バックエンド処理が遅くてタイムアウトが発生している」
- 「処理速度の異なる2つのシステムを接続したい。片方がダウンしても注文を失いたくない」
- 「バースト時にメッセージを蓄積して、バックエンドは自分のペースで処理したい」
アーキテクチャ
プロデューサー（Web API / EC2）
→ SQS キューにメッセージを送信（すぐに200 OK を返せる）
コンシューマー（EC2 / Lambda）
→ SQS から pull してメッセージを処理
→ Auto Scaling: キューの深さ（ApproximateNumberOfMessages）に応じてスケール
→ 処理成功 → メッセージ削除
→ 処理失敗 → Visibility Timeout 後に再試行 → DLQ へ試験での正解条件
- 「バックエンドの処理が遅いので Web API がタイムアウト」→ SQS で非同期化
- 「バックエンドがダウンしてもメッセージを失いたくない」→ SQS（最大14日間保持）
- 「バースト時に処理を平滑化したい」→ SQS + Auto Scaling（キュー深さに基づく）
6. パターン2：SQS FIFO で順序保証・重複排除
要件のキーワード
- 「注文の処理順序が重要で、後から来た注文が先に処理されてはいけない」
- 「重複して注文が処理されてはいけない（二重課金・在庫の二重減算が困難）」
- 「厳密に1回だけ処理したい（Exactly-Once）」
アーキテクチャ：FIFO キューの使い分け
例：金融取引処理
プロデューサー（取引受付）
→ SQS FIFO キュー（MessageGroupId: 口座ID）
→ コンシューマー（取引処理）
MessageGroupId が同じメッセージ → 厳密に FIFO 順で処理
MessageGroupId が異なるメッセージ → 並列処理（グループ間は並列 OK）試験での正解条件
- 「処理順序が重要（金融・在庫）」→ SQS FIFO + MessageGroupId
- 「重複処理を防ぎたい」→ SQS FIFO（MessageDeduplicationId で自動重複排除）
- 「高スループットかつ順序不要」→ SQS Standard（FIFO は 300 TPS 上限あり）
7. パターン3：SNS ファンアウト（1対多プッシュ）
要件のキーワード
- 「注文が完了したら、在庫・配送・通知の3つのシステムを同時に動かしたい」
- 「同じメッセージを複数のキュー・Lambdaに同時に届けたい」
- 「各システムが独立して受け取り・独立してスケールできるようにしたい」
アーキテクチャ：SNS + SQS ファンアウト
注文受付システム
→ SNS トピック「order-events」にパブリッシュ
↓（同時配信）
├── SQS キュー「inventory-queue」 → 在庫管理システム（Lambda）
├── SQS キュー「shipping-queue」 → 配送システム（EC2）
└── SQS キュー「notify-queue」 → 通知サービス（Lambda）
各キューが独立してメッセージを保持・処理
→ 在庫システムが遅くても配送・通知は先に動く
→ 一部システムがダウンしても他は影響なしなぜ SNS から直接 Lambda を複数呼ばないのか
SNS から Lambda を直接呼ぶことは可能だが、SQS を挟む理由がある。
| 直接呼び出し（SNS → Lambda） | SNS + SQS ファンアウト |
|---|---|
| Lambda が即時実行（リトライは限定的） | SQS がメッセージを保持（14日）しリトライ |
| Lambda の同時実行数上限に直撃しやすい | SQS がバッファとなり Lambda を保護 |
| 処理失敗時のメッセージロストリスクあり | DLQ で失敗メッセージを隔離・調査可能 |
8. パターン4：EventBridge イベント駆動アーキテクチャ
要件のキーワード
- 「AWS サービスのイベント（EC2 起動・S3 アップロード）をトリガーに処理を走らせたい」
- 「SaaS（Datadog・Zendesk）のイベントを受け取って自動対応したい」
- 「イベントの JSON フィールドの値によって宛先を動的に切り替えたい」
- 「定期バッチを CloudWatch Events のスケジュールで実行していたが、EventBridge に移行したい」
アーキテクチャ：EventBridge ルールによるルーティング
イベントソース
├── AWS サービス（EC2・S3・CodePipeline 等）→ デフォルトバス
├── カスタムアプリ（PutEvents API）→ カスタムバス
└── SaaS（Datadog・Zendesk 等）→ パートナーバス
EventBridge イベントバス
↓（ルールでマッチング）
├── ルール1: {source: "aws.ec2", detail-type: "EC2 Instance State-change"} → Lambda
├── ルール2: {source: "myapp", detail.type: "order.created"} → SQS
└── ルール3: スケジュール（rate(1 day)） → Step FunctionsEventBridge vs SNS の選択基準
| 判断ポイント | EventBridge | SNS |
|---|---|---|
| ルーティングの複雑さ | JSON フィールドの深い値でマッチング | 属性ベースのフィルタリング（SNS フィルタポリシー） |
| SaaS 連携 | パートナーバスで直接受信 | 対応なし |
| クロスアカウント | イベントバスポリシーでアカウント間配信 | 対応なし（同一アカウント内のみ） |
| スケジュール | cron/rate 式でスケジュール実行 | 対応なし |
| ターゲット数 | 1ルールに最大5ターゲット | サブスクライバー無制限 |
| ユースケース | AWS サービス連携・SaaS・複雑なルーティング | シンプルなファンアウト・通知 |
9. 要件キーワード早見表
| 要件キーワード | 正解パターン | 選んではいけない |
|---|---|---|
| 「非同期・疎結合・バッファ」 | SQS | 同期 API 呼び出し（密結合） |
| 「処理順序が重要・重複排除」 | SQS FIFO | SQS Standard（順序不保証・重複あり） |
| 「高スループット（数万 TPS）+ 順序」 | Kinesis Data Streams | SQS FIFO（300 TPS 上限） |
| 「複数システムに同じメッセージ・同時配信」 | SNS ファンアウト | SQS（1対1配信） |
| 「ファンアウト + 耐障害性・リトライ」 | SNS + SQS 組み合わせ | SNS → Lambda 直接（保持なし） |
| 「AWS サービスのイベントをトリガーに処理」 | EventBridge（デフォルトバス） | SNS（AWS サービスイベントは EventBridge が主流） |
| 「SaaS（Datadog/Zendesk）のイベントを受け取る」 | EventBridge パートナーバス | SNS（対応なし） |
| 「イベントの JSON フィールドで宛先を動的切り替え」 | EventBridge ルール | SNS（属性ベースのみ） |
| 「定期バッチ実行（cron/rate）」 | EventBridge スケジュール | SQS（スケジュール機能なし） |
| 「処理失敗メッセージを隔離・調査」 | SQS DLQ | メッセージ削除（ロストする） |
| 「Long Polling でコストを下げたい」 | SQS Long Polling | Short Polling（空レスポンス多発） |
10. 頻出ひっかけパターンと正しい打ち手
ひっかけ1：SNS はメッセージを保持すると思い込む
誤り： 「SNS にメッセージをパブリッシュすれば、コンシューマーが後からいつでも取り出せる」
正解： SNS はメッセージを保持しない。コンシューマーが受け取れなかったメッセージはロストする。SNS + SQS のファンアウトパターンで SQS がメッセージを保持する構成が必要だ。
ひっかけ2：SQS FIFO を「すべての順序保証に使う」と思い込む
誤り： 「大量のリアルタイムログを順序通りに処理したい → SQS FIFO」
正解： SQS FIFO は 300 TPS（バッチで3,000 TPS）が上限。毎秒数万件の高スループットで順序保証が必要なら Kinesis Data Streams（シャードキーでパーティション内順序保証）が正解だ。
ひっかけ3：SNS と EventBridge を混同する
誤り： 「EC2 インスタンスの状態変化イベントを SNS トピックで直接受け取る → SNS」
正解： EC2 の状態変化イベントは EventBridge（旧 CloudWatch Events）のデフォルトバスに自動的に流れる。SNS は「通知先」であり、EventBridge → SNS の順に使うのが正しい構成だ。
ひっかけ4：SQS を「1対多」に使おうとする
誤り： 「SQS キューのメッセージを3つのシステムが同時に受け取る → SQS 1つ」
正解： SQS は1つのメッセージを1つのコンシューマーだけが取り出す（他のコンシューマーには見えなくなる）。**1対多は SNS ファンアウト + SQS（サブスクライバーごとに個別キュー）**を使う。
11. 次のアクション チェックリスト
- SQS Standard と FIFO の配信保証・順序・スループットの違いを言える
- SQS の Visibility Timeout と DLQ の役割を説明できる
- SNS ファンアウトパターン（SNS + SQS）のアーキテクチャを図示できる
- SNS がメッセージを保持しないことを理解した
- EventBridge のデフォルトバス・カスタムバス・パートナーバスの違いを言える
- EventBridge と SNS の選択基準（複雑なルーティング・SaaS 連携・スケジュール）を押さえた
- 「SQS FIFO は 300 TPS 上限」と「高スループット順序保証は Kinesis」を即答できる
- SNS + SQS FIFO ファンアウトには SNS FIFO トピックが必要なことを理解した
- SAA Kinesis 設計パターン で高スループット順序処理との違いを確認した
12. 関連記事
- SAA-C03 試験完全ガイド｜試験概要・ドメイン・合格戦略
- SAA ドメイン2：弾力性のあるアーキテクチャ 完全解説
- SAA Lambda/サーバーレス設計パターン
- SAA Kinesis 設計パターン（KDS/KDF/KDA）
- SAA CloudWatch/X-Ray 設計パターン