導入
SNS/SQSは「送信側が明示的にメッセージを出す」設計でした。もっと多様なイベント（AWSサービスの状態変化、SaaSからの通知、スケジュール）を、ルールに基づいて柔軟に振り分けたいとき、EventBridgeの出番です。
説明
Amazon EventBridge は、イベントを受け取るイベントバスと、そのイベントの内容に応じてどこに転送するかを決めるルールからなるサービスです。
flowchart LR
S1["AWSサービスの状態変化"] --> BUS["EventBridge<br/>イベントバス"]
S2["SaaS連携<br/>（Partner Event Source）"]--> BUS
S3["スケジュール実行"] --> BUS
S4["アプリの独自イベント"] --> BUS
BUS -->|"ルール1"| L["Lambda"]
BUS -->|"ルール2"| Q["SQSキュー"]
BUS -->|"ルール3"| SF["Step Functions"]
| 比較軸 | SNS | EventBridge |
|---|---|---|
| ルーティングの単位 | トピック単位で全購読者に配信 | イベント内容（JSONの中身）でルールを分岐 |
| イベント発生元 | 主に自アプリからのPublish | AWS 200以上のサービス・SaaS・スケジュールも標準対応 |
| スキーマ管理 | なし | スキーマレジストリでイベント構造を管理・コード生成可 |
| 向いている用途 | 単純なファンアウト通知 | 複雑な条件分岐を伴うイベント駆動アーキテクチャ全体のハブ |
「EC2インスタンスの状態が変わったら通知したい」「SaaSからのWebhookを受けてワークフローを起動したい」「複数の条件でイベントを異なるLambdaに振り分けたい」といった要件は、SNSより先にEventBridgeを検討します。
具体例
SaaS企業のイベント処理基盤で、SNSでは手に負えない要件が出てきました。
- 「有料プランの解約イベントだけ、引き留めワークフローに回したい（イベントの中身で分岐）」
- 「決済SaaS（Stripe）からのWebhookを起点に処理したい（外部SaaS連携）」
- 「毎朝9時に日次バッチを起動したい（スケジュール）」
SNSは購読すれば全部届くだけで、中身による振り分けはできません。→ EventBridgeなら、イベントのJSONの中身を見て「plan=paid かつ event=cancel のときだけLambda Aへ」といったルールベースのルーティングが書ける。200以上のAWSサービス・SaaS・スケジュールも標準の発生元として扱えます。
一方、「注文確定を在庫・メール・分析に単純に一斉配信」だけならSNSで十分（軽量）。判断は「内容による複雑なルーティングが要るか」——要るならEventBridge、単純な一斉配信ならSNS。実際は両者を併用することも多いです。
読んでみよう
SNSとEventBridgeはどちらも「配信」がテーマですが、内容に基づく複雑なルーティングが要るならEventBridge、単純な一斉配信ならSNSという切り分けが基本線です。実際の設計ではSNS→SQSのファンアウトとEventBridgeのルーティングが併用されることも多く、「どちらか一方だけ」と思い込まないことが大切です。