2026.07.22 インフラ

Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説

Amazon EventBridge（アマゾン イベントブリッジ）は、アプリやAWSサービス、SaaSが出す「イベント」を受け取り、あらかじめ決めたルールに従ってLambdaやSQSなどの届け先へ振り分ける、サーバーレスのイベントバスです。ポイントは、送り手と受け手を直接つながず、間にEventBridgeを挟むことで、システムを疎結合に保てる点にあります。この記事で扱うのは、イベント駆動アーキテクチャの考え方、デフォルト・カスタム・パートナーという3種類のイベントバス、イベントパターンによるフィルタリング、Lambdaなど主要ターゲットと入力変換、1対1統合を担うPipes、定期実行のScheduler、カスタムイベント100万件1ドルと64KB課金の体系、そしてSQS・SNS・Step Functionsといつ使い分けるかの判断です。料金の細部は既存の解説へ譲り、EventBridgeで何ができ、どう組み、いつ選ぶかに絞ります。

目次

まとめ：EventBridgeはイベントで疎結合をつなぐサーバーレスの連携基盤

先に結論を示します。EventBridgeは、送り手と受け手の間に立ち、イベントをルールで振り分けて配る「ルーター」です。EC2の状態変化やS3へのファイル到着といったAWSサービスのイベント、自作アプリが投げるカスタムイベント、SaaSからのパートナーイベントを受け取り、Lambda・SQS・Step Functionsなど多数のターゲットへ、条件に合うものだけを届けます。サーバーの管理は要らず、受けた分だけ課金される従量制です。

向くのは、1つのイベントを複数のサービスへ同時に配りたい、送り手と受け手を疎結合にして片方の変更が他方に波及しないようにしたい、という多対多の連携です。逆に、送った順序を厳密に守りたい単純なキュー処理や、1対1で受け渡すだけの連携では、SQSや直接呼び出しのほうが素直に収まります。まずEventBridgeで配れるかを起点に考え、順序保証や単純さが要るなら別方式へ寄せる、という順序が現実的でしょう。

EventBridgeの基本｜イベント駆動とCloudWatch Eventsとの関係

EventBridgeを理解する近道は、「イベントを中心に組む」という発想と、その中を流れる部品の役割をつかむことです。ここでは全体像から入ります。

イベントバス・ルール・ターゲットというEventBridgeの3つの構成要素

EventBridgeの中心は、イベントバス・ルール・ターゲットの3つです。イベントバスは、イベントを受け取る入口となるルーターを指します。ルールは、流れてきたイベントのうち「どれを」「どこへ」送るかを決める設定で、後述するイベントパターンで対象を絞り込む役割です。ターゲットは、ルールに合致したイベントの届け先で、Lambda関数やSQSキュー、Step Functionsのステートマシンなどを指定します。送り手はイベントをバスへ投げるだけ、受け手はルール経由で必要なイベントだけを受け取る、という分業がEventBridgeの基本形です。1つのイベントを複数のルールで受け、それぞれ別のターゲットへ配ることもできます。

CloudWatch Eventsから拡張された経緯と現在の位置づけ

EventBridgeは、もともとCloudWatch Eventsとして提供されていた機能を土台に、外部SaaSやカスタムアプリのイベントも扱えるよう拡張されたサービスです。そのため、CloudWatch Eventsで作ったルールやAPIは現在もEventBridge側でそのまま動きます。既存のCloudWatch Eventsの設定を引き継ぎつつ、新しくSaaS連携やカスタムバスを足していける、という互換性の高さが実務では効きます。ドキュメントやコンソールの表記もEventBridgeへ寄せられているため、新規に組むならEventBridgeの名前で設計するのが素直です。

イベントバスとルーティング｜3種類のバスとパターンによる振り分け

どのイベントを、どのバスで受け、どう絞り込むか。ここがEventBridgeの設計で最初に決める部分です。

デフォルト・カスタム・パートナーという3種類のイベントバスの使い分け

イベントバスには3種類あります。デフォルトバスは、各アカウントに最初から用意されているバスで、EC2やS3などAWSサービスが出す管理イベントはここへ流れ込む既定の入口です。カスタムバスは、自作アプリのイベント（カスタムイベント）を受けるために自分で作るバスで、業務ドメインごとにバスを分けて管理する用途に向きます。パートナーバスは、Salesforceなど連携済みのSaaS（パートナー）が出すイベントを受け取る専用のバスです。設計の目安として、自社アプリのイベントはドメイン単位でカスタムバスに集約し、AWSサービス起因のイベントはデフォルトバスで受ける、という分け方が管理しやすくなります。

イベントパターンによる内容ベースのフィルタリングとターゲット指定

ルールの核になるのがイベントパターンです。これは、イベントのJSON本文の中身（たとえば「source が aws.s3」「detail.state が terminated」など）を条件にして、合致したイベントだけをターゲットへ流す仕組みを指します。件名やトピック単位ではなく、本文の任意フィールドで絞り込める点が、内容ベースのフィルタリングと呼ばれるゆえんです。1つのルールに複数のターゲットを指定でき、届ける前にイベントの一部を抜き出して形を変える入力変換（Input Transformer）も設定できます。PutEvents APIで投げたカスタムイベントも、同じくパターンで振り分けられる対象です。まず「どのフィールドで判定するか」を決めると、ルール設計の見通しが立ちます。

