AWS上で本番ワークロードを実行する組織にとって、インシデントの検出から調査、復旧までの時間を短縮することは重要な優先課題です。問題が発生した際、オンコールのエンジニアは、アプリケーションコンポーネント全体にわたって問題を迅速に診断し、根本原因を特定し、修正を適用する必要があります。多くの場合、それは深夜に行われます。
AWS DevOps Agent相関のあるメトリクス、ログ、アプリケーショントポロジーに基づいてインシデントを自律的に一日的にトリアージするAI搭載エージェントである、は、根本原因分析(RCA)と解決のための推奨アクションを提供することで、この優先事項の前半部分に対応します。しかし、コントロールを維持し意図しない変更を防ぐために、組織は通常、AWS DevOps Agentを含むオブザーバビリティエージェントを observe-and-report モード、つまりエージェントが問題を診断するものの本番リソースを直接変更しないモードで運用しています。本記事では、を使用する方法を紹介します。 AWS Lambda Durable Functions、AWS Lambdaの機能である Amazon EventBridge、および Amazon Bedrock AWS DevOps Agentを補完し、問題解決ステップを完了する自動修復ワークフローを作成します。このワークフローは調査サマリーを、単一の承認アクションで適用できる事前検証済みの修正に変換し、平均解決時間(MTTR)の削減と、オンコールエンジニアを反復的な診断作業から解放することを支援します。
ソリューション概要
With AWS Lambda Durable Functions耐障害性のあるマルチステップのアプリケーションやAIワークフローを、追加のインフラを管理したり、カスタムの状態管理やエラー処理のコードを書いたりすることなく、最長1年間実行できるように構築できます。これらの関数は進行状況を自動的にチェックポイントとして保存し、長時間実行されるタスクの間は実行を一時停止し、中断があっても信頼性の高い進行を維持しながら障害から回復します。
以下の図は、ソリューションアーキテクチャを示しています。
図1: AWS DevOps Agentによる調査からAmazon EventBridge、AWS Lambda、Amazon Bedrockを経由する自動修復ワークフロー。変更がインフラストラクチャに反映される前に、任意で人間による承認を行う
ワークフローは次のステップで構成されます:
- AWS DevOps Agent はインシデントの調査を完了すると、症状、調査結果、根本原因の分析を含むイベントを出力します。
- Amazon EventBridgeは調査完了イベントを受け取り、
devops-agent-trigger調査内容と連動して機能する。 - Lambda関数は調査サマリーをパッケージ化し、次を呼び出します。
devops-agent-remediation-durable持続的な機能。 - 永続的関数(Durable Function)は調査コンテキストを Amazon Bedrock に送信し、Amazon Bedrock が調査結果を分析して該当する修復方法を探します。
- Amazon Bedrock は、承認済みの Lambda 関数の厳選された許可リストから、利用可能な修復ツールを特定して一覧表示します。
devops-agent-lambda-tool. - Amazon Bedrock は、調査結果と利用可能なツールに基づいて、具体的な修復アクションを提案します。
- 読み取り専用のアクションについては、durable function が修復ツールを自律的に実行します。インフラストラクチャの変更については、ワークフローは一時停止し、待機します。 人間の承認 先に進む前に。
- 承認後、durable function は選択されたツールを使用してインフラストラクチャに修復アクションを適用します。
durable function は アジェンティックループとして実行され、Amazon Bedrock を繰り返し呼び出し、承認済みのツールを実行し、その結果を会話にフィードバックして、修復が完了するまで処理を続けます。自動アクションの安全性と監査可能性を保つため、オーケストレーターは厳選された修復ツールの許可リストを強制します。各ツールは、Lambda 関数の設定の読み取りや AWS Identity and Access Management (IAM) ポリシーステートメントの更新など、特定の明確に範囲限定されたアクションを実行する専用の Lambda 関数です。Amazon Bedrock はこの承認済みセットからのみツールを選択して呼び出すことができるため、自動アクションの範囲が管理された状態に保たれます。さらにワークフローは、読み取り専用操作と変更操作を区別します。読み取り専用ツールは人間の介入なしに自律的に実行されます。インフラストラクチャの状態を変更するような変更アクションが発生すると、durable function は実行を一時停止し、人間の承認を待ちます。ここで AWS Lambda Durable Functions が重要な利点を発揮します。この関数は進行状況を チェックポイント として保存し、コンピューティングリソースを消費せずに数分、数時間、あるいは数日間停止することができ、承認シグナルを受け取った後、中断した箇所から正確に処理を再開します。オンコールのエンジニアが対応する頃には、システムはすでに関連する設定を収集し、根本原因を利用可能な修復アクションと関連付け、ワンクリックで承認できる事前検証済みの変更一式を準備しています。現在の実装では承認または拒否のシグナルを使用します。コールバックは任意の JSON ペイロードを受け入れるため、承認にパラメーターの上書きやレビュー担当者の観察結果を持たせるように拡張することもできます。これらは実行前に Bedrock の会話にフィードバックされ、提案された修復の洗練に役立てられます。
以降のセクションでは、Amazon EventBridge ルールの設定や durable function のオーケストレーションロジックを含む実装の詳細を順に説明します。その後、 AWS Cloud Development Kit (AWS CDK) を使用してソリューションをデプロイします。
前提条件
このソリューションをデプロイする前に、次の前提条件が満たされていることを確認してください:
- インストールおよび設定済みの AWS Command Line Interface (AWS CLI)。
- Python 3.14 以降。
- インストール済みの AWS CDK 。
- 有効な AWS DevOps Agent スペース.
- (オプション) Kiro と Agent Toolkit for AWS。Agent Toolkit は、IAM ベースのアクセス制御を備えたマネージド MCP Server を通じて、AWS API への安全なアクセスを Kiro に提供します。Kiro を使用する場合、この記事のインシデントシミュレーション、デプロイ、クリーンアップの手順は、CLI コマンドを手動で実行する代わりに自然言語のプロンプトで完了できます。セットアップするには、AWS MCP Server を
~/.kiro/settings/mcp.json(セットアップ手順) に追加します。リポジトリには、プロジェクトのコンテキスト、デプロイの順序、および安全規約を Kiro に自動的に与える Kiro ルールおよびエージェントファイルが含まれています。
インシデントをシミュレートする
エンドツーエンドのワークフローを紹介するために、よくあるシナリオ、つまり設定されたタイムアウトを超える Lambda 関数をシミュレートします。これにより、AWS DevOps Agent に実際のインシデントを調査させ、修復ワークフローを開始します。
修復ソリューション自体に焦点を当て続けるため、このテスト関数を作成して呼び出す手順は リポジトリにまとめられています。ここにはすぐに使用できる devops-agent-timeout 関数と、それをデプロイ、呼び出し、Amazon CloudWatch Logs でタイムアウトエラーを確認するための手順が含まれています。詳細な手順については、 READMEの「インシデントをシミュレートする」セクション.
関数がデプロイされ、少なくとも1件のタイムアウトエラーが発生したら、AWS DevOps Agentを使った調査を開始する準備が整います。
AWS CDKを使用してソリューションをデプロイする
残りのソリューションリソースをデプロイするには、以下の手順を実行します。
Kiro: AWS用Agent Toolkitが設定されたKiroをお持ちの場合（前提条件を参照）、クローンしたリポジトリをKiroで開き、次のように依頼します。「Python環境をセットアップし、CDKスタックをデプロイしてください。デプロイ前に、作成されるリソースを見せてください。」Kiroはリポジトリからプロジェクトのルールを読み込み、仮想環境をセットアップし、依存関係をインストールした後、デプロイ前に計画されたリソースを表示します。リメディエーションソリューション自体が採用しているのと同じhuman-in-the-loopパターンに従い、実行前に各インフラ変更を確認します。手動でデプロイするには、以下の手順に従ってください。
- GitHubでホストされているAWS CDKコードをクローンします:
$ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git - ディレクトリに移動します
sample-automate-remediation-post-devops-agent-investigation:$ cd sample-automate-remediation-post-devops-agent-investigation - AWS CDKをブートストラップします。これは、特定のAWS環境でAWS CDKを初めて使用する際に必要です。 環境 「(AWSアカウントとAWSリージョンの組み合わせ)。」
$ cdk bootstrap - スタックをデプロイします:
$ cdk deploy
AWS CDKは、以下のリソースを自動的にプロビジョニングおよび設定します:
- 3つのLambda関数:\n
devops-agent-trigger.devops-agent-remediation-durable.devops-agent-lambda-tool.
- Amazon EventBridge ルール。
AWS CDK は、最小権限の原則と AWS のセキュリティベストプラクティスに基づいて IAM 権限を自動的に処理します。たとえば、Amazon EventBridge には次が付与されます。 lambda:InvokeFunction 以下はその権限です。 devops-agent-trigger 機能。スタックは aidevops:ListJournalRecords への許可 devops-agent-trigger AWS DevOps Agent のジャーナルから調査サマリーを取得できるようにする function です。また、 bedrock:InvokeModel への許可 devops-agent-remediation-durable Amazon Bedrock を呼び出せるようにするための関数です。
ソリューションを検証する
修復スタックがデプロイされ、 devops-agent-timeout タイムアウトエラーで失敗する関数については、これからエンドツーエンドのワークフローを順に見ていくことができます。
AWS DevOps Agentで調査を開始する
開く AWS DevOps Agent コンソール、エージェントスペースに移動し、次のように尋ねてください:「devops-agent-timeout 関数に何が起きているのですか？”
図2:AWS DevOps Agentコンソールから調査を開始する
調査が開始され、完了までに数分かかります。この間、AWS DevOps Agent が CloudWatch のメトリクス、ログ、および関数の設定を自律的に相関分析し、根本原因を特定します。
図3：調査中にシグナルを関連付けているAWS DevOps Agent
調査が完了すると、AWS DevOps Agent は根本原因分析を提示し、関数のタイムアウトがワークロードに対して不十分であることを特定します。
図4: 不十分な関数タイムアウトを特定する根本原因分析
トリガーとなったLambdaの実行を確認する
調査の完了は以下を出力します: 調査完了 「Amazon EventBridge。」
このルールは devops-agent-trigger AWS DevOps Agentのジャーナルから調査サマリーを取得するLambda関数です。この /aws/lambda/devops-agent-trigger CloudWatchロググループでは、送信された解析済みサマリーを確認できます。 devops-agent-remediation-durable 耐久性のある機能（durable function）、症状、根本原因、寄与する原因、および調査の隙間について。
図5：トリガー関数の CloudWatch ロググループに表示された解析済み調査サマリー
Durable Functions の実行を監視する
次へ移動します: Lambda コンソール, 開きます devops-agent-remediation-durable 関数を選択し、 永続的な実行 タブ。新しい実行を選択して、チェックポイントされたステップを確認します。
Figure 6:Lambdaコンソールにおける永続関数の実行とチェックポイントされたステップ
永続的なオーケストレーターは、調査コンテキストをAmazon Bedrockに送信することでエージェenticループを開始します。最初のBedrock呼び出しで、モデルは調査サマリーを分析し、修正案を提示する前に現在の関数設定を確認する必要があると判断します。そして、 lambda_get_function_configuration ツールを許可リストから取得します。これは読み取り専用操作であるため、人間の承認を必要とせずに自律的に実行されます。ステップの結果には、このツールの現在の構成が表示されます。 devops-agent-timeout 関数は、タイムアウト値が3秒であることを確認しています。
図7: 現在の3秒のタイムアウト設定を返す読み取り専用ツール呼び出し
Amazon Bedrockが修復措置を提案します
現在の構成が確認されると、Amazon Bedrock は次のイテレーションに進みます。3秒のタイムアウトが失敗の根本原因であると推論し、それを30秒に引き上げることを提案します。Amazon Bedrock のレスポンスには、推論とツール呼び出しの両方が含まれています。
{
....
},
"output": {
"message": {
"role": "assistant",
"content": [
{
"text": "Now I can see the current configuration confirms the issue - the function has a 3-second timeout. Given that this appears to be a test function for timeout scenarios (based on the name \"devops-agent-timeout\" and its association with \"DevOps Agent Test Infrastructure\"), I'll increase the timeout to a reasonable value that should allow the function to complete successfully. I'll set it to 30 seconds, which is a common timeout for Lambda functions that need more execution time."
},
{
"toolUse": {
"toolUseId": "tooluse_lcGHbWDxng5HiLpmhWagDS",
"name": "lambda_update_function_configuration",
"input": {
"FunctionName": "devops-agent-timeout",
"Timeout": 30
},
"type": "tool_use"
}
}
...
}なぜなら lambda_update_function_configuration はミューテーション(変更)アクションであり、durable functionは実行を一時停止し、人間の承認を待ちます。
図8: 承認リクエストに対する Lambda Durable 関数の cloudwatch logs の出力
重要: ザ investigation_summary Amazon Bedrock に送信される内容と、そこで提案される修復措置は AI によって生成されるため、承認前に必ず確認する必要があります。人間による承認ゲートがセキュリティコントロールです。承認者はツールのパラメータ全体(たとえば、正確な FunctionName および Timeout の中の lambda_update_function_configuration を呼び出し)、変更が正しいことを確認します。
AWS CLI を使用する場合:
$ aws lambda send-durable-execution-callback-success \
--callback-id <callback-id> \
--cli-binary-format raw-in-base64-out \
--result '{"approved": true}'AWSコンソールを使用する場合:
永続実行に移動し、保留中のコールバックを選択して、選択します 送信成功 確認のため:
図9：Lambdaコンソールで「Send success」を選択して修復を承認する
入力フィールドに次のように入力します {'approved': true} 確認してください。
図10: コールバックを確認するための承認ペイロードの入力
修正を検証する
承認後、永続関数が再開され、ツールの Lambda を呼び出して設定を更新し、Amazon Bedrock が修復の完了を確認します。更新された devops-agent-timeout 関数は新しいタイムアウト値を表示するようになります:
図11:devops-agent-timeout関数の構成を30秒のタイムアウトに更新したところ
最終ステップの出力(bedrock-call-4) で修復の成功を確認します:
{
"EventType": "StepSucceeded",
"Name": "bedrock-call-4",
....
},
"output": {
"message": {
"role": "assistant",
"content": [
{
"text": "## Remediation Complete
**Issue Identified:** The Lambda function `devops-agent-timeout` in eu-west-1 was configured with a 3-second timeout that was insufficient for its execution time, causing timeout errors at exactly 3000ms.
**Action Taken:** Successfully updated the Lambda function configuration to increase the timeout from 3 seconds to 30 seconds.
**Verification:** Confirmed the configuration change was applied successfully. The function now has:
- **Timeout:** 30 seconds (increased from 3 seconds)
- **Status:** Successful update completion
- **LastModified:** 2026-05-22T11:11:28.000+0000
This remediation should resolve the timeout errors by providing the function with adequate time to complete its execution. The 30-second timeout provides a 10x increase from the original 3-second limit, which should be sufficient for most operations while still maintaining reasonable execution bounds for a Lambda function."
}
]
}
},
"stopReason": "end_turn",
...
}インシデント検出から自動修正までのこの一連のサイクル全体において、エンジニアに必要だったのはたった1回の承認アクションだけでした。システムは診断、構成の取得、修復案の提示、そして実行を自律的に処理しました。
クリーンアップ
以下の手順を実行して、作成したリソースをクリーンアップします:
Kiro: AWS向けAgent ToolkitでKiroを使用している場合は、次のように質問してください: 「DevOps Agent 復旧デモのすべてのリソースをクリーンアップしてください: CDK スタックを破棄し、devops-agent-timeout テスト関数、その IAM ロール、および CloudWatch ロググループを削除してください。」 Kiro はリソースを正しい順序で削除し、各破壊的なアクションを次に進める前に確認します。手動でクリーンアップするには、以下の手順に従ってください。
- AWS CDKのリソースを削除します:
$ cdk destroy - 手動で削除してください。
devops-agent-timeoutインシデントをシミュレートする関数:$ aws lambda delete-function --function-name devops-agent-timeout - IAMロールとCloudWatchロググループを手動で削除する
devops-agent-timeout関数:$ aws iam detach-role-policy \ --role-name devops-agent-timeout-role \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole $ aws iam delete-role --role-name devops-agent-timeout-role $ aws logs delete-log-group --log-group-name /aws/lambda/devops-agent-timeout
結論
この記事では、Lambda Durable Functions、Amazon EventBridge、および Bedrock を DevOps Agent と組み合わせて使用し、問題の修復を自動化する方法を紹介しました。このソリューションは AWS DevOps Agent の後続の処理を担い、調査サマリーを、承認者の確認 (human-in-the-loop) を伴って実行される実行可能な修復ステップへと変換します。このアプローチにより平均解決時間 (MTTR) が短縮されます。オンコール エンジニアが対応を開始する時点で、システムはすでに問題を診断し、現在の設定情報を収集し、承認待ちの修正案を準備し終えているためです。安全性も設計の中心に据えられています。許可リストにより、Amazon Bedrock が呼び出せるのは事前に承認されたツールのみに制限され、人間による承認ゲートが、明示的な許可のない意図しない変更が本番環境に到達するのを防ぎます。このアーキテクチャは本質的に拡張可能でもあります。新しい修復機能の追加に必要なのはツールレジストリの設定更新のみで、オーケストレータのコード変更は不要です。さらに、AWS Lambda Durable Functions は承認待ちの間、コンピューティングリソースを消費せずに一時停止するため、承認サイクルが数時間や数日にわたる場合でも、このソリューションはコスト効率に優れた状態を保ちます。
このソリューションの使用を開始するには、以下から完全な AWS CDK テンプレートをダウンロードしてください。 GitHubリポジトリ、その後、この投稿の手順に従って環境にソリューションをデプロイしてください。
ぜひご意見をお聞かせください。このソリューションの実装経験を共有したり、質問をしたり、改善案を提案したりするには、コメントをご利用ください。また、 AWS Community Builders プログラムに参加して、他のビルダーと交流し、サーバーレスアーキテクチャのパターンを共有することもできます。