Amazon EventBridgeとは ― ルールと定期実行

Amazon EventBridgeは、AWSのサービスや自分のアプリで起きた出来事を受け取るサービスです。受け取った出来事のうち、条件に合うものを指定の宛先へ渡します。S3にファイルが置かれたらLambdaで処理する、EC2が止まったらメールで知らせる、毎朝9時に集計を動かす。AWSでこうした自動化を作るときに使います。

処理どうしを直接つなぐ必要はありません。サーバーレスなので、サーバの用意も要りません。ルールの書き方と定期実行の作り方、SNS・SQSとの使い分けが分かれば、こうした自動化を自分で組めます。CloudWatch Eventsという名前の古い記事も、いまのEventBridgeの話として読めるようになります。

EC2が止まったことを知るには、状態を定期的に調べるプログラムを動かす方法もあります。ただ、調べる処理をずっと動かさなければなりません。止まってから気づくまでに間も空きます。

イベント駆動は逆の作りです。変化が起きた側が知らせを出し、受け取った処理だけが動きます。この知らせをイベントと呼びます。EC2の状態の変化やCloudFormationのスタックの作成が、AWSのドキュメントが挙げるイベントの例です。

EventBridgeのイベントはJSONのデータです。次の例は、EC2インスタンスが止まったときに届くイベントの主な項目です。sourceが送り元、detail-typeが種類で、detailに中身が入ります。

{
  "source": "aws.ec2",
  "detail-type": "EC2 Instance State-change Notification",
  "region": "ap-northeast-1",
  "detail": {
    "instance-id": "i-1234567890abcdef0",
    "state": "stopped"
  }
}

EC2は、誰がこのイベントを受け取るかを知りません。受け取る処理を増やすときも、送る側には手を入れずに済みます。このように相手の状態に左右されない作りを疎結合と呼びます。SQSとSNSの記事でも同じ考え方が出てきます。

EventBridgeの流れは、4つの構成要素で説明できます。イベントを送る側・受け取る場所・振り分ける条件・渡す先の4つです。

どのアカウントにもデフォルトイベントバスが最初からあり、AWSのサービスのイベントはここに自動で届きます。ルールは1つのバスに属し、そのバスに届いたイベントだけを見ます。ルール1つに設定できるターゲットは5つまでです。ルールの数は、既定でバスごとに300までです。

1つのイベントが複数のルールに一致すると、一致したルールがそれぞれのターゲットへ渡します。どのルールにも一致しなければ、EventBridgeは何もしません。

ルールには、届いたイベントの中身で判断するものと、決まった時刻に動くものがあります。中身で判断するルールの条件をイベントパターンと呼びます。次のパターンは、EC2インスタンスがstoppedになったイベントだけを選びます。

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped"]
  }
}

パターンは、イベントと同じ形のJSONで書きます。この例では、source・detail-type・stateの3つがすべて合ったイベントだけが選ばれます。instance-idのように書かなかった項目は、判定に使われません。

次の図で届いたイベントを選ぶと、3つのルールのどれに一致するかが切り替わります。ルールBのように条件を少なくすると、より多くのイベントに一致します。

{
  "source": "aws.ec2",
  "detail-type": "EC2 Instance State-change Notification",
  "detail": { "state": "stopped" }
}

{
  "source": "aws.ec2",
  "detail-type": "EC2 Instance State-change Notification",
  "detail": { "state": "running" }
}

{
  "source": "aws.s3",
  "detail-type": "Object Created",
  "detail": {
    "bucket": {
      "name": "photos"
    }
  }
}

{
  "source": "aws.s3",
  "detail-type": "Object Created",
  "detail": {
    "bucket": {
      "name": "logs"
    }
  }
}

毎日0時にLambdaを動かすような定期実行には、2つの方法があります。1つはイベントバスに作るスケジュールルールで、もう1つはEventBridge Schedulerです。

