概要
最近注目しているサービスの一つがAWS DevOps Agentです。先日のAWS SummitでもDevOps Agentについてディスカッションさせていただいたり、下記のセッションを聞きました。
セッションの中で設計のベストプラクティスの話がありましたので、ガバメントクラウドでDevOps Agentを利用する場合、どのように利用するのが良いか主に調査スコープの観点で考えてみました。
「AWS DevOps Agent による自律的インシデント対応 —その能力を引き出す設計のベストプラクティス—」
設計のベストプラクティス
上記セッションの中で下記3つの設計に関するベストプラクティスの話がありました。
- 調査スコープを決めて精度を引き出す
- テレメトリを充実させて正確性を上げる
- ナレッジを共有して時間を短縮する
今回はこの中で特に「調査スコープに合わせてAgent Spaceを設計する」点について見ていきます。
- 依存先まで含めて1つのAgent Spaceにまとめる
- 環境やチーム単位で複数のAgent Spaceに分ける
エージェントスコープとマルチアカウントアクセス
Agent SpaceとはDevOps Agentの調査スコープを定義する論理コンテナです。つまりDevOps Agentがアクセスできる範囲を定義します。
こちらはDevOps Agentコンソールのセカンダリソースから設定をすることができますが、仕組みとしては、アクセスされる側（セカンダリアカウント）に下記のような信頼ポリシーを持つIAMロールが作成され、設定したAgent Spaceから調査のためにアクセス可能となっています。作成されたIAMロールには調査のために下記の権限が付与されています。
許可ポリシー
| コンポーネント | 役割 |
|---|---|
| AIDevOpsAgentAccessPolicy（AWS管理ポリシー） | 調査に必要なリソースへのアクセス権限を付与 |
| DevOpsAgentInlinePolicy（インラインポリシー） | Agent Space固有の追加権限（Resource Explorerのサービスリンクロール作成等） |
信頼ポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:aidevops:ap-northeast-1:123456789012:agentspace/11111111-2222-3333-4444-xxxxxxxxxxxx",
"aws:SourceAccount": "123456789012"
}
}
}
]
}
ポイントとして、Principalにはサービスプリンシパル aidevops.amazonaws.com が指定されており、Conditionの aws:SourceArn と aws:SourceAccount により特定のAgent Spaceからのアクセスのみに制限されています。
ガバメントクラウド共同利用方式での利用
上記ベストプラクティスやエージェントスコープから設計について考えてみます。
まず、共同利用方式でのDevOps Agentの利用からです。共同利用方式ではベンダー（ASP）視点の設計になります。
下記のようにASP1が自治体Aと自治体Bに個別のASPアカウントの領域を提供しており、各アカウントを管理する共通利用領域がある、アカウント分離設計を前提に考えてみると、共通利用領域側でAgent Spaceを作成して、各個別ASP領域をセカンダリアカウントとしてAgent Spaceに追加していく構成が考えられます。
ガバメントクラウド単独利用方式での利用
全てのシステムが単独利用方式での構成を想定します。単独利用方式は自治体側でのアカウント管理となるため、自治体視点の設計になります。
例えばネットワークアカウントのような管理用アカウントにAgent Spaceを作成して、各ASPアカウントをセカンダリアカウントとしてAgent Spaceに追加していくことによって、自治体内のシステム全体を調査対象にしていく構成が考えられます。
おまけ（テレメトリを充実させて正確性を上げる）
ベストプラクティスの一つに、調査の精度を上げるには調査対象のメトリクスを拡充するという考え方があります。セッションでは、Insightsファミリーを使用してサービスの内部状態のメトリクスを追加する話がありました。
ガバメントクラウド観点でメトリクスの拡張を考えた際、オンプレミスとのハイブリッド環境のため、オンプレミス側のログを調査対象に含めるということが考えられます。
先日下記のように、ネットワーク機器などのSyslogをCloudWatch Logsに取り込めるアップデートがありました。VPCエンドポイント経由でエージェントレスにSyslogを受信する仕組みです。こういった観点でAWS側に情報を集約する設計を考えると、DevOps Agentの調査精度がさらに向上する可能性があります。
Amazon CloudWatch Logs がマネージド型の syslog 取り込みをサポート
https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-cloudwatch-syslog-ingestion/
