導入
SQSは「1つのキューを1つ（または複数）のコンシューマーが取り出す」1対多の分配でした。では「1つのイベントを、複数の異なるシステムに同時に知らせたい」場合はどうすればよいでしょうか。ここで登場するのがSNSとEventBridgeです。
説明
Amazon SNS（Simple Notification Service） は Pub/Sub（発行/購読）型 の通知サービスです。発行者（Publisher）がトピックにメッセージを送ると、そのトピックを購読（Subscribe）しているすべてのサブスクライバーに即座に配信されます。
SAAで頻出するのが ファンアウトパターン（SNS → 複数のSQS） です。1つのイベントを複数のキューへ同時に配信し、それぞれのシステムが独立して処理できるようにします。
flowchart LR
E["注文イベント"] --> SNS["SNSトピック"]
SNS --> Q1["SQS: 在庫システム用"]
SNS --> Q2["SQS: 請求システム用"]
SNS --> Q3["SQS: 通知メール用"]
Q1 --> S1["在庫更新Lambda"]
Q2 --> S2["請求処理Lambda"]
Q3 --> S3["メール送信Lambda"]
Amazon EventBridge は、SNSをさらに発展させた イベント駆動アーキテクチャ 向けのサービスです。イベントの中身（属性）に基づいて ルール を定義し、条件に合うイベントだけを適切なターゲットへルーティングできます。
| 機能 | できること |
|---|---|
| イベントバス | AWSサービス・自作アプリ・SaaSからのイベントを一元的に受け取る |
| ルールベースのルーティング | イベント内容でフィルタし、Lambda・SQS・Step Functionsなどへ振り分け |
| SaaS連携 | Datadog・Zendeskなど多数のパートナーSaaSのイベントを直接受信 |
| スケジュール実行 | cron式で定期的にターゲットを起動（旧CloudWatch Events相当） |
| 使い分け | SNS | EventBridge |
|---|---|---|
| 主な用途 | シンプルな通知・ファンアウト | 複雑なイベント駆動・SaaS連携・スケジュール |
| ルーティングの柔軟性 | トピック単位（購読すれば全部届く） | イベント内容でルールを細かくフィルタ可能 |
| 典型例 | アラームメール、SNS→SQSファンアウト | 複数AWSサービスをまたぐワークフローの起点、定期バッチのトリガー |
具体例
通販の「注文確定」という1つのイベントを、複数の独立システムが同時に処理したい——ここでSNSのファンアウトが光ります。
SNS → 複数SQSのファンアウト：注文確定イベントをSNSトピックに1回発行するだけで、在庫システム用・請求システム用・通知メール用の3つのSQSキューへ同時配信。各システムは自分のキューから独立して処理し、1つが遅くても他に影響しない。後から「配送システムも」と増やしても、キューを1つ足して購読させるだけで既存には手を触れない。
一方、こんな要件ならEventBridgeを選びます。
- 「注文金額が10万円以上のイベントだけ、承認ワークフローに回したい」→ イベントの内容でフィルタして振り分けられるのはEventBridge（SNSは購読者に全部届く）
- 「外部SaaS（Zendesk）の問い合わせイベントを起点に処理したい」→ SaaS連携はEventBridge
- 「毎朝9時に集計バッチを起動」→ スケジュール実行もEventBridge
「複数システムへ同報＝SNSファンアウト、内容で振り分け・SaaS連携・定期実行＝EventBridge」と使い分けます。
読んでみよう
「1つのイベントを複数の独立したシステムに同時配信したい」はSNSのファンアウト、「イベントの内容に応じて振り分け先を変えたい」「SaaSと連携したい」「定期実行したい」はEventBridge、と覚えると選択肢を素早く絞れます。