AWSのドキュメントは、スケジュールルールを古い機能（legacy）と書いています。定期実行に勧めているのはSchedulerです。スケジュールルールも引き続き使えますが、これから作るならSchedulerを選びます。

cron式は、分・時・日・月・曜日・年の6項目を空白で区切って書きます。日と曜日の両方を*にはできないので、片方を?にします。Schedulerでは、式と別にタイムゾーンを指定できます。日本時間の毎日0時なら、式はcron(0 0 * * ? *)で、タイムゾーンはAsia/Tokyoです。

スケジュールルールの時刻はUTC+0です。日本時間の0時はUTCの前日15時なので、式はcron(0 15 * * ? *)になります。この式をタイムゾーンがAsia/TokyoのSchedulerへそのまま写すと、日本時間の15時に動きます。

Schedulerが宛先を呼ぶには、権限を持つ実行ロールが要ります。コンソールで作れば、このロールも自動で用意できます。ロールの考え方はIAMの記事で説明しています。

EC2の状態が変わったら通知する

デフォルトイベントバスに、先ほどのイベントパターンでルールを作ります。ターゲットにはSNSトピックを指定します。このトピックをメールアドレスに購読させると、EC2が止まるたびにメールが届きます。CloudWatchのアラームも、状態が変わるとEventBridgeにイベントを送ります。

S3にファイルが置かれたら処理する

S3は、バケットの設定でEventBridgeへの送信を有効にしたときだけイベントを送ります。有効にすると、作成や削除などのイベントがすべて送られます。そこで、ルールでObject Createdを選びます。ターゲットをLambda関数にすれば、ファイルが置かれるたびに関数が動きます。複数の処理を順に動かしたいなら、AWS Step Functionsのステートマシンもターゲットにできます。

SaaSのイベントで処理を動かす

対応するSaaSのパートナーは、AWSアカウントにイベントソースを作れます。これを受け入れてバスに結びつけると、AWSの外の出来事でも同じようにルールで振り分けられます。逆にAWSの外のHTTPSのAPIを呼ぶときは、API destinationsをターゲットにします。外部のサービスが用意したWebhookのURLへ通知するときも同じです。

セキュリティの検出結果に対応する

GuardDutyなどの検出結果もEventBridgeに届きます。CloudTrailが記録するAPI呼び出しもイベントになります。そのため、特定の操作を検知して知らせることもできます。

3つとも、送る側と受け取る側の間に置くサービスです。次の図は、同じ注文を送ったときの届き方を並べたものです。

EventBridgeでは、イベントの中身を見てルールが宛先を決めます。SNSでは、購読した側が受け取り手になります。SQSでは、受け取る側が自分の都合で取りに行きます。SNSとSQSの違いは、SQSとSNSの記事で流れを1段ずつ確かめられます。

3つは組み合わせて使えます。SNSトピックもSQSキューも、ルールのターゲットに指定できるからです。AWSのFAQは、ルールで必要なイベントに絞り、SNSから多数の宛先へ配る形をよくある構成として挙げています。受け取る処理が止まっていても残しておきたいなら、SQSキューをターゲットにします。

CloudWatch Eventsは、AWSのサービスの出来事をルールで処理する機能でした。EventBridgeは2019年7月に、この仕組みをもとに登場しました。大きく変わったのは、SaaSのパートナーのイベントも受け取れるようになった点です。

EventBridgeはCloudWatch EventsのAPIを使っています。そのため、既存のデフォルトバスやルールはそのまま引き継げました。いまもAWS CLIのコマンド名はaws eventsです。CloudWatch Eventsの旧ガイドのURLを開くと、EventBridgeのユーザーガイドへ転送されます。古い記事のCloudWatch Eventsのルールは、EventBridgeのルールと読み替えて構いません。

名前は似ていますが、Amazon CloudWatchの監視の機能とは別物です。CloudWatchは、数値とログを集めて異常を見つけます。EventBridgeは、届いた出来事を宛先へ渡します。

