先日AWSマネジメントコンソールからのEventBridgeルール作成のサポート強化するサービスアップデートがあり、ルールを作成する際に、使用可能なAWSサービスイベントのsourceとdetail-typeが表示されるようになりました。
以前投稿したEventBridgeルールをデバッグするときのナレッジをまとめた記事でも、AWSマネジメントコンソールからルールを作成するときに、簡単にイベントパターンを作成できる機能として紹介していました。
今回のアップデートを機に、投稿時からアップデートされた情報や、新たな知見をTipsとしてご紹介します。
新たに公開された「AWS Events Reference」
前述のアップデートと一緒に「AWS Events Reference」というドキュメントが公開されました。
ルール作成画面のイベントパターン作成で選択できる項目とおなじく、使用可能なAWSサービスイベントのsourceとdetail-typeのリファレンスとなっています。
これでイベントパターンを作成するための情報が一元化されたのかと思っていました。
しかし残念ながら、このリファレンスには、イベントのdetailに含まれる詳細なイベントの中身ついて、執筆時点では記載がありません。
目当てのイベントを詳細にフィルタリングするには、これまでどおり、ルール作成画面のサンプルイベントや、各サービスのドキュメントから読み解く必要があります。
具体的な方法は以前の記事に記載したので、気になる方はご参照ください。
とはいえ、「AWS Events Reference」にはdetail-typeが網羅されているので、対象サービスで発生するイベントが発生するかを把握するのに役立ちます。
加えて、EventBridgeルールに関する公式ドキュメントとしては、以前紹介できなかったベストプラクティスに関するページがありますので紹介します。
Amazon EventBridge のイベントパターンのベストプラクティス
Amazon EventBridge のルールを定義する際のベストプラクティス
イベントパターンにデバッグ用のイベントソースを仕込む
以前の記事では最後に以下のようなコメントしていました。
AWSへの機能要望としては、簡単にデバッグ用のイベントを発生させて、フィルタからターゲット実行までの動作確認をしやすくするような機能が欲しいですね。
目当てのイベントを発生させるのが難しい異常系のイベントであったり、何度もおなじイベントを発生させてデバッグがしたかったり、イベントを使ったデバッグするハードルが高いと感じていたため、このようなコメントをしました。
しかし、特別な機能がなくても、フィルタからターゲット実行までの動作確認をする方法がありました。
それはとても単純な方法で、イベントフィルタのsourceにデバッグ用のカスタムイベントソースを追加し、ダミーのイベントをPutEventsすることです。
具体的には、以下のようなイベントフィルタを設定します。
{ "source": [ "aws.guardduty", "eventdebug.guardduty" ], "detail-type": ["GuardDuty Finding"], }
この例では、GuardDutyの検知ルールで、sourceにaws.guarddutyだけでなく、デバッグ用のeventdebug.guarddutyも設定しています。
この状態で、イベントバスの「イベント送信」から、イベントソースにeventdebug.guarddutyを設定してダミーのイベントを送信することで、このイベントフィルタを簡単にデバッグ、テストできます。
イベントのアーカイブと再生機能
この機能は、発生したイベントを保存し、イベントバスに再投入することができる機能です。
イベント駆動のアプリケーションで発生する、重要なイベントをバックアップしておくといった利用だけでなく、
以下のようなデバッグやテストにも活用できます。
- イベントを一度発生させて、アーカイブしておき、再生機能を使ってデバッグする
- 動作確認用のイベントをアーカイブしておき、リグレッションテストに利用する
- アクション先の負荷試験用の大量イベントをアーカイブしておき、定期的に再生して負荷試験を行う
おわり
今回ご紹介したTipsが、より効率的なEventBridgeルールの設計・検証に役立てば幸いです。
今後もEventBridgeルールに関するTipsが溜まってきたら、引き続きご紹介していきたいと思います。
