0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kobayashi_0226(riku kobayashi)

AWS DevOps Agentの調査ってどんな感じなんだろうか

0
Posted at

大規模なシステムで障害調査・アラート確認を人力で行うと多大な工数がかかり、本業に手がつかないということがシステム管理者をやられている方であれば経験のあることだと思います。
このような問題を軽減できる可能性があるAWS DevOps Agentを触ってみました。

AWS DevOps Agentとは

AWS re:Invent 2025で発表されたインシデントの検知・調査といったことをやってくれるAIエージェントサービスです。

AWSのサービス紹介ページだと以下のように記載されていました。
https://aws.amazon.com/jp/devops-agent/

AWS DevOps エージェントは、インシデントを解決、予防し、信頼性とパフォーマンスを継続的に向上させるフロンティアエージェントです。経験豊富な DevOps エンジニアと同じようにインシデントを調査し、運用上の改善点を特定します。そのために、リソースとその関係を学習し、オブザーバビリティツール、ランブック、コードリポジトリ、CI/CD パイプラインを使用し、それらすべてにわたってテレメトリ、コード、デプロイデータを相互に関連付けて、マルチクラウド環境やハイブリッド環境のアプリケーションを含むアプリケーションリソース間の関係を把握します。また、運用とワークロードに関する深い理解を活用して、MTTR (平均解決時間) を短縮し、運用上の優秀性を推進します。

フロンティアエージェントという聞きなれないものがあるのですが、自律してタスクなどをこなしていくエージェントのことらしいです。
説明文を読む限りでは私たちユーザーから問い合わせを出さなくても自動で調査してくれるらしいのでアラートが出て調査依頼みたいなことをしなくてもよさそうな雰囲気を感じます。

フロンティアエージェントは、目標を達成するために独立して動作し、同時実行タスクに対応するために大規模にスケールして、介入なしで数時間または数日間にわたって持続的に動作する自律システムです。個々のタスクをサポートする従来の AI アシスタントとは異なり、フロンティアエージェントはチームの拡張機能として機能し、多様なユースケースにわたって包括的な成果をもたらします。

検証で使う構成

今回は以下の構成を作って確認してみます。
AWS DevOps Agentがどのような環境で強みを発揮出るのか確認したかったので3環境見てみます。

  1. API Gateway + Lambda + DynamoDB
  2. S3 + EventBridge + ECS
  3. ALB + EC2 (SSM Agentは入れない)

作成したコードは以下のGitHubリポジトリに格納してあります。
https://github.com/Kobayashi-Riku0226/AWS-DevOps-Agent-test

環境作成

1. API Gateway + Lambda + DynamoDB

以下のようにリソースごとにコードを分けて記載しています。
詳しくはGitHubリポジトリを見ていただきたいのですが、Lambdaプロキシ統合が有効になったAPI GatewayとPythonのLambda、DynamoDB、Lambdaの使用するIAMロールが一括で作成できるコードになります。

.
├── apigateway.tf
├── dynamodb.tf
├── iam.tf
├── lambda
│   └── index.py
├── lambda.tf
├── main.tf
└── outputs.tf

以下のコマンドでデプロイできます。

terraform init
terraform plan
terraform apply

デプロイ後、DynamoDBに以下のコマンドでデータを入れます。

aws dynamodb put-item \
  --table-name users \
  --item '{"id": {"N": "1"}, "username": {"S": "hoge"}, "registered_date": {"S": "2026-05-10"}}'

以下のcurlコマンドを実行してDynamoDBに入れたデータが確認できればリソース作成完了です。

curl https://<api-id>.execute-api.ap-northeast-1.amazonaws.com/prod/users?userid=1  

# 以下のようなレスポンスが確認できる
## useridが正しいとき
{"username": "hoge", "registered_date": "2026-05-13"}

## useridを渡していないとき
{"error": "userid is required"}

## useridが存在しないとき
{"error": "User not found"}

2. S3 + EventBridge + ECS

こちらもリソースごとにtfファイルを分割しています。
デプロイするとS3、EventBridgeルール、ECS、VPC、IAMなどが作成されます。

