Amazon EventBridgeのイベントバス、Pipes、Scheduler

Amazon EventBridgeは、AWSサービス、自分で開発したアプリケーション、対応するSaaS（Software as a Service）パートナーが発行するイベントを受け取り、条件に応じてAWS上の処理先へルーティングするサーバーレスサービスです。受信側は関心のあるイベントだけを選んで処理でき、発行側は処理先ごとの接続先を管理せずにイベントを発行できます。

たとえば、オンライン講座の配信システムで、新しいコースの公開イベントを発行するとします。受講者向けの検索インデックス更新、講師への通知、利用状況の集計といった処理をイベントから起動できます。それぞれの処理を独立して追加・変更できるため、システム間の結びつきを弱め、機能ごとの保守や拡張をしやすくなります。

EventBridgeには、大きく分けてイベントバス、EventBridge Pipes、EventBridge Schedulerの機能があります。イベントバスは複数の発行元と処理先をつなぎますが、現在はルールでルーティングする従来型のバスに加えて、保持と購読を組み込んだ新しいカスタムイベントバスも選択できます。Pipesは特定のソースとターゲットを一対一で接続し、Schedulerは時刻や間隔に基づいて処理を起動します。

CloudWatch Eventsから拡張されたイベント連携

EventBridgeはCloudWatch Eventsの機能を引き継ぎ、イベント連携の範囲を広げたサービスです。CloudWatch EventsはAWS環境内で発生するサービスイベントや、cron・rateによる定期実行を扱っていました。EventBridgeでは、それに加えて独自アプリケーションやSaaSパートナーからのイベントを取り込み、イベントパターンによるルーティングを構成できます。

現在、CloudWatch Eventsで作成していたイベントルールもEventBridge上で管理できます。このルール型のイベントバスは、2026年から公式ドキュメントで「Custom Event Bus - Classic」と呼ばれています。新しい「Custom Event Bus」は、イベントを保持して購読者がフィルターや配信先を管理する別のモデルです。既存のClassicバスと新しいカスタムバスは並行して利用でき、機能や設定方式が異なるため区別して設計します。

イベントルールでスケジュールを作る機能は現在も利用できますが、AWSはスケジュール実行の新規設計にEventBridge Schedulerを推奨しています。Schedulerは一回限りの実行、幅広いターゲット操作、再試行や柔軟な配信時間枠を備え、スケジュール専用機能として拡張されています。

イベントバスでイベントを受け取り、ルールで振り分ける

イベントバスはイベントを受信する入口です。発行元はイベントをバスへ送り、バスに関連付けられたルールがイベント内容を評価します。条件に一致すると、ルールは設定されたターゲットへイベントを渡します。

イベントバスの種類とルーティングモデル

イベントバスの発行元による大別は、デフォルト、カスタム、パートナーの3系統です。ただし、現在の「カスタム」にはルール型のCustom Event Bus - Classicと、保持・購読型の新しいCustom Event Busがあります。したがって、構成を選ぶときは「誰がイベントを発行するか」に加えて「ルールとターゲットを使うか、購読リソースを使うか」も確認します。

イベントバス	用途	イベントの主な発行元
デフォルトイベントバス	AWSサービスが発行するイベントを受信し、ルールで処理先へルーティングする	EventBridgeへイベントを送るAWSサービス
Custom Event Bus - Classic	独自イベントをルールとターゲットで振り分ける従来型のカスタムバス	自社アプリケーションや、イベント送信を許可されたAWSアカウント
Custom Event Bus	イベントを保持し、購読者がフィルターと配信先を管理する新しいカスタムバス	自社アプリケーションや、共有先アカウントの発行者
パートナーイベントバス	対応するSaaSパートナーのイベントを受け取る	パートナーが作成するイベントソース

デフォルトイベントバスは各AWSアカウントにあらかじめ存在し、EventBridgeにイベントを送るAWSサービスのイベントを受信します。AWSサービスのすべての操作がイベント化されるわけではないため、連携したいサービスとイベント種別がサポートされているかを確認します。Amazon S3のイベント通知をEventBridgeへ送る場合は、対象バケットのプロパティでEventBridgeへの送信を有効にします。バケットを作成しただけではS3イベントが自動的にEventBridgeへ配信されません。

