注意事項

本記事は「いのべこ夏休みアドベントカレンダー 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サービス側で登録してあげないと基本的に利用できない
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を使ったサービスの例と構築方法をまとめてみたいと思います。