歴史・年表でみるAWSサービス(Amazon EventBridge編) －機能一覧・概要・アップデートのまとめ・入門、Amazon CloudWatch Eventsとの違い－

小西秀和です。
「歴史・年表でみるAWS全サービス一覧－アナウンス日、General Availability(GA)、AWSサービス概要のまとめ－」から始まったAWSサービスを歴史・年表から機能を洗い出してまとめるシリーズの第5弾です(過去、Amazon S3、AWS Systems Manager、Amazon Route 53について書きました)。

今回はAWSサービスのイベント検知、条件に応じた他のAWSサービスへのイベント連携、イベントの生成などをするAmazon EventBridge(旧Amazon CloudWatch Events)について歴史年表を作成してみました。
今回もAmazon EventBridgeの誕生から機能追加やアップデートを追いながら主要機能を現在のAmazon EventBridgeの機能一覧と概要としてまとめています。
これらが、各AWSサービスの機能概要に加えてコンセプトや変わらないもの、変わってきたものを知る手がかりとなればと考えています。
今回の記事の内容は次のような構成になっています。

Amazon EventBridge歴史年表の作成経緯と方法
Amazon EventBridge歴史年表(2016年01月14日～2022年04月07日までのアップデート)
Amazon EventBridgeとAmazon CloudWatch Eventsの違い
現在のAmazon EventBridgeの機能一覧と概要
まとめ

Amazon EventBridge歴史年表の作成経緯と方法

今回、Amazon EventBridgeの歴史年表を作成した経緯は、前身となるAmazon CloudWatch Eventsが2016年に登場して以降、条件に応じたイベント駆動またはスケジュール駆動、イベントの生成といったAWSサービスを使用する様々なオートメーションのトリガーを容易に実現できるようにしてきたため、次のアプローチでAmazon EventBridgeの情報を整理したいと考えたからです。

Amazon EventBridgeの歴史を追いながら、アップデートの変遷を整理する
Amazon EventBridgeの機能一覧と特徴をまとめる

この年表は主に次のブログやドキュメント履歴のAmazon EventBridgeに関する内容を参考にしています。

年表の日付は参考にした資料によってアナウンスや記事投稿のタイミングが違う場合もあったため若干のブレがあります。
掲載している内容は現在のAmazon EventBridgeと関係している主要な機能と概要説明に必要なものに限定しています。
つまり、ここの年表にあるものがAmazon EventBridgeの機能のアップデートの全てではなく、あくまで私がピックアップした代表的なアップデートであることにご注意ください。

Amazon EventBridge歴史年表(2016年01月14日～2022年04月07日までのアップデート)

さて、ここからがAmazon EventBridgeの機能に関する年表です。Amazon EventBridgeの歴史は前身のAmazon CloudWatch Eventsとあわせて本記事執筆時点で6年程度になります。
Amazon EventBridgeでは多くのイベントとイベントルールのターゲットをサポートしていますが、ここに記載しているのはすべてではなく代表的な一部のみを挙げています。

※テーブルは項目名クリックでソートできます。

