注意事項
- 本記事は「いのべこ 夏休みアドベントカレンダー 2021」の7日目の記事です。記事の掲載内容は私自身の見解であり、所属する組織を代表するものではありません（お約束）。
- また最近よく使うAmazon EventBridgeについて知ったことや知りたいことを調べて書き残しておくための記事です。過度な期待はご遠慮ください。
Amazon EventBridgeとは何か
タイトル回収
Amazon EventBridgeとは、簡単に説明するとAWSで発生する様々なイベントや、
SaaSから発生するイベントを使用して、さらに様々なAWSサービスとつなげるまさしくBridge(架け橋)のようなサービスです
AWS公式から引用
もともとはCloudWatch Eventsというサービスがもとになっていて、そこから進化したのがEventBridgeのようです
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html
用語の説明
- Event Bus
- 様々なイベントの受け口になるもの
- 以下の3つの種類のイベントバスが存在する
- Default Event Bus
- AWSのサービス・カスタムアプリケーション（独自のアプリケーション）から発生するイベントに対して使用できるイベントバス
- どのAWSアカウントにも必ず１つ自動的に作られる
- Custom Event Bus
- カスタムアプリケーションで使用できるイベントバス
- 自由に作成できる
- Partner Event Bus
- AWS以外のSaaSサービス経由で利用できるイベントバス
- SaaSサービス側で登録してあげないと基本的に利用できない
- Default Event Bus
- Event Source
- 様々なAWSサービス・SaaS・カスタムアプリケーションのこと。
- 対応しているSaaSパートナーはこちらに登録されており、いずれのサービスとの統合も数クリックで設定が可能。
- Rules
- イベントバスに紐付き、イベントの検出パターンの定義やターゲット（どのターゲットにイベントを転送するか）の定義を記載します
- ターゲットに応じてIAM Roleが必要になります
※Schema Discovery/Schema Registryについては本稿では解説しません
EventBridgeって何がうれしいの？どう使うの？
AWSあるあるですが、このサービスを使うと何がうれしいのか、どう使うのかについて触れたいと思います
EventBridgeって何がうれしいのか
このサービスの肝は、2点あると思っています
① サーバ管理を行わず、イベントのやり取りをスケールさせられる
疎結合化したアプリケーションを作る際に、イベントを受け取りルーティングをするための仕組みをアプリケーションで作ろうとすると、
メンテナンス負荷（スケール・バージョンアップ対応など）が心配です。
EventBridgeの場合、Amazon EventBridgeはサーバレスでAWSによるフルマネージドなサービスのため、バージョンアップや負荷に応じたスケールも自動的に行われます。
それにもかかわらず料金的には非常に安価です
※AWSのサービスによって発行されたイベントについては無料・それ以外のカスタムイベント/SaaSのイベントに対しては100万件の公開済みカスタムイベントごとに 1.00USDです
⇒詳細
② 外部サービスのイベントを統合し、アプリケーションに組み込むことができる
様々なSaaSサービスから、AWS上のアプリケーションへの統合と行おうと思ったとき、APIによるPollingやWebhookによるPushを考えると思います
その際以下のような課題が発生すると思います
- EC2の場合メンテナンスが必要・サーバが落ちたらどうする？
- API扱うデータ量が多くなった時にどうスケールさせるのか？
- APIのコール数制限が近くなってきたら？
- イベント数があまりに多くなった時にどうさばく？
Event Bridgeの場合、先に挙げた通りサービスそのものはAWSによるフルマネージドで、自動でスケールします。
連携はSaaSサービス側からのPushでAPIコール制限の心配もなく利用可能です※もちろんAWSが死んでるときに生きてる保証はありませんが
- ワークフロー終了のイベントをトリガーに、Lambdaを実行する
- 認証ログを監査証跡としてKinesisにストリーミングし、S3に保管する
- セキュリティイベントを収集し、重要なセキュリティインシデントの発生を通知する
EventBridgeってどう使うの？
Event Busを登録(カスタムイベント・SaaSイベントの場合)し、RuleからTargetを指定します（ざっくり）
ポイントは以下の通りです
イベントパターンの作成
サービスごとの事前定義パターンや、独自定義のパターンを用いてどんなイベントを受け入れるのかをJSON形式で記述します
{
"source": ["aws.macie"],
"detail-type": ["Macie Alert A", "Macie Alert B"],
"detail": {
"risk-score": [80],
"trigger": {
"risk": [8]
}
}
}
この例の場合
- sourceが
aws.macieと一致する - detail-typeが
Macie Alert AまたはMacie Alert Bと一致する - detail.risk-scoreが
80と一致する - riskが
8と一致する
のようなイベントを受け入れることができます。
正規表現や、数値のレンジ・大小関係の比較は利用できないようです
ターゲットの指定
イベントパターンが決まったら、そのイベントをどのターゲットに送信するか決定します。
1つのルールに最大5つまでターゲットを指定できます。
ターゲットに使用可能な主なサービスは以下の通りです（一部抜粋）
- Lambda関数
- EC2インスタンス
- Kinesis Data Streamsのストリーム
- Kinesis Data Firehoseの配信ストリーム
- CloudWatch Logsのロググループ
- ECSタスク
- Systems Manager Run Command
- Systems Manager Automation
- AWS Batchジョブ
- AWS Step Functionsステートマシン
- AWS CodePipelineのパイプライン
- AWS CodeBuildプロジェクト
- Inspector の評価テンプレート
- SNS トピック
- SQS キュー
EventBridgeから各ターゲットへのアクセス制御には、２つの方法で制御されます
- IAMポリシーで制御（ターゲット側で制御が必要）
- Lambda, SNS, SQS, CloudWatch Logs以外のサービスをターゲットに使用する場合は、IAM Roleを割り当ててリソースへのアクセス許可を行う
- リソースベースポリシー（リソース側で制御が必要）
- Lambda, SNS, SQS, CloudWatch Logsの場合、ターゲット側でリソースポリシーの割り当てを行う必要がある
- マネジメントコンソールでターゲットを指定した場合は自動的にリソースポリシーが作成される
対応するサービスごとに、適切な方法でポリシーを設定する必要があります。
結構ハマりどころ。。。
リソースベースポリシー（CloudWatch Logsの場合）
{
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "put_log_events",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": [
"logs:PutLogEvents",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:hello-world-logs:*",
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:events:ap-northeast-1:123456789012:rule/hello-world-rule"
}
}
}
]
}
上記ポリシーの場合「hello-world-rule」から、「hello-world-logs」ロググループへの書き込みが行われるようになります
最後に
EventBridgeについて多少なりとも興味を持っていただけたでしょうか？
長くなってきたのでいったんここで区切って、次回は実際のEventBridgeを使ったサービスの例と構築方法をまとめてみたいと思います。