.
├── app
│   ├── Dockerfile
│   └── index.py
├── ecr.tf
├── ecs.tf
├── eventbridge.tf
├── iam.tf
├── main.tf
├── outputs.tf
├── s3.tf
├── variables.tf
└── vpc.tf

variables.tfにS3バケット名を入れているので、デプロイ前に任意の値に変更してください。

variable "aws_region" {
  default = "ap-northeast-1"
}

variable "app_name" {
  default = "devops-agent-test-s3-ecs"
}

variable "bucket_name" {
  default = "devops-agent-test-s3-ecs-AWSアカウントID"
}

変更したら以下のコマンドでデプロイします。

terraform init
terraform plan
terraform apply

AWSリソースの作成が完了したら作成したDockerfileのあるディレクトリに移動してDockerイメージを作成します。

aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin AWSアカウントID.dkr.ecr.ap-northeast-1.amazonaws.com
docker build -t devops-agent-test-s3-ecs .
docker tag devops-agent-test-s3-ecs:latest AWSアカウントID.dkr.ecr.ap-northeast-1.amazonaws.com/devops-agent-test-s3-ecs:latest
docker push AWSアカウントID.dkr.ecr.ap-northeast-1.amazonaws.com/devops-agent-test-s3-ecs:latest

S3バケットに何かしら入力したテキストファイルをアップロードしてください。
アップロード後、ECSが動き出しCloudWatch Logsに以下のようにログが出力されれば準備完了です。
スクリーンショット 2026-05-13 163110.png

3. ALB + EC2 (SSM Agentは入れない)

こちらもTerraformで作成していきます。

.
├── alb.tf
├── ec2.tf
├── main.tf
├── output.tf
├── sg.tf
├── terraform.tfvars
├── variables.tf
└── vpc.tf

デプロイ前にterraform.tfvarsのkey_nameとssh_allowed_cidrを変更します。
key_nameは事前にAWS上にキーペアを作成しておいてください。
allowed_cidrはALBとEC2のセキュリティグループで許可するIPアドレスです。
SSHやHTTPでのアクセスに使用するので、自宅のパブリックIPアドレスを記載してください。

aws_region          = "ap-northeast-1"
vpc_cidr            = "172.17.0.0/16"
public_subnet_cidrs = ["172.17.1.0/24", "172.17.2.0/24"]
availability_zones  = ["ap-northeast-1a", "ap-northeast-1c"]
instance_type       = "t3.micro"
ami_id              = "ami-0478d64d580a0c8e5"
key_name            = "your-key-pair-name"
project_name        = "devops-agent-test-alb-ec2"
allowed_cidr        = "0.0.0.0/0"

terraform.tfvarsを編集したら以下のコマンドでリソースを作成します。

terraform init
terraform plan
terraform apply

EC2の作成が完了したら以下のコマンドでALBへのアクセスとEC2へのアクセスができることを確認します。

curl http://ALB DNS名

ssh -i キーペア名.pem ubuntu@EC2のパブリックIP

AWS DevOps Agentの設定

DevOps Agentを使い始めるには以下のドキュメントに記載されている通りエージェントスペースというものを作成する必要があるみたいです。

ドキュメントの指示に従って作成してみます。
以下のURLからDevOps Agentの画面に飛びます。
https://ap-northeast-1.console.aws.amazon.com/aidevops/home?region=ap-northeast-1#/overview

DevOps Agentの画面を開いたら左のメニューにある「エージェントスペース」をクリックして「エージェントスペースを作成」をクリックします。
スクリーンショット 2026-05-13 171015.png

名前は任意のもので大丈夫そうです。
エージェントの応答言語も好きなもので問題なさそうなので日本語にしておきました。
IAMロールは自動作成にしています。
スクリーンショット 2026-05-13 171436.png

下の方に進むとウェブアプリを有効化という項目が出てきますが、ここもIAMロールの新規作成にしておきます。
スクリーンショット 2026-05-13 171638.png

ウェブアプリはユーザーとDevOps Agentがやり取りするためのUIのことみたいですね。