年月日	概要
2016/01/14	前身となるAmazon CloudWatch EventsがAmazon CloudWatchのイベント通知機能として追加される。
2016/02/24	イベントとしてAmazon EC2 Auto Scalingのライフサイクルフックをサポート。
2016/03/30	イベントルールのターゲットとしてAmazon Simple Queue Service(SQS)をサポート。
2016/04/19	Cron形式、Rate形式で1分単位で指定できるスケジュールされたイベントが定義できるようになる。
2016/09/09	イベントとしてAWS CodeDeployをサポート。
2016/11/14	イベントとしてAmazon EBSをサポート。
2016/11/18	イベントとしてAWS Trusted Advisorをサポート。
2016/11/21	イベントとしてAmazon Elastic Container Service(ECS)をサポート。
2016/12/01	イベントとしてAWS Healthをサポート。
2017/03/07	イベントとしてAmazon EMRをサポート。イベントルールのターゲットとしてAmazon EC2 インスタンスコマンド、AWS Step Functionsステートマシンをサポート。
2017/06/29	クロスアカウントでのイベント送信をサポート。イベントルールのターゲットとしてAWS CodePipeline、Amazon Inspectorをサポート。
2017/08/03	イベントとしてAWS CodeCommit、AWS CodeBuildをサポート。
2017/09/08	イベントとしてAWS CodePipeline、AWS Glueをサポート。イベントルールのターゲットとしてAWS Batchをサポート。
2017/12/13	イベントルールのターゲットとしてAWS CodeBuildをサポート。
2018/06/28	インターフェイスVPCエンドポイント(AWS PrivateLink)を使用してAmazon VPCとAmazon EventBridge間にプライベート接続を確立できるようになる。
2019/03/21	イベントルールにタグ付けができるようになる。
2019/07/11	Amazon EventBridgeがSaaSパートナー連携を追加するなどAmazon CloudWatch Eventsを拡張した形で独立したAWSサービスとしてアナウンスされ、General Availability(GA)となる。
2019/10/07	AWS CloudFormationでAmazon EventBridgeリソースをサポート。
2019/11/21	イベントとしてAmazon Elastic Container Registry(ECR)をサポート。
2019/12/01	スキーマの管理とコードバインディングをサポート。
2020/02/10	イベントルールのイベントパターンにコンテンツベースのフィルタリングが使えるようになる。
2020/02/24	イベントバスにタグ付けができるようになる。
2020/04/30	スキーマレジストリの機能が追加され、OpenAPIをサポート。
2020/09/29	スキーマレジストリでJSON Schema Draft 4をサポート。
2020/10/08	ターゲットの再試行ポリシーとデッドレターキューをサポート。
2020/11/05	イベントのアーカイブと再生の機能をサポート
2020/11/24	イベントバスでサーバーサイド暗号化(SSE)をサポート。
2021/03/03	Amazon EventBridgeイベントをAWS X-Rayでトレースできるようになる。
2021/03/04	API送信先(API Destinations)をサポート。
2021/04/15	イベントバスでクロスリージョンでのイベント送信をサポート。
2021/05/19	同一アカウント、同一リージョンのイベントバス間でイベント送受信できるようになる。
2021/07/15	イベントルールのターゲットとしてAWS Glueワークフローをサポート。
2021/08/30	イベントおよびイベントルールのターゲットとしてEC2 Image Builderをサポート。
2021/09/03	スキーマレジストリでイベントバスのクロスアカウントイベントを検出し、自動追加するクロスアカウントイベント検出機能をサポート。
2021/11/18	イベントとしてAmazon DevOps Guruをサポート。
2022/03/11	Amazon EventBridgeコンソール(AWSマネジメントコンソール)でサンドボックス機能をサポート。
2022/04/07	グローバルエンドポイントをサポート。

Amazon EventBridgeのルーツはAmazon CloudWatchのイベント通知機能であるAmazon CloudWatch Eventsです。
Amazon CloudWatch Eventsとしてのアップデートは主にイベントルールが中心で初期からイベント受信での実行とスケジュールでの実行をサポートし、その上で多くのAWSサービスについてイベントの受信とターゲットとしての送信をサポートしています。
Amazon EventBridgeとして一つのAWSサービスとして独立してからはイベントルールでのAWSサービスのサポートに加えて、SaaSパートナー連携、API送信先、イベントバス、アーカイブと再生、グローバルエンドポイント、スキーマレジストリ、サンドボックスといった新しい機能追加もされてきています。

Amazon EventBridgeとAmazon CloudWatch Eventsの違い

Amazon EventBridgeは前述の年表で記載したようにAmazon CloudWatchの一部であったAmazon CloudWatch Eventsの機能を拡張して作られています。
Amazon CloudWatch Eventsは当初からAWS SDK、AWS CLIのサービス名はevents(CloudFormationはAWS::Events)として提供されており、Amazon EventBridgeとAmazon CloudWatch EventsのSDK、CLI、CloudFormationの記述は同様です。
そのため、events(CloudFormationはAWS::Events)のサービス名で使用していればAmazon CloudWatch EventsのAPI、CLI、SDK、CloudFormationを使用していた場合でもAmazon EventBridgeに移行するために記述を変更するといった作業は特に必要ありません。
ただし、SDKではクラス名がCloudWatchEventsからEventBridgeに変更されているため、clientをeventsで呼び出す場合は影響はありませんが、クラス名のレベルから使用しているような場合はSDKアップデートに伴い名称変更が必要になります。

Amazon CloudWatch Eventsが持っていた主な機能は後述するAmazon EventBridgeのイベントルール(Event Rule)およびイベントバス(Event Bus)の一部の機能になります。
Amazon EventBridgeではAmazon CloudWatch Eventsのイベントルール(Event Rule)、イベントバス(Event Bus)を拡張して引き継ぎ、加えてSaaSパートナー連携、API送信先(API Destinations)、アーカイブ(Archive)と再生(Replay)、グローバルエンドポイント(Global Endpoints)、スキーマレジストリ(Schema Registries)、サンドボックス(Sandbox)といった機能が新たに追加されています。

現在のAmazon EventBridgeの機能一覧と概要

ここからは現在のAmazon EventBridgeの機能一覧と概要を紹介します。

イベント(Event)

Amazon EventBridgeはAWSサービスから発生したイベントの検知、ルールの条件に応じた他のAWSサービスへのイベント連携、独自のカスタムイベントの生成などイベントの検知、制御、操作をするAWSサービスです。
イベントはAWSで共通したトップレベルフィールドと構造を持ち、一部のトップレベルフィールド配下のフィールドをカスタマイズして状態を知らせるJSONオブジェクトです。
AWSサービスから発生するイベントはAWSの環境に変更があったことを知らせるもので、AWSサービスのリソースで状態が変化した場合に生成されます。
一方でカスタムイベントはイベントの共通フィールド構造の中にユーザーが独自のフィールドとデータを入れてイベントを生成します。