Custom Event Bus - Classicは、アプリケーションが発行する業務イベントをルールで振り分けたい場合に使います。たとえば、デジタル教材サービスが LessonPublished のようなイベントを発行し、ルールで検索インデックス更新や講師への通知に配信する構成にできます。イベントバスのリソースポリシーを使って、別アカウントからイベントを受け付けることもできます。

新しいCustom Event Busでは、発行者がイベントをバスに送り、利用者が独立したサブスクライバーを作成します。サブスクライバーごとにイベントの絞り込みやターゲットを設定でき、バスにはイベントを保持する機能があります。保持期間内のイベントから配信を開始したり、サブスクライバー単位の順序制御や一時停止・再開を使ったりできるため、再処理や複数アカウントにまたがるイベント共有が必要な組織向けの選択肢です。新しいアプリケーションでは、このカスタムイベントバスを起点に検討するようAWSは案内しています。

Classicバスはイベントを自動保持しません。イベントを後から再生したい場合はアーカイブを構成します。新しいCustom Event BusはClassicとは別のルーティングモデルであり、既存のルールをそのままサブスクライバーとして扱うことはできません。移行時はルールとターゲットをサブスクライバーへ対応づけ、必要に応じて既存Classicバスと新バスを並行稼働させます。

パートナーイベントバスは、対応するSaaSプロバイダーのイベントソースを接続したときに使います。SaaSから届いたイベントもルールでパターン照合し、Lambda関数やキューなどのターゲットへ送れます。

ルールとイベントパターン

デフォルト、パートナー、Classicイベントバスでは、ルールが「どのイベントに反応するか」と「一致したイベントをどこへ送るか」を定義します。新しいCustom Event Busでは、ルールの代わりにサブスクライバーがイベントを絞り込み、配信します。どちらもフィルターパターンを用いますが、Classicではルールにターゲットを関連付け、新しいバスでは利用者がサブスクライバーを作成する点が異なります。

イベントパターンはJSONで記述し、イベントの source、detail-type、detail などのフィールドを条件にできます。ルールやサブスクライバーが一致した場合、配信先へ元のイベント全体を渡すほか、入力の一部を選んだり、ターゲット向けのJSONに変換したりすることもできます。

次のパターンは、特定のCodeBuildプロジェクトでビルドが失敗したイベントを選びます。

{
  "source": ["aws.codebuild"],
  "detail-type": ["CodeBuild Build State Change"],
  "detail": {
    "build-status": ["FAILED"],
    "project-name": ["atlas-catalog-ci"]
  }
}

このルールにより、成功したビルドなど関心のないイベントを除き、対象プロジェクトの失敗だけを通知や調査処理へ送れます。イベントパターンのフィールド名と値は、実際に配信されるイベントのJSON構造に合わせる必要があります。パターンは完全なJSON文法ではなく、EventBridgeの比較演算子や配列の規則に従って評価されます。

ルールのターゲットと配信失敗への備え

Classicルールのターゲットには、Lambda、Amazon SQS、Amazon SNS、Step Functions、Kinesisストリーム、CloudWatch Logsなどを指定できます。1つのルールに複数のターゲットを関連付けられ、同じイベントをそれぞれ異なる処理へ渡せます。また、同じイベントに一致する複数のルールを作れば、複数のアプリケーションへ独立して振り分けられます。新しいCustom Event Busでは各サブスクライバーに1つのターゲットを指定し、別の処理先にはサブスクライバーを追加します。

EventBridgeがターゲットへ配信できない場合、ターゲットごとの再試行ポリシーに従って再試行します。標準の設定では、再試行の上限は最大24時間・185回で、指数バックオフとランダムな待ち時間が使われます。設定した再試行を使い切ったイベントは、デッドレターキュー（DLQ）を構成していなければ破棄されるため、重要なイベントではDLQや失敗メトリクスを含む監視を用意します。ターゲットのリソースポリシーや実行ロールなど、EventBridgeから呼び出す権限の設定も必要です。

