Amazon GuardDuty の検出通知メールに AWS DevOps Agent の調査結果を追加する クラウド事業統括本部 yhana 

本⽇お話すること GuardDuty の検出通知メールに DevOps Agent の調査結果を記載するノウハウ 検出内容 DevOps Agent 調査結果 2 

想定している AWS 環境 • AWS Organizations 全体の GuardDuty 検出結果を Security Hub に集約 • 集約した検出結果から EventBridge ルール経由で通知 • メールで通知し、宛先は AWS 全体の管理者 ② 検出結果のイベント連携 ③ メール送信 ① 検出結果の集約 3 

DevOps Agent を組み込んだアーキテクチャ ⑥ メール送信 ② 検出結果のイベント連携 ③ 調査依頼 追加部分 ⑤ 調査結果の取得 ① 検出結果の集約 ④ 検出アカウントの調査 4 

DevOps Agent の利⽤機能 5 

DevOps Agent の利⽤機能 ⑥ メール送信 ② 検出結果のイベント連携 ③ 調査依頼 ⑤ 調査結果の取得 ① 検出結果の集約 ④ 検出アカウントの調査 6 

インシデントレスポンス（インシデント RCA）機能 インシデント RCA 機能とは、インシデントの根本原因分析をする機能であり、 DevOps Agent のエージェントとして提供されている 7 

調査結果のサマリとタイムライン 調査結果のサマリと調査した内容のタイムラインが閲覧可能 サマリ（2026年8⽉に追加！） 調査タイムライン 8 

調査結果を API で取得 調査結果は API/CLI で取得できるため、通知メールには内容を厳選して記載 調査タイムラインを AWS CLI で取得した例 参考ブログ：AWS DevOps Agent のインシデント調査結果を AWS CLI で取得してみた | DevelopersIO 9 

サマリ/タイムラインベースのメール内容 2026年8⽉より前は調査タイムラインのみであったが、8⽉からはサマリ情報が調査 結果に出⼒されるようになり、サマリをそのまま取得可能に サマリの内容をそのまま記載 調査タイムラインから根本原因（root_cause）と 現象（symptoms）を取得して記載 10 

タイムラインをベースに記載する場合の注意点 根本原因を取得する場合において、調査結果に根本原因が「存在しない場合」「複数 存在する場合」があり、考慮が必要 根本原因を記載する場合の考慮の例 • 根本原因が 1 つの場合は、そのまま記載（下図） • 根本原因が複数の場合は、複数並べて記載 • 根本原因が無い場合は、原因（cause）を利⽤ 存在しない場合、複数存在する場合がある 11 

調査結果の⽣成に対する指⽰ 「インシデント RCA」 機能に対する SKILL.md を利⽤して、調査結果の体裁への指 ⽰が可能。⽇本語の記載指⽰が無い場合は、英語で出⼒されることもあった … 12 

DevOps Agent のスペース設定 13 

DevOps Agent のスペース設定 ⑥ メール送信 ② 検出結果のイベント連携 ③ 調査依頼 ⑤ 調査結果の取得 ① 検出結果の集約 ④ 検出アカウントの調査 14 

DevOps Agent のスペース設定 スペースとは DevOps Agent がアクセス‧調査できる範囲 デフォルトは単⼀アカウント内の範囲のため、AWS Organizations 配下の全メンバー アカウントを対象とするためには追加設定が必要 引⽤元：AWS DevOps Agentの全体構造と設定箇所を図解してみた | DevelopersIO 15 

DevOps Agent のスペース設定 スペースへの他アカウント追加には、IAM ロールの作成とセカンダリソースの追加が 必要。下図は CloudFormation StackSets と CLI を利⽤して設定する例 ① DevOps Agent がアクセスするためのロールを StackSets で⼀括作成 ② セカンダリソースとして、全メンバーアカウントを CLI で⼀括追加 参考ブログ：AWS DevOps Agent スペースのセカンダリソースの追加に必要な IAM ロールを CloudFormation StackSets で作成してみた | DevelopersIO 16 

DevOps Agent のスペース設定 セカンダリソースの追加を AWS CLI で⼀括設定するイメージ セカンダリソースとなる AWS アカウントのリストを CLI のインプットとして実⾏ 参考ブログ：AWS DevOps Agent スペースに AWS Organizations 配下のアカウントをセカンダリソースとして AWS CLI でまとめて追加してみた | DevelopersIO 17 

DevOps Agent の調査コスト 18 

DevOps Agent のコスト GuardDuty の重要度 High 以上の調査コスト実績は「$1〜15/1回、平均 約$6/1回」 サンプルの⼀⻫作成で調査してしまうと $200 程度かかるみたい 参考ブログ：Amazon GuardDutyの検出結果サンプルの⽣成を実⾏したら、AWS DevOps Agentで200ドルの課⾦が発⽣した話 | DevelopersIO 19 

【余談】⼤量サンプルの調査が始まってしまった場合 仮に⼤量サンプルを作成してしまった場合でも、同時に調査できる数は限られている ことから、調査をキャンセルすることで意図しない課⾦の抑制が可能 調査のキャンセル ⼤量サンプルの発⽣ 調査 調査 調査 調査 調査 調査 調査 調査 … … 調査 調査 調査 調査 調査 … 20 

EventBridge ルールの設定 21 