ウェブアプリは、担当者がインシデント調査とレコメンデーションの確認のために AWS DevOps エージェントとやり取りする場所です。詳細については、 AWS DevOps エージェントコンソールアーキテクチャ〔リンク〕」を参照してください。有効にすると、ユーザーは AWS マネジメントコンソールから IAM 認証リンクを介して エージェントスペースウェブアプリにアクセスできます。

ここまで出来たら作成をクリックします。

作成ができたら機能タブを見てみます。

クラウドという項目では別のAWSアカウントを調査させるための項目のようです。
他にも2026/05/13時点ではAzureも接続して調査させることができるみたいです。

スクリーンショット 2026-05-13 172038.png

テレメトリという項目ではDatadogなどに接続して調査させるようなことをするための項目のようです。
以下のドキュメントを見る限りDatadog以外にもGrafana、New Relic、Splunk、Dynatraceに接続することができるようなので、対応している監視サービスは幅広いラインナップになっているのではないかと思います。

スクリーンショット 2026-05-13 172546.png

パイプラインという項目ではGitHubやGitLabに接続してCI/CDでのデプロイイベントを調査させることが可能なようです。

スクリーンショット 2026-05-13 173047.png

コミュニケーションという項目ではSlackなどのチャットアプリと連携してDevOps Agentの調査結果をチャットに連携するようなことが可能になっています。

スクリーンショット 2026-05-13 173459.png

MCPサーバーという項目ではDevOps AgentにMCPサーバーを追加して調査の拡張性を持たせるといったことができるようです。
例えば以下のブログで紹介されているような独自のMCPサーバーを作成すればZabbixとの連携などもできます。

スクリーンショット 2026-05-13 173725.png

最後にウェブフックという項目です。
Webフックを使用することで外部からの連携をもとに調査を開始させるといったことができるようです。
ユースケースとしてはAWS外と連携しているようなシステムで外部システム側のエラー検知をもとにウェブフックで調査させるみたいなのができそうです。
スクリーンショット 2026-05-13 174351.png

機能を確認してみたので早速チャット画面を見てみます。
ウェブアプリタブを開いてオペレータアクセスをクリックしてください。
スクリーンショット 2026-05-13 180336.png

クリックすると別タブでチャット画面が出てきます。

スクリーンショット 2026-05-13 180446.png
スクリーンショット 2026-05-13 180647.png

調査させてみる

疑似的に問題を起こして調査させたいので各環境で何かしら設定を外してみたり内部から負荷をかけるようなことをしてみます。

1. API Gateway + Lambda + DynamoDB

ここではLambdaのIAMロールからDynamoDBの権限を外してエラーを起こしてみたいと思います。
エラーを起こす前にAPI Gatewayの5XXErrorメトリクスにCloudWatch Alarmを設定しておきます。
閾値などは任意の値でとりあえず5xxエラーが出た時に反応するようにします。
スクリーンショット 2026-05-13 184728.png

アラームが設定できたらLambdaのIAMロールからDynamoDBへのアクセス権限を外してみます。
get-user-lambda-roleからdynamodb-readを削除してください。
スクリーンショット 2026-05-13 182226.png

削除が完了したらAPI Gatewayにcurlコマンドでアクセスします。
IAMを編集してしばらくすると以下のようにInternal server errorになります。

curl https://<api-id>.execute-api.ap-northeast-1.amazonaws.com/prod/users?userid=1
{"error": "Internal server error"}

CloudWatch Alarmが反応したらチャット画面にあるインシデントレスポンスで調査を開始します。
スクリーンショット 2026-05-13 184905.png
スクリーンショット 2026-05-13 185022.png

調査の履歴を見るとLambdaのCloudWatch Logsなどを読み込んでなぜエラーになったのかを確認しているのが見れます。
スクリーンショット 2026-05-13 192402.png
スクリーンショット 2026-05-13 192518.png