EventBridge Pipesで一対一のイベント連携を行う

EventBridge Pipesは、1つのイベントソースと1つのターゲットを結ぶポイントツーポイント連携を構築する機能です。イベントバスのように多くの発行元・購読先の組み合わせをルール群で管理する代わりに、特定の入力元から特定の処理先へ至る一つの経路を定義します。

Pipesでよく使われるソースには、Amazon SQS、Kinesis Data Streams、DynamoDB Streams、Amazon MSK、自己管理Apache Kafka、Amazon MQなどがあります。ターゲットにはLambda、Step Functions、Kinesis、SQS、EventBridgeイベントバスなどが含まれます。利用可能な組み合わせはソースとターゲットごとに異なるため、構築時に公式の対応一覧を確認します。

パイプの途中には、次の処理を必要に応じて組み込めます。

1. フィルタリング: イベントパターンを使い、後続処理に必要なイベントだけを通します。
2. エンリッチメント: イベントを処理して不足情報を補ったり、追加情報を取得したりします。
3. 入力変換: JSONPathなどを使って、ターゲットやエンリッチメントが必要とする形式に整えます。

エンリッチメント先として設定できるのは、AWS Lambda、Step FunctionsのExpressワークフロー、API GatewayのREST API、EventBridge API Destinationsです。エンリッチメントは同期的に呼び出され、その応答を受け取ってからターゲットへの処理を続けます。任意のAWSサービスをエンリッチメントにできるわけではありません。

たとえば、会員登録要求を受け取るSQSキューをソースにし、有効な登録だけをフィルターで選びます。必要に応じてLambdaで会員情報を補い、Step Functionsに渡して歓迎メールや初期設定を進める構成が考えられます。送信元キューのメッセージ形式とターゲットの入力形式が異なる場合は、入力変換で項目を組み替えます。

Pipesの順序と信頼性

イベントソースが順序を保ってPipeへ渡す場合、その順序はパイプ内の処理を通じてターゲットまで維持されます。したがって、「Pipesを使えば常にすべてのイベント順が保証される」という意味ではありません。順序が重要なら、ソース側の順序規則やバッチ設定を含め、利用するソースがどの範囲で順序を保証するかを確認します。

Pipesにはバッチ処理、再試行、ソースに応じたエラー制御があり、失敗時にイベントを保持または退避するための仕組みも利用できます。どのイベントが再試行されるか、チェックポイントがどこまで進むか、DLQを使えるかはソースの種類によって異なります。ソースの可視性タイムアウト、保持期間、シャードなどの設定と合わせて、処理失敗後の再配信を設計します。

イベントを複数ターゲットへ配信したい場合はイベントバスが適しています。Pipesからイベントバスをターゲットにする構成も可能で、その後はイベントバスのルールを使って複数の処理先へファンアウトできます。

EventBridge Schedulerで時刻や間隔に応じて起動する

EventBridge Schedulerは、時刻や繰り返し間隔に基づいてターゲットのAPI操作を呼び出すサーバーレススケジューラーです。サーバー上でcronを動かしたり、実行時刻のたびにアプリケーションから起動要求を送ったりせずに、スケジュールを作成・管理できます。大量のスケジュールを扱えるよう設計されており、数百万件規模のタスクを管理する用途にも向いています。

Schedulerは次のスケジュール形式に対応します。

形式	説明	利用例
rate	指定した分・時間・日単位の間隔で繰り返す	15分ごとにキャッシュの状態を確認する
cron	カレンダーに基づき、指定した日時に繰り返す	毎週決まった曜日に利用状況レポートを作成する
at（一回限り）	指定日時に一度だけ実行する	予約時刻に合わせてイベントを公開する

EventBridge Schedulerは多数のAWSサービスに対するAPI操作をターゲットとして呼び出せます。よく使う操作にはテンプレート化されたターゲットを選び、それ以外はUniversal Target Parameterを使って広い範囲のAWS API操作を指定できます。ターゲットを呼び出すには、Schedulerが引き受ける実行ロールに対象操作の権限を与えます。