Amazon EventBridgeでサポートされているAWSサービスのイベントは非常に多いため次のリンクを参照してください。
Events from AWS services - Amazon EventBridge

イベントパターン

イベントの共通フィールド構造についてJSONオブジェクトの例を示します。
後述するカスタムイベントで変更可能な部分については(カスタマイズ可能)という表記で記載します。

{
  "version": "＜イベントバージョン：本記事執筆時点では「0」が入る＞",
  "id": "＜イベントID：「12345678-1234-1234-1234-123456789012」の形式でIDが入る＞",
  "detail-type": "＜イベント詳細タイプ：イベントの概要を示す文字列が入ることが多い(カスタマイズ可能)＞",
  "source": "＜イベントソース：AWSサービスで発生するイベントのソースは「aws.XXXXX」の形式(カスタマイズ可能)＞",
  "account": "＜イベントが生成されたAWSアカウントID：「123456789012」の形式＞",
  "time": "＜イベントが生成された時刻(UTC)：「YYYY-MM-DDThh:mm:ssZ」の形式(カスタマイズ可能)＞",
  "region": "＜イベントが生成されたリージョン文字列：「ap-northeast-1」など＞",
  "resources": [＜イベントの対象リソース：対象リソースが存在する場合は文字列の配列形式で入る(カスタマイズ可能)＞],
  "detail": {
    ＜イベント詳細：各AWSサービスで形式が異なるフィールド(カスタマイズ可能)＞
  }
}

次にAmazon S3のPutObjectアクションで発生するイベントサンプルを示します。

{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "Object Created",
  "source": "aws.s3",
  "account": "123456789012",
  "time": "2022-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": ["arn:aws:s3:::hidekazu-konishi.com"],
  "detail": {
    "version": "0",
    "bucket": {
      "name": "hidekazu-konishi.com"
    },
    "object": {
      "key": "index.html",
      "size": 10,
      "etag": "12345678901234567890123456789012",
      "version-id": "12345678901234567890123456789012",
      "sequencer": "123456789012345678"
    },
    "request-id": "1234567890123456",
    "requester": "123456789012",
    "source-ip-address": "10.0.0.1",
    "reason": "PutObject"
  }
}

カスタムイベントの送信

カスタムイベントはイベントの共通フィールド構造の中にユーザーが独自のフィールドとデータを入れてイベントを生成します。
AWSサービスから発生するイベントは主にAWSリソースの状態の変化を示しますが、カスタムイベントは目的に応じて様々な用途に使用できます。
カスタムイベントはAWS CLI、AWS SDKを使用したAPI経由で生成します。
次にAWS CLIのput-eventsコマンドでカスタムイベントを送信する場合のJSONパラメーターの形式を記述します。
パラメーターの一つであるEventBusNameで指定するイベントバス(Event Bus)については後述します。

[
  {
    "Time": "＜RFC3339準拠形式のタイムスタンプ。指定しない場合は送信時刻が使用される。＞",
    "Source": "＜任意の文字列。AWSサービスが使用する「aws.XXXXX」に倣えば、「＜英数小文字＞.＜英数小文字＞.～」の形式となる。＞",
    "Resources": [
      "＜リソース名。配列内に複数指定可能。指定しない場合は空の配列として送信される。＞",
      ...
    ],
    "DetailType": "＜任意の文字列。AWSサービスが使用するDetailTypeに倣えば、イベントの概要を表す文字列となる。＞",
    "Detail": "＜任意のJSON文字列。このパラメーター自体がJSON内にあるためダブルクォーテーションはエスケープが必要。＞",
    "EventBusName": "＜カスタムイベントを送信するEventBusNameまたはEventBus ARNを記述する。指定しない場合はdefaultのイベントバスが使用される。＞",
    "TraceHeader": "X-Rayを使用する場合はTracing headerを指定する。"
  },
  ...
]

次にJSONファイルにカスタムイベントのJSONパターンを記述し、AWS CLIのput-eventsコマンドでJSONファイルからカスタムイベントを生成する例を示します。

[ho2k_com@ho2k-com ~]$ vi entries.json
[ho2k_com@ho2k-com ~]$ cat entries.json
[
  {
    "Time": "2022-01-01T00:00:00Z",
    "Source": "custom.sample",
    "Resources": [
      "sample-resource-a",
      "sample-resource-b"
    ],
    "DetailType": "Custom Sample Event",
    "Detail": "{ \"sample-parameter-key1\": \"sample-parameter-value1\", \"sample-parameter-key2\": \"sample-parameter-value2\" }",
    "EventBusName": "arn:aws:events:ap-northeast-1:123456789012:event-bus/CustomSampleEventBus"
  }
]
[ho2k_com@ho2k-com ~]$ aws events put-events --entries file://entries.json