デフォルトイベントバスのほかに、自分のアプリ用のバスやSaaSのパートナー用のバスも作れます。自作のバスのうち、ルールとターゲットで振り分けるものがあります。AWSのドキュメントでの名前はCustom Event Bus - Classicです。

新しいアプリ向けに、AWSはCustom Event Busから始めることを勧めています。このバスでは、ルールの代わりに購読者を作ります。購読者は条件と宛先を持ち、受け取る側のチームが作ります。イベントも1日から365日の間で保持できます。

EventBridge Pipesは、1つの送り元を1つの宛先につなぐ機能です。多くの送り元と宛先を振り分けるのがイベントバスで、1対1の連携に使うのがPipesです。

ルールを作ったのに宛先が動かないときは、次の点を確かめます。

• イベントパターンの値が、実際のイベントの値と合っているか。
• イベントが届くバスにルールを作ったか。ルールは自分のバスのイベントしか見ません。
• S3のイベントなら、バケットでEventBridgeへの送信を有効にしたか。有効にしてから反映まで約5分かかります。
• EventBridgeにターゲットを呼ぶ権限があるか。
• スケジュールルールなら、時刻をUTC+0で書いたか。

宛先が使えないなどでイベントを届けられないとき、EventBridgeは既定で24時間、最大185回まで届け直します。それでも届かないイベントは捨てられます。権限が足りない、宛先が消えているといったエラーでは、届け直しもしません。こうしたイベントを残しておきたいなら、デッドレターキューとしてSQSの標準キューを設定します。

逆に、ルールが動きすぎることもあります。ターゲットの処理が同じルールに一致するイベントを起こすと、無限に繰り返します。S3のACLの変更を検知して直すルールが、自分の変更でまた動く例をAWSは挙げています。料金も増えるので、パターンはできるだけ細かく書きます。

ルールで振り分けるバスでは、AWSのサービスが自動で送る管理イベントの受信は無料です。同じアカウントのサービスへ渡す分も無料です。S3のように有効にしてから送るイベントは、管理イベントとは別の扱いです。自分のアプリやSaaSのイベントは、件数に応じて料金がかかります。EventBridge Schedulerは、毎月1,400万回の呼び出しまで無料です。

Custom Event Busは、件数ではなくデータ量で料金が決まります。ここに書いた内容は、2026年10月31日に料金ページで確かめたものです。最新の値はEventBridgeの料金ページで確認してください。

• AWS「What Is Amazon EventBridge?」（定義、バスの種類、Pipes、Scheduler）
• AWS「Event bus concepts in Amazon EventBridge」（構成要素の関係、ターゲットとルールの数）
• AWS「Amazon EventBridge event bus (default and Classic)」（複数のルールに一致するときの動き）
• AWS「Amazon EventBridge event patterns」（パターンの形、EC2の例、無限ループの注意）
• AWS「Creating a scheduled rule (legacy)」（スケジュールルールの時刻とバスの制約）
• AWS「What is Amazon EventBridge Scheduler?」（Schedulerの機能と呼び出せる範囲）
• AWS「Schedule types on EventBridge Scheduler」（cron式・rate式・at式とタイムゾーン）
• AWS「How EventBridge retries delivering events」（再試行の既定値）
• AWS「What is the EventBridge Custom Event Bus?」（Custom Event Busの購読者と保持期間）
• AWS「Receiving events from a SaaS partner with Amazon EventBridge」（パートナーのイベントの受け取り方）
• AWS「Using EventBridge」（Amazon S3）（S3から送られるイベント）
• AWS「State change events for Amazon EC2 instances」（EC2のイベントの例）
• AWS「Amazon EventBridge FAQs」（SNSとの使い分け、Schedulerとスケジュールルールの違い）
• AWS「Introducing Amazon EventBridge」（2019年7月11日）（CloudWatch Eventsとの関係）
• AWS「Amazon EventBridge pricing」（料金）