配信時刻に幅を持たせる柔軟な時間枠を設定すると、同じ時刻に集中する呼び出しを一定の時間内へ分散できます。Schedulerのcron式ではタイムゾーンを指定でき、サマータイムの変更も考慮できます。一方、秒単位の実行精度は提供されません。秒単位での起動が必要な用途にSchedulerを使うことはできません。

再試行、DLQ、重複を考慮する

Schedulerはターゲットへの配信に失敗したイベントについて、保持期間と最大再試行回数を設定できます。再試行を使い切った場合の保存先として、Amazon SQS標準キューをDLQに指定できます。DLQがなければ配信できなかったイベントを後から調べたり再処理したりする手段が限られるため、業務上重要な実行ではDLQと監視を組み合わせます。

Schedulerの配信は少なくとも1回の実行を想定します。再試行などで同じ処理が複数回呼ばれる可能性があるため、課金処理や通知の作成などは、重複して実行しても意図しない結果にならないよう冪等性を考慮します。Schedulerの再試行やDLQは、ターゲット側で発生した処理失敗をアプリケーションに代わって解決するものではありません。起動後の業務処理のエラーは、ターゲットサービス側の監視や再試行設計も必要です。

EventBridge Schedulerとスケジュールルールの選択

従来のEventBridgeルールでもcron式やrate式による定期実行を作成できます。ただし、スケジュールルールは従来機能として位置付けられており、AWSは新規のスケジュール用途にSchedulerを推奨しています。イベントルールのターゲットを定時に起動したい既存構成は継続利用できますが、一回限りの実行、大量のスケジュール、広いAPIターゲット、リトライ制御や時間枠の設定が必要ならSchedulerを選びます。

要件	適したEventBridge機能
複数のイベント発行元から複数の処理先へ、イベント内容を見て振り分けたい	イベントバスとルール
キューやストリームのイベントを、フィルター・加工しながら特定の処理へ渡したい	EventBridge Pipes
決まった日時や間隔でAWS APIを実行したい	EventBridge Scheduler
一回だけ指定時刻にタスクを起動したい	EventBridge Schedulerのatスケジュール
イベントバスへ届くイベントから定期ルールを実行したい既存構成を維持したい	スケジュールルール（新規のスケジュール用途にはSchedulerを推奨）

試験で押さえる使い分け

イベントバスは、ルールによるフィルタリングとファンアウトを使った多対多のイベント連携を提供します。デフォルト、カスタム、パートナーの各バスはイベントの発行元に応じて選択します。JSONイベントパターンはバス上のイベントを照合し、ルールのターゲットへ処理を渡します。

Pipesは一つのソースから一つのターゲットへ向かう経路を作り、必要に応じてフィルター、エンリッチメント、入力変換を挟みます。順序維持はソースの順序特性を引き継ぐものであり、すべての入力元に共通する絶対的な順序保証ではありません。

Schedulerは時刻または間隔が起点です。cronやrateの繰り返しに加えて一回限りのスケジュールを作れ、広いターゲット選択肢、柔軟な時間枠、再試行、DLQを設定できます。イベントの内容で処理先を分ける要件ならイベントバス、ソースからターゲットへの一対一統合ならPipes、時刻起動ならSchedulerを選ぶと整理できます。

公式ドキュメント

• Amazon EventBridgeのデフォルトイベントバスとCustom Event Bus - Classic
• Amazon EventBridge Custom Event Bus
• Classicから新しいCustom Event Busへの移行
• Amazon EventBridgeイベントパターン
• Amazon EventBridgeルールの再試行とDLQ
• Amazon EventBridge Pipesの概念
• Amazon EventBridge Pipesのエンリッチメント
• Amazon EventBridge Schedulerのスケジュール管理
• EventBridge Schedulerのスケジュール形式
• Amazon S3からEventBridgeへのイベント通知を有効化する
• Amazon EventBridge料金