そして、このAWS CLIをAWSアカウント123456789012のap-northeast-1リージョンで実行した場合に発生するカスタムイベントのJSON例は次のようになります。

{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789000",
  "detail-type": "Custom Sample Event",
  "source": "custom.sample",
  "account": "123456789012",
  "time": "2022-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": ["sample-resource-a", "sample-resource-b"],
  "detail": {
    "sample-parameter-key1": "sample-parameter-value1", 
    "sample-parameter-key2": "sample-parameter-value2"
  }
}

イベントバス(Event Bus)

イベントバス(Event Bus)はイベントを受信するパイプラインで、後述するイベントルールは関連付けられたイベントバスに送信されたイベントをルールに基づいて処理します。
イベントバスには最初から用意されているdefaultのイベントバスとユーザーが独自に作成するカスタムイベントバスがあります。
前述したようにカスタムイベントは送信するイベントバスを指定できますが、イベントバスを指定しないイベントはイベントが発生したアカウント・リージョンにあるdefaultのイベントバスにすべて送信されます。
つまり、defaultのイベントバスだけを使用しているとイベントルールで評価対象としたいイベント以外が送信されてくることもあるため、不要なイベントが受信されたり、不要なイベントを制御するためにイベントルールの記述が複雑になったりするなどの問題が発生することもあります。
そのため、イベントルールで評価対象としているイベントだけを受信するなど目的や機能に応じてカスタムイベントバスを作成します。

イベントルール(Event Rule)

イベントルールにはイベント受信で実行するタイプとスケジュールで実行するタイプがあります。

イベント受信で実行するタイプのイベントルール

イベント受信で実行するタイプは、関連づいているイベントバスから受信したイベントが定義したイベントパターンに一致した場合に後述するターゲットにイベントを送信します。
イベント受信で実行するタイプのイベントルールについて、例としてイベントパターン定義と評価対象のイベントサンプルを並べてみると次のようになります。
ここで例示した評価対象のイベントサンプルはイベントパターン定義例に一致するようになっています。

評価対象のイベントサンプル	イベントルールのイベントパターン定義例
{ "version": "0", "id": "12345678-1234-1234-1234-123456789012", "detail-type": "Object Created", "source": "aws.s3", "account": "123456789012", "time": "2022-01-01T00:00:00Z", "region": "ap-northeast-1", "resources": ["arn:aws:s3:::hidekazu-konishi.com"], "detail": { "version": "0", "bucket": { "name": "hidekazu-konishi.com" }, "object": { "key": "index.html", "size": 10, "etag": "12345678901234567890123456789012", "version-id": "12345678901234567890123456789012", "sequencer": "123456789012345678" }, "request-id": "1234567890123456", "requester": "123456789012", "source-ip-address": "10.0.0.1", "reason": "PutObject" } }	{ "source": [ "aws.s3" ], "detail-type": [{ "anything-but": [ "AWS API Call via CloudTrail" ] }], "detail": { "bucket": { "name": [{ "anything-but": { "prefix": "www." } }] }, "object": { "key": [{ "prefix": "index." }], "size": [{ "numeric": [">", 0] }] }, "source-ip-address": [{ "cidr": "10.0.0.0/24" }], "reason": [{ "exists": true }] } }

評価対象のイベントサンプル

イベントルールの
イベントパターン定義例

{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "Object Created",
  "source": "aws.s3",
  "account": "123456789012",
  "time": "2022-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": ["arn:aws:s3:::hidekazu-konishi.com"],
  "detail": {
    "version": "0",
    "bucket": {
      "name": "hidekazu-konishi.com"
    },
    "object": {
      "key": "index.html",
      "size": 10,
      "etag": "12345678901234567890123456789012",
      "version-id": "12345678901234567890123456789012",
      "sequencer": "123456789012345678"
    },
    "request-id": "1234567890123456",
    "requester": "123456789012",
    "source-ip-address": "10.0.0.1",
    "reason": "PutObject"
  }
}

{
  "source": [
    "aws.s3"
  ],
  "detail-type": [{
    "anything-but": [
      "AWS API Call via CloudTrail"
    ]
  }],
  "detail": {
    "bucket": {
      "name": [{
        "anything-but": {
          "prefix": "www."
        }
      }]
    },
    "object": {
      "key": [{
        "prefix": "index."
      }],
      "size": [{
        "numeric": [">", 0]
      }]
    },
    "source-ip-address": [{
      "cidr": "10.0.0.0/24"
    }],
    "reason": [{
      "exists": true
    }]
  }
}

この例で使用したコンテンツフィルタリングの方法について説明します。