ターゲットとPipes・Scheduler｜配信先と1対1統合・定期実行の役割

イベントの届け先と、バスとは別系統の2つの機能（PipesとScheduler）を押さえると、EventBridgeで組める範囲が見えてきます。

Lambda・SQS・Step Functionsなど主要ターゲットと配信の考え方

ターゲットとして指定できるサービスは幅広く、Lambda関数、SQSキュー、SNSトピック、Step Functionsのステートマシン、Kinesis Data Streams、ECSタスク、さらにHTTPエンドポイントを叩くAPI Destinationsなどが選べます。イベント処理を関数で行うならLambda、受けたイベントを一旦ためて非同期にさばくならSQS、複数ステップの処理を組むならStep Functions、という当て方が基本です。SQSやLambdaと組み合わせた非同期処理の具体的な組み方はSQS・Lambda・EventBridgeを用いた非同期処理の解説で実装例を追えます。配信に失敗したイベントを取りこぼさないよう、ターゲットごとにデッドレターキュー（DLQ）とリトライを設定しておくのが実務の定石です。

EventBridge Pipesが担う単一ソースから単一ターゲットの1対1統合

Pipesは、イベントバスとは別に用意された1対1統合の仕組みです。1本のパイプが、単一のソースからイベントを受け、途中でフィルタやエンリッチ（外部データの付加）を挟み、単一のターゲットへ届けます。ソースにはDynamoDB Streams、Kinesis、SQS、Amazon MQといったストリーム/キュー系を指定でき、これまでLambdaで橋渡しを自作していた「ストリームを読んで別サービスへ流す」処理を、コードなしで組めます。バスが多対多のルーターなのに対し、Pipesは点と点をつなぐ配管、と役割で覚えると混同しません。パイプのターゲットにイベントバスを指定して、両者を組み合わせる構成もよく使われます。

EventBridge Schedulerによる定期実行と1回限りのタスク管理

Schedulerは、時刻や間隔をきっかけにターゲットを呼び出す、スケジューリング専用の機能です。cron式やrate式で「毎日9時」「5分ごと」といった繰り返しを定義でき、特定日時の1回限り実行も設定できます。指定時刻の前後で実行を許容する柔軟な時間枠、リトライ上限、失敗時の最大保持時間なども個別に決められる点も特徴です。従来はルールのスケジュール機能で定期実行を組んでいましたが、大量のスケジュールを一元管理するならSchedulerが向きます。設定項目や制限の詳細はAmazon EventBridge Schedulerの解説で確認できます。

料金とスキーマ｜従量課金の課金要素とスキーマレジストリの役割

EventBridgeは受けたイベントの量で課金される従量制です。何にいくらかかるかの骨格と、イベント構造を扱う補助機能を整理します。

カスタムイベント100万件1ドルと64KB課金・AWSイベント無料の体系

課金の中心はイベントの取り込み量です。自作アプリが投げるカスタムイベントは、取り込み100万件あたり1.00ドル（2026年時点）で、同一アカウント内のターゲットへの配信は追加料金がかかりません。一方、EC2やS3などAWSサービスがデフォルトバスへ出す管理イベントの取り込みは無料です。課金の単位には注意が必要で、料金は「ペイロード64KBごとに1イベント」として数えられるため、大きなイベントは複数件分として計上されます。別アカウントへの配信やパートナーイベント、Pipes（100万リクエスト0.40ドル）、Scheduler（月1,400万呼び出しまで無料）など要素ごとに単価が分かれる仕組みです。無料になる条件や64KB課金でつまずきやすい点はAmazon EventBridgeの料金の解説に詳しく、コスト試算はそちらを土台にすると精度が上がります。

スキーマレジストリと検出によるイベント構造の自動把握とコード生成

スキーマレジストリは、イベントのJSON構造（どんなフィールドがどの型で入るか）を登録・管理する機能です。スキーマ検出（Schema Discovery）を有効にすると、バスを流れるイベントから構造を自動で拾い上げてレジストリへ登録してくれます。登録済みのスキーマからは、JavaやPythonなどのコードバインディングを生成でき、イベントを型付きオブジェクトとして扱えるため、フィールド名のタイプミスを実装段階で減らせます。検出は月500万件の取り込みまで無料で、超過分は100万件1.00ドル（8KB単位・2026年時点）です。多数のカスタムイベントを扱い、開発者間でイベント仕様を共有したいチームで効いてきます。

EventBridgeとSQS・SNS・Step Functionsの違いと使い分けの基準

似た用途のサービスと並べると、EventBridgeの持ち場がはっきりします。役割の差で切り分けます。

SQS・SNSとの違い｜キュー/通知とイベントルーターの役割差

