導入
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を検討します。
読んでみよう
SNSとEventBridgeはどちらも「配信」がテーマですが、内容に基づく複雑なルーティングが要るならEventBridge、単純な一斉配信ならSNSという切り分けが基本線です。実際の設計ではSNS→SQSのファンアウトとEventBridgeのルーティングが併用されることも多く、「どちらか一方だけ」と思い込まないことが大切です。