単純なマッチングによるコンテンツのフィルタリング

まず、フィールドの値に単純に一致するかどうかを定義する記述は、上記の例では次の部分が該当します。
パターンマッチングの記述の方法は評価対象のフィールドの値の部分に配列の形式で条件となる文字列を入力します。

  "source": [
    "aws.s3"
  ],

次に、上記の例を参照しながらコンテンツフィルタリングをする"prefix"、"anything-but"、"numeric"、"cidr"、"exists"が意味する評価方法を見ていきます。

「prefix」によるコンテンツのフィルタリング

フィールドの値に"prefix"を使用すると、指定した文字列のプレフィックスが一致すること(前方一致すること)を定義できます。
上記の例では次の部分が該当し、「index.」と前方一致することを示します(index.html, index.php, index.doなどが一致する)。

    "object": {
      "key": [{
        "prefix": "index."
      }],

「anything-but」によるコンテンツのフィルタリング

フィールドの値に"anything-but"を使用すると、指定した値以外のすべてに一致することを定義できます。
上記の例では次の部分が該当し、「AWS API Call via CloudTrail」以外の値が一致することを示します(Object Created、Object Deletedなどが一致する)。

  "detail-type": [{
    "anything-but": [
      "AWS API Call via CloudTrail"
    ]
  }],

「prefix」と「anything-but」によるコンテンツのフィルタリング

また、"prefix"と"anything-but"を複合的に使用することもできます。
上記の例では次の部分が該当し、「www.」と前方一致しない文字列が一致することを示します(en.、api.で始まるものなどが一致する)。

    "bucket": {
      "name": [{
        "anything-but": {
          "prefix": "www."
        }
      }]
    },

「numeric」によるコンテンツのフィルタリング

フィールドの値に"numeric"を使用すると、値が数値の場合に比較演算子による比較結果が真の場合に一致することを定義できます。
上記の例では次の部分が該当し、数値が0より大きい場合に一致することを示します(比較演算子は"="、">"、"<"、">="、"<="が使用できます)。

      "size": [{
        "numeric": [">", 0]
      }]

「cidr」によるコンテンツのフィルタリング

フィールドの値に"cidr"を使用すると、指定したIPv4アドレスとIPv6アドレスのCIDR形式に一致することを定義できます。
上記の例では次の部分が該当し、「10.0.0.0/24」のCIDR範囲に一致することを示します(10.0.0.0～10.0.0.255は一致する)。

    "source-ip-address": [{
      "cidr": "10.0.0.0/24"
    }],

「exists」によるコンテンツのフィルタリング

フィールドの値に"exists"を使用すると、値の存在有無の評価を定義できます。
上記の例では次の部分が該当し、値が存在する場合に一致することを示します("exists": falseの場合は存在しない場合に一致)。

    "reason": [{
      "exists": true
    }]

イベント受信で実行するタイプのイベントルールはこのようにイベントパターンを定義して、受信したイベントを評価して一致する場合に、後述するターゲットへ受信したイベントやカスタマイズしたイベントを送信できます。

スケジュールで実行するタイプのイベントルール

スケジュールで実行するタイプは、Cron形式またはRate形式で定義したスケジュールに従って後述するターゲットにイベントを送信します。

Cron形式の記述方法について

Cron形式のフォーマットは次のようになります。

cron(＜分＞ ＜時間＞ ＜日＞ ＜月＞ ＜曜日＞ ＜年＞)

Cron形式の表記をいくつか例示します。

cron(0/15 * * * ? *) # 15分毎に実行。
cron(0/15 0-9 * * ? *) # 0:00-9:45(UTC+0)[日本時間で9:00-18:45(UTC+9, JST)]まで15分毎に実行。
cron(0 0 * * ? *) # 毎日0:00(UTC+0)[日本時間で毎日9:00(UTC+9, JST)]に実行。
cron(0 0 1 * ? *) # 毎月1日0:00(UTC+0)[日本時間で毎月1日9:00(UTC+9, JST)]に実行。
cron(0 15 L * ? *) # 毎月末日15:00(UTC+0)[日本時間で毎月1日00:00(UTC+9, JST)]に実行。
cron(0 0 ? * MON-FRI *) # 月曜か金曜まで毎日0:00(UTC+0)[日本時間で月曜日から金曜日まで毎日08:00(UTC+9, JST)]に実行。
cron(0 23 ? * SUN-THU *) # 日曜から木曜まで毎日23:00(UTC+0)[日本時間で月曜日から金曜日まで毎日08:00(UTC+9, JST)]に実行。

注意するべき点はEventBridgeで扱う時刻はUTCであり日本時間(JST)ではないことです。
また、Cron形式の表記に関しては「曜日」を指定する場合は「日」は「?」となり、「日」を指定する場合は「曜日」は「?」となることに注意が必要です。

Rate形式の記述方法について

Rate形式のフォーマットは次のようになります。

rate(＜値＞ ＜単位＞)

使用可能な単位はminute、minutes、hour、hours、day、daysです。
Rate形式の表記をいくつか例示します。

rate(5 minutes) # 5分毎に実行
rate(12 hours) # 12時間毎に実行
rate(1 day) # 1日毎に実行
rate(7 days) # 7日毎に実行

スケジュール実行された場合に発生するイベントについて

スケジュールで実行するタイプのイベントルールではスケジュール実行された際にイベントが発生します。
このイベントは後述するターゲットに設定したリソースまたはエンドポイントに送信するイベントに指定できます。
次はスケジュール実行された際に発生するイベントの例です。
"resources"に入っているリソースはスケジュール実行をしたイベントルールのARNです。

{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "Scheduled Event",
  "source": "aws.events",
  "account": "123456789012",
  "time": "2022-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": [
    "arn:aws:events:ap-northeast-1:123456789012:rule/SampleEventRule"
  ],
  "detail": {}
}

スケジュールで実行するタイプのイベントルールはこのようにCron形式またはRate形式でスケジュールを定義して、後述するターゲットへスケジュール実行イベントまたはカスタマイズしたイベントを送信できます。

ターゲット(Targets)

ターゲットはイベントルールからイベントを送信するリソースまたはエンドポイントです。
ターゲットにイベントが送信される条件はつぎにになります。

イベント受信で実行するタイプのイベントルールで定義したイベントパターンが、イベントバスから受信したイベントと一致する
スケジュールで実行するタイプのイベントルールで定義したスケジュールが、年月日・時刻と一致する

ターゲットに送信するイベントは次のようにカスタマイズしたイベントを送信できます。

イベント受信で実行するタイプのイベントルールの場合は、イベントパターン定義と一致したイベントの全部または一部、定数(JSONテキスト)、入力トランスフォーマーで定義したイベント
スケジュールで実行するタイプのイベントルールの場合は、スケジュール実行イベントの全部または一部、定数(JSONテキスト)、入力トランスフォーマーで定義したイベント

このうち、イベントの全部または一部についてはイベント受信で実行するタイプのイベントルール、スケジュールで実行するタイプのイベントルールの両方でサンプルイベントを紹介したので例示は省略します。
定数(JSONテキスト)はフィールドに対する値が固定のJSONテキストをターゲットにイベントとして送信する方法です。
入力トランスフォーマーについては次項で説明します。

入力トランスフォーマー(Input Transformer)

入力トランスフォーマー(Input Transformer)はイベントルールでイベントパターンに一致したイベント、定数(JSONテキスト)をターゲットに送信する前にJSON構造やフィールドの内容を変換する機能です。
入力トランスフォーマーでは変数名の変換に入力パス(Input Path)、出力するJSON構造の定義にテンプレートを使用します。
入力トランスフォーマーで入力パス、テンプレートを使用してイベントを変換して出力する例を次に示します。

変換前のイベント	入力トランスフォーマー
{ "version": "0", "id": "12345678-1234-1234-1234-123456789012", "detail-type": "Object Created", "source": "aws.s3", "account": "123456789012", "time": "2022-01-01T00:00:00Z", "region": "ap-northeast-1", "resources": ["arn:aws:s3:::hidekazu-konishi.com"], "detail": { "version": "0", "bucket": { "name": "hidekazu-konishi.com" }, "object": { "key": "index.html", "size": 10, "etag": "12345678901234567890123456789012", "version-id": "12345678901234567890123456789012", "sequencer": "123456789012345678" }, "request-id": "1234567890123456", "requester": "123456789012", "source-ip-address": "10.0.0.1", "reason": "PutObject" } }	■入力パス(Input Path) { "bucket_name" : "$.detail.bucket.name", "object_key": "$.detail.object.key", "action" : "$.detail.reason", "datetime" : "$.time" } ■入力トランスフォーマーテンプレート { "bucket_name" : "<bucket_name>", "object_key": "<object_key>", "action" : "<action>", "datetime" : "<datetime>" } ■出力結果 { "bucket_name" : "hidekazu-konishi.com", "object_key": "index.html", "action" : "PutObject", "datetime" : "2022-01-01T00:00:00Z" }

変換前のイベント

入力トランスフォーマー

{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "Object Created",
  "source": "aws.s3",
  "account": "123456789012",
  "time": "2022-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": ["arn:aws:s3:::hidekazu-konishi.com"],
  "detail": {
    "version": "0",
    "bucket": {
      "name": "hidekazu-konishi.com"
    },
    "object": {
      "key": "index.html",
      "size": 10,
      "etag": "12345678901234567890123456789012",
      "version-id": "12345678901234567890123456789012",
      "sequencer": "123456789012345678"
    },
    "request-id": "1234567890123456",
    "requester": "123456789012",
    "source-ip-address": "10.0.0.1",
    "reason": "PutObject"
  }
}

■入力パス(Input Path)

{
  "bucket_name" : "$.detail.bucket.name", 
  "object_key": "$.detail.object.key", 
  "action" : "$.detail.reason", 
  "datetime" : "$.time"
}

■入力トランスフォーマーテンプレート

{
  "bucket_name" : "<bucket_name>",
  "object_key": "<object_key>",
  "action" : "<action>",
  "datetime" : "<datetime>"
}

■出力結果

{
  "bucket_name" : "hidekazu-konishi.com",
  "object_key": "index.html",
  "action" : "PutObject",
  "datetime" : "2022-01-01T00:00:00Z"
}

ターゲットとして利用可能なAWSサービスとAPI送信先(API Destination)

Amazon EventBridgeでサポートされているAWSサービスのターゲットは非常に多いため次のリンクを参照してください。
Amazon EventBridge targets - Amazon EventBridge

このうち、本記事執筆時点でターゲットとして利用可能なAWSサービスとAPI送信先には主に次のものがあります。

サービス名	クロスリージョン送信	クロスアカウント送信
Event Bus	Yes	Yes
API Destinations(API送信先パートナーを含む)	Yes	Yes
API Gateway	Yes	No
Batch Job Queue	No	No
CloudWatch Log Group	No	No
CodeBuild Project	No	No
CodePipeline	No	No
EC2 CreateSnapshot API Call	No	No
EC2 Image Builder	No	No
EC2 RebootInstances API Call	No	No
EC2 StopInstances API Call	No	No
EC2 TerminateInstances API Call	No	No
ECS Task	No	No
Firehose Delivery Stream	No	No
Glue Workflow	No	No
Incident Manager Response Plan	No	No
Inspector Assessment Template	No	No
Kinesis Stream	No	No
Lambda Function	No	No
Redshift Cluster	No	No
SageMaker Pipeline	No	No
SNS Topic	No	No
SQS Queue	No	No
Step Functions state machine	No	No
Systems Manager Automation	No	No
Systems Manager OpsItem	No	No
Systems Manager Run Command	No	No

イベントバスではクロスリージョン、クロスアカウントのイベント送受信が可能です。
クロスリージョン、クロスアカウントのイベント送受信をするには送信側と受信側の両方でポリシーの設定が必要です。
まず、イベントを受信するアカウント・リージョンのEventBusのリソースベースのポリシーでイベントを送信するアカウント・リージョンのイベントルールからのevents:PutEventsを許可します。
次にイベントを送信するアカウント・リージョンのイベントルールに関連づいたIAMロールの許可ポリシーでイベントを受信するアカウント・リージョンのEventBusのARNへのevents:PutEventsを許可します。
受信側と送信側の双方のポリシーでEventBusへのevents:PutEventsアクションが許可されることでクロスリージョン、クロスアカウントのイベント送受信ができるようになります。

API送信先(API Destinations)はAPIをEventBridgeに登録することによりターゲットに指定する機能で、API送信先パートナーが提供するAPIや独自に開発したAPIなどを登録して使用できます。
EventBridgeのAPI DestinationsではAPI認証方式としてベーシック、OAuth、APIキーがサポートされています。
API Destinationsの送信先はAPIとなるためクロスリージョンやクロスアカウントの送信制限はありません。

API Gatewayではクロスアカウント送信の指定はできませんが、AWS CLIやAWS SDKを使用することでクロスリージョンのAPI Gatewayをターゲットに指定することができます(EventBridgeコンソールからは指定不可)。
ただ、Amazon API GatewayもAPI DestinationsにAPIとして登録し、EventBridgeのターゲットに指定することでクロスリージョンに加えてクロスアカウントの送信ができます。

サンドボックス(Sandbox)

サンドボックス(Sandbox)はEventBridgeルールで使用するイベントパターンや入力トランスフォーマー(Input Transformer)をテストするEventBridgeコンソール(AWSマネジメントコンソール)の機能です。
サンドボックス(Sandbox)は主に次の内容をテストできます。

EventBridgeルールで定義するイベントパターンがサンプルイベントや独自に入力したイベントに一致するかしないかをテストする。
入力トランスフォーマー(Input Transformer)で定義するJSON入力パス、テンプレート、出力をサンプルイベントや独自に入力したイベントを使用してテストする。

アーカイブ(Archive)と再生(Replay)

アーカイブ(Archive)は指定したイベントバスで受信したイベントを保存する機能です。
アーカイブするイベントは定義したイベントパターンに一致した場合のみ(またはすべて)保存したり、保存期間(または無制限)を指定したりできます。

アーカイブしたイベントは再生(Replay)できます。
アーカイブしたイベントの再生はイベントバスに関連づいたイベントルールから再生先を指定(またはすべてのルールを指定)したり、再生時間枠の開始時刻と終了時刻によってアーカイブしたイベントの発生時刻の範囲を指定して部分的に再生したりできます。

グローバルエンドポイント(Global Endpoints)

EventBridgeのグローバルエンドポイントはイベントバスを2つのリージョンでフェイルオーバーするフォールトトレランス構成にします。
グローバルエンドポイントを構成するには次の項目を設定します。

プライマリリージョンとセカンダリリージョンのイベントバス
イベントバス名は両リージョンで同一である必要があります。
フェイルオーバーを判断するためのAmazon Route 53ヘルスチェック
Amazon Route 53ヘルスチェックは独自に設定することもできますが、Amazon CloudWatchメトリクスを使用してAWS/Events NamespaceのIngestionToInvocationStartLatencyメトリックで判断するCloudFormationテンプレートが用意されています。
イベントレプリケーションの有効化・無効化
イベントレプリケーションはプライマリリージョンからセカンダリリージョンにイベントを非同期レプリケーションする機能のため、イベントの送信順序は保証されません。

なお、EventBridgeのグローバルエンドポイントには追加料金がかからず、グローバルエンドポイントに送信されたイベントの料金に従って請求されます。

スキーマ(Schemas)とスキーマレジストリ(Schema Registries)

スキーマ(Schemas)はEventBridgeで扱うイベントの構造を定義したものです。
スキーマはAWSサービスによって生成されるイベントが既に用意されていますが、ユーザーがカスタムスキーマを作成して登録することもできます。

スキーマレジストリ(Schema Registries)はEventBridgeに登録するスキーマを分類して整理するための論理的なグループです。
EventBridgeには、AWSイベントスキーマレジストリ、検出されたスキーマレジストリ(Discovered Schema Registry)、カスタムスキーマレジストリが最初から用意されています。
スキーマレジストリもユーザーのカスタムスキーマを登録するために新たに作成できます。

このうち、検出されたスキーマレジストリ(Discovered Schema Registry)にはイベントバスでスキーマ検出(Schema Discovery)を有効化することで自動的に新しく検出されたスキーマが登録されます。

コードバインディング(Code Bindings)

スキーマレジストリに登録したスキーマからはコードバインディング(Code Bindings)をダウンロードできます。
コードバインディングを使用するとIDE等でGolang, Java, Python, TypeScriptといったプログラミング言語による開発をする際にイベントをコード内のオブジェクトとして扱い、検証やオートコンプリート機能などを使うことができます。
コードバインディングはEventBridgeコンソールの他、AWS Toolkit for Visual Studio CodeなどIDEのプラグインからもダウンロードできます。

SaaSパートナーからのイベント受信

SaaSパートナーがAmazon EventBridgeに統合されていれば、SaaSパートナーごとに用意されたイベントパターンを使用してSaaSパートナーが提供するサービスまたはアプリケーションからイベントを受信できます。
SaaSパートナーのイベントを受信するには各SaaSパートナーのウェブサイトなどでパートナーイベントソースを作成し、SaaSパートナー用に作成したイベントバスに関連付けます。
イベントルールを作成するEventBridgeコンソールには選択してカスタマイズできるSaaSパートナーごとのイベントパターンも提供されています。

Amazon EventBridge機能全体の概要図

Amazon EventBridgeの機能の関係を概要図にまとめると次のようになります。

＜参考資料＞
AWS Documentation(Amazon EventBridge)
AWS Documentation(Amazon CloudWatch Events)
Tech Blog with related articles referenced

まとめ

今回はAmazon EventBridgeの歴史年表を作成して、Amazon EventBridgeの機能一覧と概要を見てきました。

Amazon EventBridgeは前身であるAmazon CloudWatchのイベント通知機能として追加されたAmazon CloudWatch Eventsの機能を拡張して登場しました。
Amazon CloudWatch Eventsが持っていたイベントルール(Event Rule)を基に、Amazon EventBridgeではカスタマイズ可能なイベントルール(Event Rule)とイベントバス(Event Bus)やSaaSパートナー連携などの機能が加わり、より柔軟なイベントコントロールと幅広いイベント連携ができるようになっています。
オートメーションのトリガーでもあるイベントドリブン(イベント駆動)、スケジュール実行の両方をカバーしているAmazon EventBridgeはAWSサービスを使用した設計・開発をしていると必ず出会うサービスとも言えます。
そのため、Amazon EventBridgeのアップデートは今後も少なからずAWSを活用したサービスに影響を与えることになるでしょう。
今後も継続的にAmazon EventBridgeがどのような機能を提供していくのかその動向をウォッチしていきたいと思います。

なお、今回の記事の英語版やAmazon EventBridge以外のサービスも含めたAWSサービス全体の歴史年表もありますので、興味がありましたら御覧ください。

Written by Hidekazu Konishi