根本原因タブを開くとIAMの問題について記載されているのと、Lambdaの環境変数がおかしいというのが報告されています。
環境変数の問題は変更した記憶がないかつLambdaの画面でも設定されていたので、なぜ発生したか分からなかったですが、IAMの問題が特定できているのはよさそうです。
スクリーンショット 2026-05-13 192904.png

このようなサーバーレスな環境の調査はかなり有用な感じに見えます。

2. S3 + EventBridge + ECS

S3にメモリエラーが出る程度のオブジェクトを配置してECSのエラーを誘発してみます。

検知については以下のブログを参考に設定します。

設定は以下のような形でターゲットはとりあえずAmazon SNSにしています。
スクリーンショット 2026-05-13 195619.png

EventBridgeができたらInvocationsメトリクスにでアラームを設定します。
スクリーンショット 2026-05-13 200450.png

1. メモリエラー誘発

準備できたら1の方から試してみます。
以下のコマンドでテストに使用するファイルを作成します。(出来上がるのに30秒くらいかかります)

base64 /dev/urandom | head -c 3G > large.txt

ファイルができたらS3にアップロードしてください。
アップロードしてしばらくするとECSタスクがOutOfMemoryErrorで停止します。
異常停止になるのでCloudWatchアラームが反応したら調査開始します。

以下のように調査させます。
おそらくここら辺は該当するアラーム名やクラスター名などを入れるとより精度が上がるのではないかと思います。
スクリーンショット 2026-05-13 200950.png

調査の履歴を見るとメトリクスからEventBridgeを特定しています。
さらにその中のルールからECSクラスターを特定して調査が進んでいっています。
スクリーンショット 2026-05-13 201118.png

ちゃんと問題のS3オブジェクトまで特定できていそうです。
スクリーンショット 2026-05-13 201408.png

根本原因タブを見ると結果が見れます。
メモリ不足というところから該当のオブジェクトまであたりをつけているので調査としては問題なさそうです。(ファイル名から推測してそうなところもあるのでテストが微妙だったかもしれません)
スクリーンショット 2026-05-13 201608.png

ECSの場合も起動失敗の記録などがあるので調査しやすいのかもしれません。

3. ALB + EC2 (SSM Agentは入れない)

最後にEC2内のPHPから5xxを返して調査させてみます。

sudo apt install php libapache2-mod-php -y
sudo systemctl restart apache2
echo '<?php http_response_code(500); exit; ?>' | sudo tee /var/www/html/test.php

同じようにALBのメトリクスのHTTPCode_Target_5XX_Countでもアラームを作成しておきます。
コマンドを実行したらtest.phpにアクセスしてみてください。

curl http://ALBのDNS名/test.php

しばらくするとアラームが反応するのでDevOps Agentで調査を行わせます。
スクリーンショット 2026-05-13 230733.png

調査が開始されるとAlarmの内容からALBとターゲットの中身を確認しにいっていることがわかります。
スクリーンショット 2026-05-13 230910.png

レスポンスタイムなども見てALBの問題ではないということを判断してくれています。
スクリーンショット 2026-05-13 231143.png

ターゲットのEC2に問題が無いかもちゃんと見てくれています。
スクリーンショット 2026-05-13 231314.png

最終的な調査結果としてはEC2の負荷によって発生したのではという内容になりました。
該当のEC2はOS内の情報をAWSに出していないので、今あるCloudWatchメトリクスから判断して仮説を立てる動きになりました。
スクリーンショット 2026-05-13 231452.png

やはり、OS内部の調査まではできないので整備されていない環境だとパフォーマンスが発揮できないようです。

さいごに

今回はAWS DevOps Agentを触ってみました。
一次調査としてはかなり心強いサービスなのではないかと思います。
ただし、AWSへ十全な情報を渡せていない環境だとパフォーマンスが出せないので、DevOps Agentを入れる前にしっかりと整備をしておく必要がありそうです。

以下のドキュメントに料金が記載されているのですが、調査させると1秒当たり0.0083USDらしいです。
また、有料のAWSサポートを使用しているとプランごとに毎月クレジットをもらえるとのこと。 (私のアカウントはBusiness Support+を使用しているので8ドルくらい？)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?