SQS と SNS で「渡す」と「配る」は分かった。けれど構成図を見ると、EC2 が止まったら通知する、毎晩バッチを起動する、別のアカウントの出来事を集める、といった矢印の真ん中に Amazon EventBridge がいます。SNS と何が違うのか、ルールとターゲットは何を指すのか、Scheduler や Pipes まで並ぶと、どこから手を付ければいいか分からなくなります。この記事は、EventBridge を「出来事を受け取り、条件に合うものだけを回し先へ送る仕分け係」として掴み、正確な用語に戻して、SNS・SQS との使い分けまでを1本で整理します。
この記事の結論
- Amazon EventBridge は、イベントを受け取り、条件に合うものだけを決めた回し先へ送るサーバーレスのサービスです。
- 中心の部品は、イベントを受けるイベントバス、条件を書くルール（イベントパターン）、送り先のターゲットの3つです。
- AWS のサービスが自分のアカウントで出したイベントはデフォルトイベントバスに届くので、EC2 の状態変化などはそこにルールを作って拾います。
- 決まった日時の実行は EventBridge Scheduler、1つの送り元と1つの送り先をつなぐなら EventBridge Pipes が受け持ちます。
- 決まった受け手へ配るだけなら SNS、仕事を貯めて受け手のペースで処理するなら SQS、出来事の中身で振り分けるなら EventBridge が候補です。
EventBridge とは（何のためにあるか）
Amazon EventBridge は、イベントを受け取って、ルールに合うものをターゲットへ送るサービスです。イベントとは「何かが起きた」という知らせで、中身は JSON で書かれています。EC2 のインスタンスが止まった、S3 にファイルが置かれた、注文が確定した、といった出来事がイベントになります。
たとえるなら、会社の受付に座る仕分け係です。届いた知らせを1枚ずつ見て、「経理宛ての請求書は経理へ」「設備の故障は総務へ」と、決めておいた条件に合うものだけを担当の部署へ回します。送り手は、自分の知らせが最後にどの部署へ届くかを知りません。回し先を増やしたいときは、受付の決まりを1つ足すだけで済みます。
このたとえを正確な言葉に戻すと、次のようになります。
- 受付の窓口がイベントバス（イベントを受け取る場所）
- 「経理宛ては経理へ」という決まりがルールと、その条件を書いたイベントパターン
- 回し先の部署がターゲット（Lambda 関数・SQS のキュー・SNS のトピック・Step Functions・別のイベントバス など）
この形の価値は、送り手と受け手を互いに知らなくてよい状態にすること、つまり疎結合にあります。送り手のコードを書き換えずに、受け手を足したり外したりできます。
EVENT ROUTINGイベントの通り道
出来事はバスで受け、ルールで選んでターゲットへ
-
出来事が起きる
EC2 の停止・注文の確定
-
イベントバス
イベントを受け取る入口
-
ルール
イベントパターンと照合
-
ターゲット
Lambda・SQS・SNS など
イベントバス・ルール・ターゲットはどうつながるのか
イベントバス
イベントバスは、イベントを受け取る入口です。アカウントには最初からデフォルトイベントバスが1つあり、自分のアカウントで AWS のサービスが出したイベントは、必ずここに届きます。自分のアプリの出来事を流すために、名前を付けたカスタムイベントバスを作ることもできます。SaaS の提供元から届くイベントは、パートナーイベントソースとして受け取ります。
ルールとイベントパターン
ルールは、イベントバスに結び付ける「どのイベントを、どこへ送るか」の決まりです。イベントが届くと、EventBridge はそのバスにあるルールを1つずつ照らし合わせ、パターンに合ったルールのターゲットへイベントを送ります。1つのイベントが複数のルールに合うこともあり、その場合はそれぞれのターゲットへ届きます。
デフォルトイベントバスと従来のカスタムイベントバスでは、1つのルールに5つまでターゲットを付けられます。送る前にイベントの形を組み替える入力の変換も、ルールの中で指定できます。
ターゲット
ターゲットは、イベントを受け取って仕事をする側です。Lambda 関数を起動する、SQS のキューに入れる、SNS のトピックで通知する、Step Functions のワークフローを始める、別のアカウントのイベントバスへ送る、といった送り先を選べます。HTTP の API へ送る API の送信先（API destinations）も使えます。
| 部品 | 役割 | たとえ |
|---|---|---|
| イベント | 起きた出来事の JSON | 届いた知らせ |
| イベントバス | イベントを受け取る入口 | 受付の窓口 |
| ルール（イベントパターン） | どのイベントをどこへ送るかの条件 | 「経理宛ては経理へ」という決まり |
| ターゲット | イベントを受けて仕事をする送り先 | 回し先の部署 |
CHECK 1ここまでの確認
AWS のサービスが自分のアカウントで出したイベント（EC2 の状態変化など）を拾うルールは、どのイベントバスに作りますか?
答えと解説
答え: 2. アカウントのデフォルトイベントバス
AWS のサービスのイベントは、アカウントのデフォルトイベントバスに届きます。「イベントバス・ルール・ターゲットはどうつながるのか」を読み直してください。
AWS のサービスの出来事をどう拾うのか
EventBridge が構成図でよく出てくるのは、AWS のサービスが出す出来事に反応する場面です。EC2 の状態の変化、Auto Scaling の起動と終了、CodePipeline の実行の失敗、GuardDuty の検出結果、AWS Health の通知などが、イベントとしてデフォルトイベントバスに届きます。定期的に状態を問い合わせる仕組みを自分で作らなくても、起きたときに知らせが来ます。
イベントパターンの書き方
たとえば「EC2 のインスタンスが停止か終了になったら知らせたい」なら、ルールのイベントパターンは次のように書きます。
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"],
"detail": {
"state": ["stopped", "terminated"]
}
}
source はどのサービスから来たか、detail-type はどの種類の出来事か、detail は出来事の中身です。パターンに書いた項目の値がすべて合ったイベントだけがターゲットへ送られ、書いていない項目は何でも構いません。ターゲットに SNS のトピックを付ければ通知に、Lambda を付ければ自動の対処になります。
EVENT PATTERNルールの門
パターンに合ったイベントだけが門を通ってターゲットへ進む
ルール: source が aws.ec2、state が stopped か terminated
- EC2インスタンスが stopped に 通知へaws.ec2
- EC2インスタンスが terminated に 通知へaws.ec2
- EC2インスタンスが running に 対象外aws.ec2
- S3オブジェクトが作られた 対象外aws.s3
アカウントをまたいで集める
イベントバスは、別のアカウントのイベントバスをターゲットにできます。各アカウントのルールで中央のアカウントのバスへイベントを送り、受け取る側のバスには、どのアカウント（または組織）からの送信を許すかをリソースベースのポリシーで書きます。セキュリティの検出結果を運用のアカウントに集める構成は、この形です。
CHECK 2ここまでの確認
ルールのイベントパターンに書く source と detail-type は、何を絞り込むためのものですか?
答えと解説
答え: 2. どのサービスの、どの種類の出来事かという条件
イベントパターンは、届いたイベントの JSON の項目と値に対する条件です。source はどのサービスか、detail-type は出来事の種類を表します。「AWS のサービスの出来事をどう拾うのか」の例を読み直してください。
EventBridge Scheduler と Pipes はどこに位置づくのか
EventBridge の名前の付いた部品は、イベントバスのほかに2つあります。
EventBridge Scheduler（決まった日時に起動する）
EventBridge Scheduler は、決まった日時にターゲットを呼び出すための部品です。cron 式や rate 式で繰り返しを書けるほか、日時を1つだけ指定する一度きりの実行も作れます。タイムゾーンを指定できるので、「平日の日本時間 20 時に開発環境の EC2 を止める」のような指定がそのまま書けます。ターゲットとして、多くの AWS サービスの API を直接呼べます。
ルールの側にも定期実行を書く方法（スケジュールで動くルール）がありますが、公式ドキュメントはこれを legacy と位置づけ、新しく作るなら Scheduler を勧めています。サーバーの cron で回していたバッチを AWS に移すときは、Scheduler から Lambda や ECS のタスクを起動する形がよく使われます。
EventBridge Pipes（1つの送り元と1つの送り先をつなぐ）
EventBridge Pipes は、1つの送り元（SQS のキューや DynamoDB のストリームなど）と1つの送り先を、1対1でつなぐ部品です。途中に絞り込みと、Lambda や API Gateway などで情報を足すエンリッチメントを挟めます。イベントバスが「多くの送り元から多くの送り先へ振り分ける」のに対して、Pipes は「この流れを1本の管でつなぐ」役目です。
| 部品 | 何を起点に動くか | 向いている場面 |
|---|---|---|
| イベントバス＋ルール | 届いたイベントの中身 | 多くの出来事を条件で振り分ける |
| EventBridge Scheduler | 日時（繰り返し・一度きり） | 定期実行、決まった時刻の起動と停止 |
| EventBridge Pipes | 1つの送り元に届いたデータ | キューやストリームを1つの送り先へつなぐ |
SNS・SQS とはどう使い分けるのか
3つとも部品どうしを疎結合にするためのサービスですが、得意な場面が違います。AWS の意思決定ガイドは、SQS を処理の非同期化と負荷の吸収、SNS をファンアウトと一斉の通知、EventBridge をイベント駆動の構成とアカウントをまたいだイベントの共有、に向くものとして分けています。
WHICH ONE3つの使い分け
貯める・配る・振り分けるのどれが要るかで選ぶ
-
貯める
SQS — 仕事を貯めて受け手のペースで処理
負荷の山をならす・非同期にする
-
配る
SNS — 同じ知らせを決まった受け手へ一斉に
ファンアウト・通知
-
振り分け
EventBridge — 出来事の中身で振り分ける
AWS のサービスや SaaS の出来事・アカウントをまたぐ
迷ったときは、次の問いを順に当てると決めやすくなります。
- 受け手が自分のペースで取りに行き、処理しきれない分を貯めておきたいか。そうなら SQS です。
- 同じ知らせを、決まった受け手全員へすぐ配りたいだけか。そうなら SNS です。
- AWS のサービスや SaaS の出来事に反応したい、中身の条件で細かく振り分けたい、アカウントをまたいで集めたいか。そうなら EventBridge です。
実際の構成では組み合わせて使います。EventBridge のルールで「失敗したジョブ」だけを拾い、ターゲットを SQS にして処理の速さをならす、ターゲットを SNS にして担当者へ通知する、といった形です。EventBridge は振り分け役、SQS は貯める役、SNS は配る役と分けて読むと、構成図の矢印の意味が取れます。
CHECK 3ここまでの確認
「毎週月曜の朝 8 時（日本時間）に処理を起動したい」とき、新しく作るなら何を使うのが公式の推奨ですか?
答えと解説
答え: 1. EventBridge Scheduler
定期実行や一度きりの実行は EventBridge Scheduler の役目で、タイムゾーンも指定できます。ルールで組む定期実行は公式ドキュメントで legacy と書かれています。「EventBridge Scheduler と Pipes はどこに位置づくのか」を読み直してください。
使うときに気をつけることは何か
EventBridge で事故になりやすい3つ
- 同じイベントが2回届くことを想定せず、受け手で二重に処理してしまう
- 送れなかったイベントの行き場（デッドレターキュー）を決めず、失敗に気づけない
- パターンを広く書きすぎて、関係ないイベントでターゲットを動かしてしまう
同じイベントが2回届いても壊れない受け手にする
EventBridge は、ターゲットへ少なくとも1回は届けることを目指す仕組みで、同じイベントが複数回届くことがあります。イベントには重複を見分けられる情報が入っているので、受け手の側で「すでに処理した ID なら何もしない」という作り（冪等性）にしておきます。なお、AWS のサービスが出すイベントには、届け方の確かさがサービスやイベントの種類ごとに決まっているものがあり、公式ドキュメントに一覧があります。
送れなかったイベントの行き場を決める
ターゲットが一時的に受け取れないとき、EventBridge は再試行の設定に従って送り直します。それでも届かなかったイベントは捨てられるので、取りこぼしたくないなら、ターゲットごとにデッドレターキュー（SQS のキュー）を指定して受け止めます。処理の不具合を直したあとに同じ期間のイベントを流し直したいときは、イベントを保存しておくアーカイブと、そこからのリプレイが使えます。
2026 年 9 月にカスタムイベントバスが新しい形で出し直された
2026 年 9 月、カスタムイベントバスが新しい形で出し直され、従来のものは Custom Event Bus - Classic と呼ばれるようになりました。デフォルトイベントバスと Classic は、この記事のとおりルールとターゲットで振り分けます。新しいカスタムイベントバスでは、絞り込み・送り先・再試行・デッドレターの指定を Subscriber という1つの単位にまとめ、バス自体にイベントを保持する期間や、届いた順に処理する仕組みが加わっています。再試行の既定値や料金の形、使えるリージョンも従来とは違うので、新しく組むときは公式のユーザーガイドと料金ページで確認してください。
READ ALSO — 学習中向け・段2 構成
Amazon SQS と Amazon SNS とは｜キューとトピック、疎結合とファンアウト
参照ソース
- What is Amazon EventBridge?（Amazon EventBridge ユーザーガイド） — イベントバス・ルール・ターゲットの全体像、Pipes と Scheduler の位置づけ（2026年10月時点の記載）
- Amazon EventBridge event bus (default and Classic)（Amazon EventBridge ユーザーガイド） — AWS のサービスのイベントがデフォルトイベントバスに届くこと、ルールとターゲットによる振り分け、1つのルールに5つまでのターゲット（2026年10月時点の記載）
- EventBridge is the evolution of Amazon CloudWatch Events（Amazon EventBridge ユーザーガイド） — CloudWatch Events との関係と同じ API であること（2026年10月時点の記載）
- Rules in Amazon EventBridge（Amazon EventBridge ユーザーガイド） — ルールとイベントパターンの考え方（2026年10月時点の記載）
- Sending and receiving events between AWS accounts in Amazon EventBridge（Amazon EventBridge ユーザーガイド） — アカウントをまたいだイベントの送受信とリソースベースのポリシー（2026年10月時点の記載）
- How EventBridge retries delivering events（Amazon EventBridge ユーザーガイド） — 再試行とデッドレターキュー（2026年10月時点の記載）
- Delivery level for AWS service events（Amazon EventBridge リファレンス） — 少なくとも1回の配信と重複、AWS のサービスのイベントの届け方（2026年10月時点の記載）
- Creating a scheduled rule (legacy) in Amazon EventBridge（Amazon EventBridge ユーザーガイド） — スケジュールで動くルールが legacy であり、Scheduler が推奨されていること（2026年10月時点の記載）
- What is Amazon EventBridge Scheduler?（EventBridge Scheduler ユーザーガイド） — Scheduler の役割（2026年10月時点の記載）
- Schedule types in EventBridge Scheduler（EventBridge Scheduler ユーザーガイド） — cron 式・rate 式・一度きりの実行とタイムゾーンの指定（2026年10月時点の記載）
- Amazon EventBridge Pipes（Amazon EventBridge ユーザーガイド） — 1対1の連携、絞り込みとエンリッチメント（2026年10月時点の記載）
- Amazon SQS, Amazon SNS, or Amazon EventBridge?（AWS Decision Guides） — 3つのサービスの得意な場面の違い（2026年10月時点の記載）
- What is the EventBridge Custom Event Bus?（Amazon EventBridge ユーザーガイド） — 新しいカスタムイベントバスの Subscriber と保持期間、Classic との違い（2026年10月時点の記載）
- Amazon EventBridge relaunches event buses for enterprise scale（AWS What’s New） — カスタムイベントバスの出し直しの発表（2026年9月の発表）
