はじめに
こんにちは！ アプリケーションサービス本部ディベロップメントサービス１課の森山です。
AWS DevOps Agent はすでに３記事が投稿されていますが、懲りずに私も検証記事を投稿してみたいと思います！
今回は以下の動画でも紹介されているシナリオを再現してみたいと思います。
何かしらの障害が発生し、エンジニアがオンコール対応で AWS 環境にログインするとすでに DevOps Agent が調査を開始してくれている・・・というシナリオです。
私は前職では 24 時間のオンコール対応をしていたので、自律的に調査を進めてくれるこの新サービスに非常に魅力を感じております。
特に深夜帯など、頭が回っていない時間帯に障害対応するときなどは非常に助かる機能だと思います。
本記事の注意事項
DevOps Agent は本記事執筆時点（2025 年 12 月上旬）ではプレビュー版です。
GA（一般提供）までに仕様が変更される可能性がありますので、ご注意ください。
試してみた！
では、今回は以下のシナリオで動作確認してみます。
Webhook の内容は後述します。
- 準備（Webhook 設定）
- サーバレスアプリとアラームのデプロイ
- 正常動作の確認
- ポリシーを削除（障害発生）
- エラーの確認
- DevOps Agent による自動調査
- 緩和計画の作成
準備
まず、DevOps Agent の準備をします。
基本的なセットアップはすでに紹介していただいているので、この記事では割愛します。
DevOps Agent は ServiceNow や PagerDuty などのチケット管理システムのインシデントをトリガーに動作することもできますが、今回は Webhookを活用し、CloudWatch Alarm をトリガーに自動調査を開始する構成を試してみます。
個人的な所感としては、CloudWatch Alarm でアラーム状態に遷移した際に自動的に動いて欲しいとは思うのですが、現時点では Webhook でトリガー等、何かしらのCapabilitiesの設定が必要そうです。
では、Capabilitiesのところから Webhook を追加していきます。
ここからadd sourceで設定をしていきます。
Webhook の作成方法を教えてくれます。
その後、URL やシークレットキーを作成する画面になるので、作成し、内容を控えておきます。
これで Webhook 作成完了です！
なお、Webhook を叩く AWS Lambda ソースは以下を参照ください。
1. サーバレスアプリとアラームのデプロイ
AWS SAM で Amazon DynamoDB にアクセスする簡単なサーバレスアプリと、アプリのエラーを検知するアラームをデプロイします。
以下にソースを置いています。
2. 正常動作の確認
Amazon API Gateway 経由で動作確認をします。
% curl https://xxx.execute-api.us-east-1.amazonaws.com/Prod/hello
{"message":"hello world","timestamp":"2025-12-04T04:33:20.267Z","saved":true}
3. ポリシーを削除（障害発生）
AWS Lambda に付与されている以下のインラインポリシーを手動削除します。
これ以降、Amazon DynamoDB の操作がAccessDeniedで拒否されるようになり、正常に動作しなくなります。
4. エラーの確認
再度 Amazon API Gateway 経由で動作確認をします。
% curl https://xxx.execute-api.us-east-1.amazonaws.com/Prod/hello
{"message": "Internal server error"}
エラーになりました。
5. DevOps Agent による自動調査
しばらくするとアラームが発報します。
このアラームはアラーム状態になると、Amazon SNS 経由で、先ほど作った Webhook を叩く動作になっています。
そのため、AWS DevOps Agent Web アプリを確認すると、調査が進んでいることが確認できます。
では、抜粋して調査内容を紹介していきます。（今回は可読性のため、 WEB ページを日本語翻訳してております。）
1. アラーム情報の確認
まず、アラームの詳細情報を確認していました。
2. Lambda 情報の収集
次に、AWS Lambda 関数の設定情報を取得します。
ここでAWS SAMでデプロイされていることや、関数の最終更新時刻がエラー発生の約 5 分前であることに気づきます。
ここから以下 4 つを並列で調査し始めました。
3. ログ分析
Amazon CloudWatch Logs を確認したところ、全てのエラーが AccessDeniedException であることが判明しました。
これにより、Amazon DynamoDB へのアクセス権限に問題があることに気づきます。
4. デプロイメントの変更を確認
デプロイの状況を確認します。
今回の障害の原因ではないのですが、インプレースデプロイであったことや、環境変数の設定漏れを指摘しています。
5. IAM 権限の確認
実行ロールの権限を確認します。
そして、デプロイ時には存在したはずのインラインポリシーがないことに気づきます。
調査の時系列は前後しますが、私がインラインポリシーを削除していることも検知しています。
素晴らしいです！
6. 根本原因の調査結果
最終的には以下の結果になりました。
根本原因を特定するために必要な情報は調査しているものの、結論は少し誤っていますね。
ただ、何度か実施すると、正しい原因を報告する場合もありました。
なお、チャットで質問ができるので、聞いてみます。
Could it be because
satoshi.moriyamadeleted the inline policy?
結果、以下の回答（翻訳）が来て、質問すれば正しい回答が返ってきました。
はい、まさにその通りです。調査の結果、04:34:37Z にユーザー satoshi.moriyamaが AWS コンソール経由で AWS Lambda 実行ロールからインラインポリシー HelloWorldFunctionRolePolicy0 を手動で削除したことが判明しました。
このポリシーには、関数が必要とするすべての Amazon DynamoDB 権限（PutItem を含む）が含まれていました。
この削除は次のタイミングで発生しました：
AWS CloudFormation デプロイがポリシー付きロールを作成してから 3 分後（04:31:41Z）
AWS Lambda エラー発生の 2 分前（04:37:00Z）
AWS CloudFormation テンプレートは Amazon DynamoDB 権限を正しく定義していましたが、手動削除により権限が失われたため、以降の全ての Amazon DynamoDB 操作が AccessDeniedException で失敗しました。
6. 緩和計画の作成
次に、Generate Mitigation Planを選択し、緩和計画を作成してもらいます。
しばらくすると、以下の 4 つのステップで緩和計画が作成されます。
- Step 1: Prepare（準備）
- Step 2: Pre-validate（事前検証）
- Step 3: Apply（適用）
- Step 4: Post-validate（事後検証）
内容を抜粋すると、Amazon DynamoDB を操作するために必要なインラインポリシーをアタッチする計画になっています。
また、ロールバック用のコマンドも提供してくれていました。
緩和計画自体は自身で実行する必要がありそうです。
まとめ
AWS DevOps Agent を使った障害調査の自動化を試してみました。
今回の検証で感じたことをまとめます。
良かった点
- アラームやログだけでなく、デプロイ履歴や IAM 設定・CloudTrailなど、複数の情報源を自動で調査してくれる
- デプロイ時刻とエラー発生時刻の関連性を自動で発見してくれた
- 緩和計画を自動生成してくれるので、素早く復旧できそう
気づいた点
- 今回の調査結果は完全ではなかったが、必要な情報は集めていた
- チャットで追加質問することで、正確な根本原因（手動でのポリシー削除）を特定できた
- CloudWatch Alarm がアラーム状態になった際に、Webhook を経由せずに直接 DevOps Agent が起動する仕組みがあるとさらに便利
Preview 段階ではありますが、オンコール対応の負荷を軽減できる可能性を感じました。今後の機能拡充に期待です！