DevOps Agent の設定 ⑥ メール送信 ② 検出結果のイベント連携 ③ 調査依頼 ⑤ 調査結果の取得 ① 検出結果の集約 ④ 検出アカウントの調査 22 

サンプルを除外するイベントパターン DevOps Agent の調査コストを考慮して次の検出内容を調査‧通知対象に選定 ①重要度「⾼（High）」以上、②サンプルは特定の 1 タイプのみ、にマッチ { "source": ["aws.securityhub"], "detail-type": ["Security Hub Findings - Imported"], "detail": { "findings": { "ProductName": ["GuardDuty"], "Severity": { "Label": ["HIGH", "CRITICAL"] }, "$or": [ { "Sample": [false] }, { "Types": ["TTPs/Command and Control/Backdoor:EC2-DenialOfService.Dns"] } ] } } } 参考ブログ：AWS Security Hub CSPM 経由の GuardDuty 通知においてサンプル検出を通知させない EventBridge イベントパターンを試してみた | DevelopersIO 23 

GuardDuty のテスト⽤サンプル作成 GuardDuty のサンプルは CLI を⽤いることで特定の 1 種類だけ作成が可能 参考ブログ：Amazon GuardDutyで1つのサンプルイベントのみ発⽣させる⽅法 | DevelopersIO 24 

Lambda の設定 25 

Lambda の設定 ⑥ メール送信 ② 検出結果のイベント連携 ③ 調査依頼 ⑤ 調査結果の取得 ① 検出結果の集約 ④ 検出アカウントの調査 26 

Lambda の実装イメージ GuardDuty 検出イベントを契機に、Lambda から SDK で DevOps Agent のインシデ ント調査を開始し、調査が終われば SNS 経由でメールを送信 27 

Lambda のタイムアウト時 Lambda のタイムアウト時間上限が 15 分であることを考慮して、DevOps Agent の 調査が終わらない場合は、結果を取得できない旨を記載して通知メールを送信 28 

Lambda のタイムアウトへの対応⽅法 Lambda のタイムアウトへの対応⽅法はいくつかあるが、 Durable Functions を利⽤してタイムアウト時間を15分以上にする実装が可能 Durable Functions の各ステップと動作イメージ No. ステップの処理内容 1 DevOps Agent に調査を依頼する 2 調査のステータスを確認する 3 調査結果を取得してメール本⽂に整形する 4 SNS トピックに発⾏する 1 回⽬ 2〜n 回⽬ n+1 回⽬ … 29 

Lambda のタイムアウトへの対応⽅法 Durable Functions 以外の解決策 • Step Functions 化 • DevOps Agent 調査完了イベントを契機にメール送信する Lambda に分割 次スライド以降で、今回は採⽤しなかった理由を紹介 30 

Step Functions と Durable Functions Step Functions でも実現できそうであったが、連携サービスも少なかったため、 公式の意思決定フレームワークを参考に Durable Functions で試してみた 引⽤元：Durable functions or Step Functions - AWS Lambda 31 

Step Functions と Durable Functions 将来の拡張を考えると Step Functions を採⽤してもよかった 例えば、Bedrock を⽤いて DevOps Agent の調査結果から独⾃の要約を追加する等 独⾃の要約 追加調査内容 32 

調査完了イベントを契機にメール送信 Lambda 起動 メール送信⽤ Lambda 関数を分けて作成し、DevOps Agent 調査完了イベントを契機 に Lambda 関数を起動する処理イメージ 33 

メール送信⽤ Lambda を分ける場合の考慮点 調査結果イベントや調査結果には GuardDuty の検出結果の完全な情報は無い メール送信⽤ Lambda において、調査依頼時に渡している検出結果情報などを基に 情報取得する必要がある（または、別途保管しておく） GuardDuty 検出結果情報 (Findings) の有無 メールに検出結果情報を記載する場合は考慮が必要 調査完了イベントや調査結果に 含まれない情報がある 検出結果情報あり 検出結果情報なし 34 

メール送信⽤ Lambda を分ける場合の考慮点 DevOps Agent には調査のステータスには調査完了以外に、調査失敗やスキップがあ るため、調査完了イベントだけを条件にすると通知メールが送信されない恐れがある EventBridge のイベントパターン例 通知が漏れないように調査完了（Investigation Completed） 以外も考慮して指定する必要がある 35 

メール送信⽤ Lambda を分ける場合の考慮点 DevOps Agent のインシデント調査には同時実⾏できる上限がある 仮に⼤量の検出が同時に発⽣した際に、調査が終わって通知されるまでに時間がかか る可能性があり、今回は 1 時間以内に通知されるように Durable Functions を利⽤ ⼤量検出の発⽣ 調査 1時間経過 調査 調査 調査 調査 調査 調査 調査 調査 調査 調査 調査 調査 36 

SNS 経由のメールの件名の指定 SNS を直接呼び出してメール件名を指定（ただし、⽇本語は未対応） メール件名の例 • Sandbox 01 (111122223333) AWS Security Notification • Audit (444455556666) AWS Security Notification 37 

さいごに 38 

さいごに 本⽇説明した Lambda と Durable Functions 両⽅のサンプルコードをブログで公開 しています URL：【登壇資料】 Amazon GuardDuty の検出通知メールに AWS DevOpsAgent の調査結果を追加する #devio2026 | DevelopersIO 39 

No content