導入
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のファンアウト、「イベントの内容に応じて振り分け先を変えたい」「SaaSと連携したい」「定期実行したい」はEventBridge、と覚えると選択肢を素早く絞れます。