SQSはメッセージを一時的にためて1つの受け手が順に取り出すキュー、SNSは1つのメッセージを購読者へ一斉配信するトピック（プッシュ通知）です。これに対しEventBridgeは、イベントの中身を見て条件に合う届け先だけへ振り分けるルーターという違いがあります。内容ベースのフィルタリングや、AWSサービス/SaaSからのイベント取り込み、入力変換が要るならEventBridgeが向きます。単純に処理をためてワーカーへ渡すだけならSQS、同報通知だけならSNSで足りるはずです。実際には、EventBridgeで振り分けた先にSQSを置いてバッファリングする、といった併用も定番です。

Step Functionsとの違い｜ワークフロー制御とイベント配信の分担

Step Functionsは、複数ステップの処理順序・分岐・リトライを1つのステートマシンとして制御するワークフローエンジンです。EventBridgeはあくまでイベントを配るところまでを担い、配った先の多段処理はStep Functionsに任せる、という分担になります。たとえば「注文イベントを受けたら、在庫確認→決済→通知の順に処理する」なら、EventBridgeがイベントを受けてStep Functionsを起動し、Step Functionsが各ステップを制御する構成です。イベントの受配信はEventBridge、処理フローの管理はStep Functions、と層を分けて設計すると役割が混ざりません。

EventBridgeを採用すべき条件と見送って別方式に寄せる場面

ここは言い切ります。EventBridgeはすべての連携で正解になるわけではありません。向く条件と、あえて選ばない場面を分けて示します。

EventBridgeの採用が向く条件｜多対多のイベント配信と疎結合な連携

効果が出るのは、1つのイベントを複数のサービスへ同時に配りたい、送り手と受け手を切り離して片方の変更が他方に波及しないようにしたい、という多対多かつ疎結合な連携です。マイクロサービス間のイベント連携、AWSサービスの状態変化をトリガーにした自動処理、SaaSのイベントを起点にした業務連携などが典型で、サーバーを持たずに配信の土台を作れます。イベント駆動でAWS上のシステムを設計・実装したい、既存のバッチ連携をイベント起点へ組み替えたい、といった相談はAWSを含むインフラ構築の受託で受け付けています。設計から運用までを外部に任せたい場合の入口です。

見送るべき場面｜厳密な順序保証や単純な1対1の受け渡しのケース

逆に見送ったほうがよい場面もあります。イベントの到着順を厳密に守りたい処理では、EventBridgeは配信順を保証しないため、FIFOキュー（SQS FIFO）やKinesisのように順序性を持つ仕組みを選ぶ判断です。また、送り手と受け手が固定の1対1で、フィルタリングも同報も要らない単純な受け渡しなら、SQSへ直接入れるかサービスを直接呼び出すほうが構成がシンプルで済みます。ミリ秒単位の低遅延が要求されるリアルタイム処理も、配信のわずかな遅延が問題になりうるため設計を要確認です。判断の順序としては、まず多対多・疎結合・内容フィルタが要るかを確かめ、当てはまらなければ別方式へ寄せる、という進め方が堅実です。

よくある質問

EventBridgeの料金や他サービスとの違いなど、導入前に迷いやすい点をまとめます。

Amazon EventBridgeとCloudWatch Eventsは何が違いますか？

EventBridgeはCloudWatch Eventsを拡張したサービスで、AWSサービスのイベントに加えて、自作アプリのカスタムイベントやSaaSのパートナーイベントも扱えるようになったものです。CloudWatch Eventsで作ったルールやAPIはEventBridgeでもそのまま動くため、新規に組むならEventBridgeの名前で設計すれば問題ありません。

EventBridgeの料金はどのくらいかかりますか？

自作アプリのカスタムイベントは取り込み100万件あたり1.00ドル、AWSサービスがデフォルトバスへ出す管理イベントの取り込みは無料です（2026年時点）。料金はペイロード64KBごとに1イベントとして数えられます。無料になる条件や64KB課金の細部は料金専用の解説で確認するのが確実です。

EventBridgeとSQSはどう使い分けますか？

イベントの中身を見て複数の届け先へ振り分けたい、AWSサービスやSaaSのイベントを取り込みたいならEventBridgeが向きます。単純にメッセージをためて1つのワーカーが順に処理するだけならSQSで足ります。EventBridgeで振り分けた先にSQSを置いてバッファリングする併用も定番です。

EventBridge PipesとEventBridgeのバスは何が違いますか？

バスは多数のソースから多数のターゲットへイベントを振り分けるルーターで、Pipesは単一ソースから単一ターゲットへつなぐ1対1統合です。DynamoDB StreamsやSQSを読んで別サービスへ流す配管をコードなしで組めるのがPipesで、途中でフィルタやエンリッチを挟めます。両者を組み合わせる構成もよく使われます。

定期実行のスケジュールはEventBridgeで組めますか？

組めます。EventBridge Schedulerを使えば、cron式やrate式で繰り返し実行を、あるいは特定日時の1回限り実行を設定できる仕組みです。柔軟な時間枠やリトライ、失敗時の保持時間も指定できます。大量のスケジュールを一元管理する用途に向いており、設定の詳細はScheduler専用の解説で追えます。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る