DevOps Agentについて
続いて、DevOps Agentの使用感についても概要を紹介します。
AWS公式にて公開されているテスト用の環境を準備し、実際にDevOps Agentがどのように調査するか確認してみました。
CloudFormationのテンプレートが用意されていて、テスト環境が簡単に作れるため、ぜひ利用してみてください。
EC2インスタンスでCPU使用率が急上昇し、CloudWatchアラームが発報した状況を想定したテストを実施してみました。
手順概要
①EC2にCPUストレステストを仕込む
②CloudWatchアラームを発報させる
③DevOps Agentに調査を依頼する
1. AgentSpace作成
マネジメントコンソールにて「DevOps Agent」を検索し、AgentSpaces > createAgentSpaceへ進み任意の名前をつけ使用するロールやタグの設定をします。
2. テスト環境の構築
AWS公式ドキュメントにて展開されているCloudFormationのテンプレートを利用して、テスト用のEC2インスタンスやCloudWatchアラームを作成します。
マネジメントコンソールにて「CloudFormation」を検索し、テスト環境構築用のスタックを作成します。
yamlファイルをアップロードし、ステータスが「CREATE_COMPLETE」となれば、テスト環境構築の完了です。
3. CPUストレステスト
次に、意図してアラートを発生させるため、EC2インスタンスを起動し、CPUストレステストを実行します。
ストレステスト用のスクリプトはCloudFormationのテンプレートでEC2を構築した際に、配置済みのため、コマンドを入力するだけで実行できます。
スクリプト概要 1.CPUコア数分のプロセスを起動 2.約5分間CPUを使い切る 3.意図的に70%以上のCPU使用率を発生
4. CloudWatchアラーム発報
しばらくすると、CPU使用率が急上昇したことにより、CloudWatchアラームがALARM状態へ変更されます。
5. DevOps Agentに調査を依頼する
AgentSpaceに遷移し、このアラート発報の原因をAgentがどのように調査し結論づけるか確認してみましょう。
6. DevOps Agentが行う調査
調査を開始すると、タイムライン上に調査の過程が入力されます。
Agentの調査の過程を確認してみると、以下の過程で調査が行われていることがわかります。
①メトリクスの時系列分析
②インスタンス操作履歴
③ユーザーアクション
④IaC/UserData
7. 調査結果
数分経過後に、原因の特定が完了しRootCauseのタブが出現します。
RootCauseAnalysis
結果 TheCPUspiketo~100%at2026- 01- 03T09:05:00ZwascausedbyaCPU- intensiveworkloadinitiatedapproximately3minutesafteruserChinami.MatsubaraestablishedanSSHconnectiontotheinstanceat09:02:13Z. ThestrongtemporalcorrelationbetweentheSSHconnectionandtheCPUspike,combinedwiththeshort- livednatureofthespike(approximately5minutes),theinstance’spurposeasan"AWS- DevOpsAgent- Testing"resource,andthecompleteabsenceofotherinfrastructurechangesduringthisperiod,stronglyindicatesthattheuserexecutedaCPU- intensivecommandorscriptviaSSH. Duringthespike,thet3.microinstanceconsumed6.13CPUcreditsperminute(approximately37xnormalusage),reducingavailablecreditsfrom81.93to73.89.However,sufficientburstcapacitywasavailable,andnoCPUthrottlingoccurred. Theworkloadcompletedby09:10:00Z,afterwhichCPUutilizationreturnedtoabaselinelevelof0.16%. ーーー日本語訳ーーー 2026- 01- 03T09:05:00Zに発生した約100%のCPU使用率スパイクは、ユーザーChinami.Matsubaraが09:02:13Zに当該インスタンスへSSH接続を行った約3分後に開始された、CPU負荷の高い処理がユーザー操作によって実行されたことが原因です。 SSH接続とCPUスパイクの強い時間的相関関係に加え、CPUスパイクが約5分間という短時間で終了していること、当該インスタンスが「AWS-DevOpsAgent-Testing」用途のリソースであること、該当時間帯に他のインフラ変更が一切確認されていないことを踏まえると、ユーザーがSSH経由でCPU負荷の高いコマンドまたはスクリプトを実行した可能性が極めて高いと判断できます。 CPUスパイク発生中、t3.microインスタンスは1分あたり6.13CPUクレジット（通常時の約37倍）を消費し、CPUクレジットは81.93から73.89まで減少しましたが、十分なバーストキャパシティを保持していたためスロットリングは発生しませんでした。 処理は09:10:00Zに完了し、その後CPU使用率は0.16%まで正常に戻っています。
私がCPUテストを実施したことが原因でアラートが発生したことが調査により特定されています。
具体的なユーザ名や、EC2を起動した時刻などどのような順序で事象が発生したかが記載されています。
人間なら複数画面を行き来する調査を、Agentは一気にまとめて実行し、数分で根本原因の特定まで至ることができます。
また、AWSリソースの構成と依存関係を、因果関係つきで可視化したTopologyも結果とともに出力され、アラートが、どのリソース群の上で、どんなつながりを持って発生したのかが一目でわかります。
すべての事象に対して、適切な調査を行うことができるか否かは実際に利用してみないとわかりませんが、少なくとも今回の事象に関しては問題なく必要な調査結果を得ることができました。
このように、数分で調査の過程及び調査結果が確認できるため、運用の現場においては初動負荷を大きく下げられるのではないでしょうか。
Devops Agentのユースケース
今回のハンズオンでは、インシデント調査としてCloudWatchと連携しアラート発報時の原因調査を検証しました。
Devops Agentは、他にも、Datadog、Dynatrace、New Relic、Splunkといった外部オブザーバビリティツールや、GitHub・GitLabなどのコードリポジトリ、CI/CDパイプライン、運用ランブック、ワークフローと統合できる点が特徴です。
これにより、単一の監視アラートだけでなく、デプロイ履歴・コード変更・運用手順・ログやメトリクスといった複数の運用データを横断的に関連付けた調査が可能になります。
さらに、MCP（Model Context Protocol）サーバーを介して独自のツールや社内システムと接続することで、チケット管理システムや社内独自の運用基盤と連携し、既存の運用プロセスに組み込んだ形で活用することも可能です。
以下のようなユースケースが考えられるかと思います。
| ユースケース分類 | 概要 | 主な連携・対象 |
|---|---|---|
| インシデント初動調査 | アラートを起点に、メトリクス・操作履歴・IaC・ユーザー操作を横断的に調査 | CloudWatch、EC2、CloudFormation、IAM |
| オブザーバビリティツール連携 | 複数の監視・ログ基盤を横断して調査・分析 | Datadog、Dynatrace、Splunk、New Relic |
| CI/CD 連携による変更起因分析 | デプロイやコード変更と障害発生の関係を分析 | GitHub、GitLab、CI/CD パイプライン |
| ランブック・運用フロー連携 | 障害状況に応じて、対応手順や確認ポイントを提示 | 運用ランブック、ワークフロー |
| MCP による独自ツール連携 | 組織固有のツールやチケット管理システムと統合 | Jira、ServiceNow、独自ツール |
