AWS DevOps AgentがどこまでCDKの設定ミスを特定してくれるのか試してみた #AWSreInvent
re:Invent 2025のキーノートで AWS DevOps Agent のプレビューが発表されました。
DevelopersIOもたいへん盛り上がっております！
この子の力を最大化するために、問題があったら原因となったリリースを特定させて、コードまで分析させられないかと試してみました。
前提となるアプリケーション
以下のような単純なアプリケーションを想定します。
1分ごとのlambda起動 → DynamoDBに書き込み
それだけです。
import * as cdk from "aws-cdk-lib";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";
import * as events from "aws-cdk-lib/aws-events";
import * as targets from "aws-cdk-lib/aws-events-targets";
import * as nodejs from "aws-cdk-lib/aws-lambda-nodejs";
const app = new cdk.App();
const stack = new cdk.Stack(app, "PlayDevopsAgentsStack", {
env: {
region: "us-east-1",
},
});
// DynamoDB Tableを用意して
const table = new dynamodb.TableV2(stack, "Table", {
partitionKey: { name: "pk", type: dynamodb.AttributeType.STRING },
sortKey: { name: "sk", type: dynamodb.AttributeType.STRING },
removalPolicy: cdk.RemovalPolicy.DESTROY,
});
// Tableにデータを書き込むLambdaを用意して
const fn = new nodejs.NodejsFunction(stack, "Function", {
environment: {
TABLE_NAME: table.tableName,
},
});
table.grantReadWriteData(fn);
// Lambdaを定期実行する
const rule = new events.Rule(stack, "Rule", {
schedule: events.Schedule.rate(cdk.Duration.minutes(1)),
});
rule.addTarget(new targets.LambdaFunction(fn));
// Lambdaのエラーにアラームをセット
fn.metricErrors().createAlarm(stack, "FunctionErrorAlarm", {
threshold: 1,
evaluationPeriods: 1,
});
Lambdaの中身は、適当な値でDynamoDBに書き込むだけの簡単なものです。
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocument } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({});
const doc = DynamoDBDocument.from(client);
const TABLE_NAME = process.env.TABLE_NAME;
export const handler = async () => {
await doc.put({
TableName: TABLE_NAME,
Item: {
pk: "1",
sk: new Date().toISOString(),
val: Math.random() * 100,
},
});
};
エラーを起こしてみる
AWS DevOps Agentのspaceを作成してから、Lambdaの権限を剥奪してエラーを起こしてみます。
以下のコードをコメントアウトします。
Agentにはぜひこの差分（コメントアウト）を特定してほしい。。。
// Lambdaから書き込み権限を剥奪
// table.grantReadWriteData(fn);
CDKをデプロイすると想定通りCloudWatch Alarmが鳴りはじめました。
AWS DevOps Agentに調査を依頼する
Agentに調査開始を依頼します。
（ここ自動にならないのかな。。。）
以下が調査結果です。
意訳:
Lambda関数がDynamoDB Tableに書き込もうとして
AccessDeniedExceptionエラーになりました。
このLambda関数のロールはdynamodb:PutItemを実行する権限を持っていません。
17:42-17:43Z にインフラがデプロイされたけど、この権限は付与されていなかった。
DynamoDBへの書き込みが不要だった8分間は成功してたけど、書き込みが始まってからは失敗するようになった。
関数は最初から書き込みを行っていて、権限がなくなったことによりエラーが始まったので、分析が間違ってますね 🤔
コード差分を理解できるようになればもっと正確な分析が行えるはず。
Migration Planも考えてもらいましたが、提案されたのはCLIを用いて権限を付与するというものでした。
aws iam put-role-policy ...
もっと正しく分析してほしい。具体的な修正を出してほしい。
Pipelineを設定して、リリースを特定させる
Agentが問題のあったリリースとそれ以前のリリースを特定できるように、DevOps AgentのPipelineを設定します。
この機能はGitHubやGitLabと連携してあげることで、ワークフローを確認できるようにする機能です。
PipelineはAWS DevOps Agentのコンソール → Agent Spaceを選択 → Capabilitiesタブ → Pipelineセクションから追加できます。
GitHub Actionでのデプロイもセットアップしていざ。
一度CDKを正しい状態に戻してデプロイし、再度コメントアウトしてエラーを発生させます。
// 今一度、Lambdaから書き込み権限を剥奪
// table.grantReadWriteData(fn);
AWS DevOps Agentに調査を依頼する v2
CloudWatch Alarmが鳴ったのを確認してから、Start Investigationしました。
意訳：
Lambda関数は
dynamodb:PutItemしようとしてAccessDeniedExceptionエラーになりました。原因は実行roleに必要な権限が足りなかったからです。
この権限欠落はCloudFormationデプロイによって引き起こされました。19:36:26Zにpolicyを削除しています。
ここでもCDKとかGitHub Actionsの話はでてきませんね。
修正案を提案させてみます。
おお！GitHub Actionに言及してくれています！
意訳：
Lambdaが落ち始める前のIAMの状態に戻すべく、ワークフローを再デプロイしましょう
GitHub repository https://github.com/yamatatsu/play-devops-agents に遷移 → Actions → Deploy workflow → 前回うまく動いてたときの実行 → 'Re-run all jobs'をクリックしてロールバックを実行 → 成功するのを眺める → CloudFormationがUPDATE_COMPLETEになるのを待つ
リポジトリも特定してくれていますね 👀
実行ジョブまで特定してくれてもよかったのにな。。。
MCPとRunBookを設定する
まだまだ、これではプロダクト利用可能とは言えません。
AWS CDKの思想は「クラウドにデプロイされるものはコードリポジトリの完全な断面。ロールバックするならリポジトリのコードをロールバックするのだ」なので、過去jobの再デプロイではなくコードの修正を提案してほしいところです。
そのためにまずはgithub-mcp-serverを設定して、Agentが詳しくコードの変更を分析できるようにしてみました。
（Pipelineを設定した時点でできるように鳴っているのかもしれない。。別途実験します。）
MCP ServerはAWS DevOps Agentのコンソール → Agent Spaceを選択 → Capabilitiesタブ → MCP Serverセクションから追加できます。
加えてRunBookも設定してみます。
RunBookは今までの設定とは異なり、AWS DevOps AgentのWebApp（正式名称はなんだろう。。）から設定できます。
設定したRunBookはGitHubにコミットしてあります。
AWS DevOps Agentに調査を依頼する v3
同じ手順で再度エラーを発生させてから、AWS DevOps Agentに調査させました。
結果はこちら
意訳：
CloudFormationによってLambdaの権限なくなったから起きた
RunBookは使ってくれなかったようです。。。いちおうMigration Planを考えてもらいました。
意訳：
直ちに実行できる運用上の緩和措置は特定できません。
根本原因とCloudFormationテンプレートの分析により、これはロールバック可能なデプロイメントではなく、既存のInfrastructure as Code構成の欠陥であることが判明しました。
Lambda関数は、2025-12-04T19:19:11Zに、DynamoDBテーブルへの書き込みを試みるコードと共にデプロイされましたが、CloudFormationテンプレートには必要なIAM権限が含まれていませんでした。
この設定ギャップは、ソースのCloudFormation/CDKテンプレート自体に存在します。Lambda関数のデプロイをロールバックしても、最初のデプロイ時のIAMロール設定が不十分だったため、問題は解決しません。
この問題を解決するには、Infrastructure-as-Codeテンプレートを更新し、Lambda実行ロールにDynamoDB権限を追加した上で、スタックを再デプロイする必要があります。
これは、即時の運用ロールバックや設定調整ではなく、コード変更と開発作業です。
おお！？急に良くなってるぞ？RunBookが読み込まれた感じがしますね！
でも調査段階で使ってくれていればコード分析もしっかりできたのでは。。。？
AWS DevOps Agentに調査を依頼する v4
調査段階でRunBookを使ってくれないものかと公式ページを調べると、どうやらチャット欄から「RunBookを使って再調査してくれ」って依頼できるようです。
依頼してみました。
調査してくれそう！
MCP Server使って調査してる！
きたあぁぁーーーー！！
意訳：
CDK codeのgrantのとこがコメントアウトされてるよ
根本原因はpackages/cdk/src/app.tsです。26行目のtable.grantReadWriteData(fn);がコメントアウトされてます。
これはLambda関数にDynamoDBテーブルのread&write権限を付与するコードです。コメントアウトすると権限がなくなりAccessDeniedExceptionエラーが発生するようになります。
完全に正解です！💯
これでAWS障害発生時にAWS DevOps Agentが勝手にコード上の主原因を見つけてくれる夢に近づきました！
まとめ
今回はAWS DevOps AgentとGitHubを連携させて、コード上のミスを特定させることに成功しました。
ゆくゆくは、夜中に問題が発生しても朝には修正PRが出されているような世界にぜひともたどり着きたいものです。
そのためにもまず、CloudWatch Alarmから自動的に調査を開始してくれないと。。。
そしてChatで依頼されなくてもRunBookを引き当てて調査してくれないと。。。
引き続きやりかたを調べてみます。
以上でした！
