目次
AWS EventBridgeとは？
AWS EventBridgeとは、イベント駆動の処理を実現するサービスです。
AWSのサービスや独自のアプリケーションにて発生するイベントをリアルタイムで検知し、そのイベントに基づいた処理をトリガーするができます。
EventBridgeは、様々な種類のイベントに対応しています。例えば、EC2インスタンスの起動・停止や、S3バケットへのオブジェクトのアップロードなど、AWS上の様々なサービスで発生するイベントを検知することができます。
EventBridgeでは、イベント・ルール・ターゲット・イベントバスを定義します。以下でそれぞれの説明を行います。
- イベント：AWSのサービスや独自アプリケーションなどで発生する状態変化です。
- イベントバス：メッセージの送受信を管理するエンティティで、EventBridgeの本体となります。
- ターゲット：イベントを配信する先です。
- ルール：ターゲットやイベントを定義する設定です。
また、イベントには以下の種類が存在します。
- デフォルトサービスイベント：AWSサービスで発生するイベント
- カスタムイベント：独自アプリケーション毎の独自のイベント
- パートナソースイベント：SaaSアプリが発行するイベント
- クロスアカウントイベント：異なるAWSアカウント間共有されるイベント
※サポートされるパートナーソースについては、AWS公式ドキュメントを参照下さい。
デフォルトサービスイベントにはデフォルトイベントバス、カスタムイベントにはカスタムイベントバスの様に、各イベント毎に異なるイベントバスを利用する事となります。
料金
EventBridgeの作成は無料であり、イベント毎に課金される従量課金制となります。
イベントの種類により、料金体系が異なります。アジアパシフィックリージョンの場合、以下のようになります。
- デフォルトサービスイベント：無料
- カスタムイベント：発行されたイベント100万1.00USD
- パートナーソースイベント：公開済みのイベント100万件あたり1.00USD
- クロスアカウントイベント：送信されたイベント100万件あたり1.00USD
料金は変動する可能性があるので、詳細はAWS公式ドキュメントを参照下さい。
ユースケース
ユースケースとしては、イベント駆動のシステムを構築する際に利用します。
アラートが発生した際に、アプリケーションやLambda関数を動作させ、アラートに応じた処理を実施するなどのケースで利用できます。
Amazon SNS(Simple Notification Service)との比較
類似サービスとして、Amazon SNSがあります。イベント駆動で情報を連携するという要件に対し、Amazon SNSでも対応可能なケースもあります。
EventBridgeとSNSの違いが発生するシナリオとして、異なる組織間でのイベントの連携のケースなどで発生します。
異なる組織間でイベントを共有する際に、EventBridgeを利用すると、以下の様なアーキテクチャになります。
対してSNSを利用すると、以下のようになります。
一見SNSの方がシンプルなように見えますが、組織Bの中で別のAWSリソースを追加し、追加したリソースに対してもイベントを連携したい場合に違いが出ます。
EventBridgeを利用したケースの場合は、組織Bが独自で追加リソースへのイベント連携を設定できます。
一方SNSの場合、組織Aにリソースの追加を報告しイベント連携を設定して貰う必要があります。この場合、イベント連携設定の変更にリードタイムが発生してしまう可能性があります。
上記の様に組織を跨いだイベント連携の際などに違いが発生します。
ハンズオン概要
以下で実際にEventBridgeを利用していきます。
今回は、GuardDutyで検知されたアラートをEventBridgeとSNSを用いて管理者にメールを送信するという機能を作成します。
利用手順
※当ページでは2023年3月現在のEventBridgeについて解説します。クラウドサービスは頻繁にアップデートが施されるため、仕様が異なる可能性があります。
ログイン
まずは、AWS公式ページからAzureにログインしましょう。
SNSの作成
SNSの作成については、Amazon SNSとは？徹底解説！を参照下さい。
EvendBridgeの新規作成
検索バーに”EventBridge”と入力し、”Amazon EventBridge”を押下します。
デフォルトのイベントバスを利用するので、イベントバスの新規作成は不要です。
ルールタブより、デフォルトイベントバスに紐づくルールを作成します。
“ルールの詳細”は以下の様に設定します。
- 名前：任意のルール名を付与します。今回は”test-eb-rule”と命名します。
- 説明：ルールの説明を記載します。
- イベントバス：紐づけるイベントバスを指定します。デフォルトを利用するので、”default”を指定します。
- ルールタイプ：定義したイベントで実行されるルールとするか、スケジュールによって事項されるルールかを定義します。”イベントパターンを持つルール”を指定します。
“イベントソース”は”AWSイベントまたはEventBridgeパートナーイベント”を選択肢、AWSサービスのイベントを検知できるようにします。
“サンプルイベント”では、接続元のイベントをサンプルで作成し、テストに利用する事が出来ます。
今回は”GuardDuty Finding”を選択します。
“作成のメソッド”は”カスタムパターン”を選択し、イベントパターンにJSON形式でイベントを定義します。
“イベントパターン”にてJSON形式でイベントを定義します。
今回はGuardDutyにて、SeverityがHighのイベントを通知する事を想定します。
“ターゲット1″は、以下の様に設定します。
- ターゲットタイプ：Amazon SNSをターゲットとする為、”AWSのサービス”を選択します。
- ターゲットを選択：“SNSトピック”を選択します。
- トピック：先程作成した、”test-eb-topic”を選択します。
- ターゲット入力を設定：ターゲットに渡すメッセージをカスタマイズする事が出来ます。今回はイベントのテキスト全てを渡す”一致したイベント”を指定します。
- イベントの最大有効期間：未処理のイベントを保持する最長の時間を定義します。デフォルトで24時間となっています。今回はデフォルトの24時間のままとします。
- 再試行回数：エラーが発生した際に、ターゲットへイベントの送信を再試行する最大回数を定義します。デフォルトで185回となっています。今回はデフォルトの185回のままにします。
- デッドレターキュー：設定した再試行回数を超えても正常にターゲットに配信されなかった場合、イベントを保持するSQS(デッドレターキュー)を準備する事で、問題を解決した後に、正常に配信されなかったイベントを再送する事が出来ます。今回は”なし”を選択します。
タグは今回利用しません。
上記の設定が完了したら、”ルールの作成”を押下します。
GuardDutyの有効化
GuardDutyを有効化します。GuardDutyのページから、”今すぐ始める”を押下します。
“GuardDutyを有効化する”を押下します。
テスト
GuardDutyの検出結果をテスト用に生成します。
GuardDutyのテストタブより、”検出結果のサンプルの生成”を押下します。
以下の様に登録したメールアドレスにGuardDutyのメッセージが送信されていれば成功です。※数分時間が掛かります。
関連記事
