AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス

インシデント発生時の根本原因分析は、クラウドアプリケーション運用において最も時間がかかり、ストレスの大きい作業の一つです。エンジニアは複数のサービスにまたがるテレメトリデータを迅速に相関づけ、デプロイ履歴を確認し、複雑なアプリケーションの依存関係を把握しなければなりません。しかもそのすべてを、サービス復旧というプレッシャーの中で行う必要があります。AWS DevOps Agent は、運用チームに自律的な調査能力をもたらすことでこのパラダイムを変革し、平均復旧時間 (MTTR) を数時間から数分に短縮します。

ただし、AWS DevOps Agent の効果は、リソースアクセスの境界を制御する Agent Space の設定に大きく左右されます。Agent Space の範囲が狭すぎると、調査中に重要なコンテキストを見逃してしまいます。逆に広すぎると、パフォーマンスのオーバーヘッドや複雑さが増大します。本記事では、調査能力と運用効率のバランスを取る Agent Space のセットアップに関するベストプラクティスを、早期に導入いただいたお客様のオンボーディングや社内チームでの DevOps Agent 活用経験をもとに紹介します。

本記事を読み終えると、最適な調査精度を実現するための Agent Space の構成方法、適切なリソースアクセス範囲の決定方法、そして Infrastructure as Code (IaC) を活用したデプロイの効率化について理解できるようになります。まずは、これらすべてを可能にする基本概念である Agent Space そのものについて理解しましょう。

Agent Space とは何か、なぜ重要なのか

Agent Space は、AWS DevOps Agent がアクセスおよび調査できる範囲を定義する論理的なコンテナです。エージェントの運用範囲と考えてください。どのクラウドアカウントをエージェントがクエリできるか、どのサードパーティ統合が利用可能か、誰が調査に関与できるかを決定します。

Agent Space が重要なのは、AWS DevOps Agent が正確な根本原因分析を行うために十分なコンテキストを必要とするからです。

インシデントが発生すると、エージェントは以下の処理を実行します。

アカウント全体のリソースとその関係性を学習します。
ログ、メトリクス、トレースからテレメトリデータを相関分析します。
デプロイや設定変更を含む最近の変更をレビューします。
追加のデータソースにクエリを行い、仮説を生成・検証します。

図1: Agent Space トポロジー

Agent Space に重要なアカウントや統合へのアクセスが含まれていない場合、エージェントは根本原因を完全に見逃す可能性があります。逆に、Agent Space が広すぎる場合、調査中にエージェントがより多くのリソースの組み合わせを考慮するため、パフォーマンス上の課題が生じます。

スコープとパフォーマンスのトレードオフを理解することが不可欠です。問いはこうなります。“自組織の運用モデルに適した境界をどのように決めれば良いのでしょうか？“

パート1：Agent Space アーキテクチャの設計

Agent Space の境界は、オンコールの責任範囲と同じように考えることを推奨します。アプリケーションに関連するアカウントへのアクセスを付与しつつ、本番環境と非本番環境は分離します。

このアプローチには以下のメリットがあります。

理解しやすい考え方: 運用チームはすでにオンコールの境界を理解しています。
適切な調査スコープ: 人間のエンジニアがインシデントを調査する方法を反映しています。
Two-way door (可逆的) な決定: 必要に応じて Agent Space のスコープを拡大・縮小できます。
パフォーマンスのバランス: エージェントに過剰な情報を与えることなく、十分なコンテキストを提供します。

Agent Space の境界を決定する

まず、アプリケーションアーキテクチャを Agent Space の境界にマッピングし、以下の質問を検討します。

何をもって 1 つの論理的なアプリケーションと見なすか？
- チームが複数の独立したアプリケーションを所有している場合は、別々の Agent Space を作成します。ただし、アプリケーションが密結合（例：相互依存するマイクロサービス）で、単一のリゾルバーグループ（オンコール担当グループ）にマッピングされる場合は、グループごとに1つの Agent Space を検討します。
- 複数のアカウントにまたがるモノリスの場合は、クロスアカウントアクセスを持つ1つの Agent Space が適切です。
オンコールローテーションはどのように編成されているか？
- 本番と非本番で別々のチームがある場合は、別々の Agent Space を推奨します。
- 1つのチームがすべての環境を担当する場合は、アプリケーションごとに1つの Agent Space で対応できます。
調査パターンはどうなっているか？
- 本番インシデントで他のアカウントの依存サービスへのクエリが必要な場合は、それらのアカウントを含めます。
- 環境が完全に分離されている場合は、Agent Space も分離します。

決定ツリーの例:

アプリケーション：Eコマースプラットフォーム
├── 本番環境
│ ├── アカウント 111111111111（フロントエンド）
│ ├── アカウント 222222222222（API Gateway + Lambda）
│ └── アカウント 333333333333（RDS + DynamoDB）
├── ステージング環境
│ └── アカウント 444444444444（全リソース）
└── 開発環境
└── アカウント 555555555555（全リソース）

推奨 Agent Space：
→ "EcommerceProd"（アカウント 111111111111, 222222222222, 333333333333）
→ "EcommerceNonProd"（アカウント 444444444444, 555555555555）

Figure 2: Agent Space boundaries mirror on-call team responsibilities

図2. Agent Spaceの境界はオンコールチームの責任範囲を反映する

一般的な Agent Space パターンと判断ポイント

基本的な単一アプリケーションパターン以外にも、慎重な検討が必要なより複雑なシナリオがあります。以下は、お客様が実際に採用して成功しているパターンです。

パターン1: 複数チームにまたがる調査

大規模な組織で複数のチーム（例：100以上の本番アカウントを管理する3チーム）がある場合、チームAのインフラストラクチャで問題が発生しても、根本原因がチームBのサービスにあるという状況が発生します。問題は、Agent Space 間のコラボレーションをどのように実現するかです。

推奨アプローチ：共有リソースアカウント（依存先など）への読み取り専用アクセスを含むアプリケーション固有の Agent Space を作成します。明確なオンコールエスカレーション手順を確立しランブックとして追加します。これは根本原因がチームにまたがる場合、効率的なコミュニケーション（例：Slack)に有用です。共有サービスチームのリソースには、どのアプリケーションが使用しているかを識別するタグ（例：app-id: ecommerce-frontend）を設定します。一貫したタグ付け戦略に従うことで、明確なリソース所有権を維持しながら、共有リソースの調査コンテキストを提供できます。

パターン2: 共有サービスとネットワークオペレーションセンター (NOC) チーム

一部の組織には、組織全体の複数のアプリケーションで使用される共有インフラストラクチャサービス（データベース、ネットワーク、モニタリング、セキュリティ）を提供・サポートする集中型チームがあります。これらの NOC や中央運用チームは、すべてのアプリケーションの Agent Space にアクセスすることなく、自分たちのサービスへの可視性を必要とします。

推奨アプローチ：共有サービスチーム専用の Agent Space を作成し、チームのインフラストラクチャと運用責任をスコープに設定します：

共有データベース、ネットワークインフラストラクチャ、集中ログ、モニタリングシステムを含む AWS アカウントを含めます。
チームがサポートする特定のリソースへの読み取り専用アクセスを提供する IAM ロールを設定します。
共有サービス固有のランブックと運用手順を含めます。

これは、アプリケーション固有の Agent Space と同じ原則に従います。Agent Space がスコープとして複数のアプリケーションにまたがる場合でも、オンコールチームごとに1つの Agent Space です。

パターン3: 多数のアプリケーションを管理する中央運用チーム

共有サービスチームが特定のインフラストラクチャドメインを管理する一方で、SRE チームはさらに大きな課題に直面することがあります。エンタープライズ規模で数百から数千のアプリケーションに対する運用責任です。運用ツールを担当する中央運用チームは、Infrastructure as Code を使用して Agent Space を大規模に効率的に管理できます。

推奨アプローチ：出発点として、AWS CDK または Terraform のサンプルを使用します。これらのサンプルにより、チームは以下が可能になります。

組織で必要な IAM ロール、統合、リソース境界を含む標準化された Agent Space テンプレートを定義できます。
アプリケーションオンボーディングワークフローの一部として Agent Space をプログラムでデプロイできます。
AWS Config ルールやサービスコントロールポリシーを通じてコンプライアンスを強制できます。
統合された請求とタグ付け（application-id、team、cost-center、environment）を通じてすべての Agent Space を追跡できます。

中央運用チームがテンプレートとガバナンスポリシーを管理し、アプリケーションチームはそのガードレール内で運用します。このアプローチは、一貫した設定と自動デプロイにより、数千のアプリケーションにスケールします。AWS DevOps Agent は、AWS アカウント内のエージェントアクセスの制限と、チームが大規模に Agent Space アクセスを管理するためのオペレーターコンソールへのアクセス制御を可能にします。

Figure 3: Enterprise scale pattern using Infrastructure as Code

図3: Infrastructure as Code を使用したエンタープライズスケールパターン

Agent Space の境界をチーム構造とスケール要件に合わせて設計する方法を理解したところで、これらのアーキテクチャパターンを実現するための実践的な実装手順を見ていきましょう。

パート2: Agent Space アーキテクチャの実装

このセクションでは、最初の Agent Space を作成するための実践的な手順を説明します。前提条件の確認、アカウント間の IAM ロール設定、オブザーバビリティツールの統合、アクセス制御の設定、そして調査に必要なコンテキストが確保されていることを確認するためのテストまでを網羅します。

ステップ1: Agent Space の前提条件

最初の Agent Space をセットアップする前に、以下を確認してください。

AWS アカウント: アプリケーションリソースが稼働する AWS アカウントが少なくとも1つ必要です。
IAM 権限: アカウント間で IAM ロールとポリシーを作成するための十分なアクセス権。AWS DevOps Agent には2つの異なる IAM 権限セットが必要です。
- Agent Space ロール権限: AWS DevOps Agent が AWS リソースのクエリ、CloudWatch Logs へのアクセス、トポロジーの検出のために引き受ける IAM ロール。このロールには AIOpsAssistantPolicy マネージドポリシーに加え、AWS Support と拡張機能のための追加権限が必要です。完全なロール設定については CLI オンボーディングガイドを参照してください。
- オペレーターアプリロール権限: 人間のオペレーターが AWS DevOps Agent Web アプリケーションで実行できる操作（調査の開始、結果の表示、AWS Support ケースの作成など）を制御する IAM ロール。このロールはエージェントの調査権限とは別です。
サービスコントロールポリシー (SCP): 組織の SCP が AWS DevOps Agent の API アクションを許可していることを確認してください。よくあるトラブルとして、チームが Agent Space のセットアップを完了しても、SCP が aidevops:* アクションや bedrock:InvokeModel アクションをブロックしているために調査が失敗するケースがあります。AWS Organization の SCP を確認し、必要に応じて DevOps Agent の例外を追加してください。なお、DevOps Agent と Amazon Bedrock の推論は、お客様のコンテンツを特定の AWS リージョンに制限するポリシーの影響を受けません。Bedrock は米国東部（バージニア北部）以外の米国リージョンをステートレス推論に使用する場合があります。
オブザーバビリティツール: 最低限、Amazon CloudWatch (IAM ロールが適切に設定されていれば自動的に利用可能) と Amazon CloudTrail を利用します。包括的な調査のためには、Datadog、Dynatrace、New Relic、Grafana、Splunk などのアプリケーションパフォーマンスモニタリングツールを統合してください。サポートされている統合についてはテレメトリソースの接続を参照してください。
サードパーティ統合設定の理解: 一部のサードパーティツールには2段階の設定プロセスが必要です。
- アカウントレベルの登録: OAuth を使用するツール（GitHub、Dynatrace など）は、まず DevOps Agent コンソールを通じて AWS アカウントレベルで登録する必要があります。これにより、アカウント内のすべての Agent Space で共有される OAuth 認証情報が確立されます。
- Agent Space レベルの関連付け: 登録後、各 Agent Space はそのツールから使用するリソースを個別に指定します。例えば、GitHub を一度登録した後、Agent Space「EcommerceProd」には本番リポジトリのみを関連付ける一方、Agent Space「EcommerceNonProd」には開発リポジトリを関連付ける、ということが可能です。Datadog、New Relic、Splunk などの他のツールは、API キーやトークンを使用して、別途アカウントレベルの登録なしに Agent Space に直接関連付けることができます。CloudWatch は IAM ロール以外の追加設定は不要です。
ソースコントロール: コードコンテキストとデプロイの相関分析のための GitHub または GitLab リポジトリアクセスを推奨します (オプションだが強く推奨)。
IaC ツール: Agent Space デプロイ用の AWS CDK（TypeScript/Python）、Terraform、AWS CLI、または AWS マネジメントコンソール。

前提条件の確認が完了したら、Agent Space を作成し、調査を可能にする IAM 信頼関係を確立する準備が整います。

ステップ2: Agent Space の作成

AWS DevOps Agent は、Agent Space の境界内にある各 AWS アカウントに IAM ロールを必要とします。エージェントはこれらのロールを引き受けて、CloudWatch Logs のクエリ、リソース情報の取得、アプリケーショントポロジーの構築を行います。

AWS DevOps Agent は、設定された Agent Space 内でアクセスを許可したすべての AWS アカウントの複数の AWS リージョンから運用データを取得するように設計されており、地理的なデプロイ場所に関係なく、分散インフラストラクチャとアプリケーションへの包括的な可視性を実現します。複数アカウントのサポートは、セカンダリアカウントで適切な信頼ポリシーと権限を持つ IAM ロールを作成する設定プロセスを通じて行われます。

オプション A: AWS コンソールウィザードを使用する

AWS DevOps Agent コンソールに移動し、「Agent Space の作成」を選択して、ガイド付きセットアップに従い、各ターゲットアカウントに IAM ロールを作成します。

Figure 4: Creating an Agent Space in the Console

図4: コンソールでの Agent Space の作成

セットアップウィザードは、クロスアカウント信頼関係の設定を支援します。

Figure 5: Multiple account configuration for your Agent Space

図5: Agent Space の複数アカウント設定

オプション B: Infrastructure as Code を使用する（推奨）

Agent Space の作成と複数アカウントへの IAM ロールのデプロイを自動化する CDK および Terraform のサンプルテンプレートを提供しています。

AWS CDK の例（TypeScript）：

// 多数のアカウントがある場合はループを使用：

const accounts = [
  { id: '111111111111', name: 'Prod', role: prodRole, stage: 'prod' },
  { id: '222222222222', name: 'Dev', role: devRole, stage: 'dev' },
  { id: '333333333333', name: 'Test', role: testRole, stage: 'test' },
];

accounts.forEach(account => {
  const association = new devopsagent.CfnAssociation(this, `${account.name}Association`, {
    agentSpaceId: agentSpace.ref,
    serviceId: 'aws',
    configuration: {
      aws: {
        assumableRoleArn: account.role.roleArn,
        accountId: account.id,
        accountType: 'monitor'
      }
    }
  });

  association.addDependency(agentSpace);
  cdk.Tags.of(association).add('stage', account.stage);
});

アカウント間の IAM ロールと権限の設定に関する詳細な手順については、CLI オンボーディングガイドを参照してください。

Agent Space が作成され、AWS アカウントへのアクセスが確保されたら、次の重要なステップはAWS ネイティブサービス以外の調査コンテキストを提供するオブザーバビリティツールと開発ツールとの接続です。

ステップ3：統合の設定

AWS DevOps Agent は、複数のソースからのデータを相関分析してインシデントを調査します。利用可能なコンテキストが多いほど、根本原因分析の精度が向上します。

推奨される統合 (優先度順)

Amazon CloudWatch: AWS サービスからのログ、メトリクス、トレースを提供します。エージェントは調査中に CloudWatch Logs Insights を自動的にクエリします。IAM ロールが適切に設定されていれば、追加の設定は不要です。
オブザーバビリティツール: Datadog、Dynatrace、New Relic、Splunk は、分散トレーシング、ログ、メトリクス、アプリケーションレベルのコンテキストを提供します。AWS コンソールの Agent Space 統合から設定します。
コードリポジトリ: GitHub または GitLab の統合により、エージェントは最近のデプロイとコード変更をレビューできます。OAuth またはパーソナルアクセストークンが必要です。
CI/CD パイプライン: GitHub Actions または GitLab ワークフローにより、エージェントはインシデントとデプロイのタイミングを相関分析できます。コードリポジトリ統合と併せて設定します。
コミュニケーションチャネル: Slack と ServiceNow の統合により、DevOps Agent はチームチャネルにリアルタイムの調査アップデートを投稿し、調査ライフサイクル全体を通じて、調査結果、根本原因分析、推奨される緩和策でインシデントチケットを自動的に更新できます。

高度な統合

組み込みの統合に加えて、AWS DevOps Agent は Webhook トリガーによる調査とカスタム MCP (Model Context Protocol) サーバーをサポートしており、独自のオブザーバビリティツールを持ち込むことができます。

調査トリガーのための Webhook 設定
Webhook により、外部システム (Grafana、Prometheus、PagerDuty、カスタムモニタリングツール) がインシデント発生時に DevOps Agent の調査を自動的にトリガーできます。各 Agent Space は、インシデントを記述する JSON ペイロードを受け付ける一意の Webhook URL を受け取ります。

よくある設定の落とし穴:

Webhook 認証: Webhook はセキュリティのために HMAC 署名を使用します。Webhook シークレットは AWS Secrets Manager に保存し、セキュリティポリシーに従ってローテーションしてください。
ペイロード形式: モニタリングツールがタイムスタンプ、影響を受けるリソース、症状の説明を含むインシデントコンテキストを送信するようにしてください。より豊富なコンテキストにより、より正確な調査が可能になります。

Webhook の詳細なセットアップについては、Webhook を通じた DevOps Agent の呼び出しを参照してください。

独自の MCP サーバーの持ち込み
組み込みの統合以外のオブザーバビリティツール (Grafana、Prometheus、カスタムテレメトリシステム) を使用している場合、MCP サーバーを介して接続できます。MCP サーバーは、DevOps Agent が調査中にクエリする標準化されたプロトコルを通じてツールのデータを公開します。

MCP サーバーの主な要件:

パブリックにアクセス可能な HTTPS エンドポイント: MCP サーバーはパブリックインターネットから到達可能である必要があります。VPC でホストされたサーバーは現在サポートされていません。
読み取り専用ツールのみ: セキュリティのため、読み取り操作を実行する MCP ツールのみを公開してください。書き込み操作はプロンプトインジェクションのリスクをもたらします。
ツールの許可リスト: MCP サーバーをアカウントレベルで登録し、Agent Space ごとに特定のツールを選択的に有効にします。すべてのツールへのアクセスを付与せず、調査に関連するもののみを選択してください。

よくある MCP セットアップエラー:

認証の設定ミス: MCP サーバーは OAuth 2.0 または API キー認証をサポートしています。OAuth クライアント認証情報が正しいこと、およびトークン交換 URL が AWS インフラストラクチャからアクセス可能であることを確認してください。
ツール名の長さ: MCP ツール名の最大長は64文字です。それより長い名前は登録に失敗します。
エンドポイント URL の形式: パスを含む完全な HTTPS URL を使用してください。例：https://mcp.example.com/v1/mcp（mcp.example.com だけではありません）。

認証設定を含む包括的な MCP サーバーセットアップについては、MCP サーバーの接続を参照してください。

統合のテスト:

Webhook または MCP サーバーを設定した後、テスト調査をトリガーして接続性を確認します。
Webhook の場合: モニタリングツールからテストペイロードを送信し、DevOps Agent Web アプリで調査が開始されることを確認します。
MCP サーバーの場合: 手動で調査を開始し、エージェントジャーナル (調査記録)を確認して MCP ツールが正常に呼び出されたことを確認します。
AWS CloudTrail ログでエラーを確認します。CloudTrail は統合の試行を含むすべての DevOps Agent API コールをキャプチャします。

データソースが接続されたら、セキュリティ境界を維持しながら、適切な人が調査に適切にアクセスできるようにする必要があります。

ステップ4: アクセス制御の設定

Agent Space は、認可されたチームメンバーのみが調査に関与できるよう、きめ細かなアクセス制御をサポートしています。

アクセス制御の検討事項:

誰が調査を閲覧すべきか？ 通常はオンコールエンジニア、SRE、DevOps エンジニアです。セキュリティ関連のインシデントにはセキュリティチームの参加も検討してください。
誰が AWS Support ケースを作成すべきか？ 通常はオンコールリードとシニアエンジニアです。過度なケース作成を防ぐため、この権限は制限してください。
誰が Agent Space の設定を変更すべきか？ 通常は中央運用チームまたはインフラストラクチャチームです。日常の調査アクセスとは分離してください。

IAM ベースのアクセス制御:
AWS DevOps Agent は、Agent Space へのアクセスを制御するために IAM ポリシーを使用します。IAM ユーザー、グループ、またはロールにポリシーをアタッチします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "devopsagent:GetAgentSpace",
        "devopsagent:StartInvestigation",
        "devopsagent:GetInvestigation",
        "devopsagent:ListInvestigations"
      ],
      "Resource": "arn:aws:devopsagent:us-east-1:123456789012:agentspace/EcommerceProd"
    }
  ]
}

AWS DevOps Agent は、複数のアカウントにまたがる運用データへの特権アクセスを持つ AWS 環境内で動作します。一般的なセキュリティの基盤は適用されますが、Agent Space の設定には固有の考慮事項があります。包括的なセキュリティガイダンスについては、AWS DevOps Agent セキュリティのドキュメントを参照してください。

アクセス制御が整ったら、Agent Space の設定が必要な調査カバレッジを提供していることを検証する時です。

ステップ5: テストと反復

Agent Space の設定は後から変更可能です。焦点を絞ったスコープから始め、調査結果に基づいて拡大します。

Agent Space のテスト

AWS DevOps Agent Web アプリを使用してテスト調査をトリガーします。

調査を開始し、「/api/checkout エンドポイントの高レイテンシー」などの症状を提供します。
エージェントがどのリソースにクエリするかを観察します。
調査の完全性をレビューします。エージェントは根本原因を特定できましたか？
調査から欠落しているアカウントやサービスはありませんでしたか？
エージェントは十分なテレメトリデータを持っていましたか？

結果に基づいて Agent Space の境界を調整します。

調査にコンテキストが不足している場合はアカウントを追加します。
テレメトリのギャップがある場合は統合を追加します。
パフォーマンスが低下する場合はスコープを縮小します。

まとめ

AWS DevOps Agent は、インシデント対応を手動で時間のかかるプロセスから、自律的でデータ駆動型の調査へと変革します。ただし、エージェントの効果は適切な Agent Space の設定に依存します。オンコールベースのアプローチ（本番環境と非本番環境を分離しつつ、アプリケーションに関連するアカウントへのアクセスを付与する）に従うことで、不必要な複雑さを導入することなく、正確な根本原因分析のための十分なコンテキストを提供できます。

主なポイント

オンコールの境界で考える: Agent Space のスコープは、チームがインシデントを調査する方法を反映すべきです。
Infrastructure as Code を使用する: CDK と Terraform のテンプレートにより、一貫性のある再現可能なデプロイを実現できます。
オブザーバビリティツールを統合する: データソースが多いほど、調査の精度が向上します。
結果に基づいて反復する: 調査パターンの出現に応じて Agent Space のスコープを拡大・縮小してください。

次のステップ

最初の Agent Space を作成しましょう。

AWS DevOps Agent の導入をより容易にし、お客様の問題解決の精度を向上させることに取り組んでいます。Agent Space のセットアップは、迅速で信頼性の高いインシデント解決を実現するための基盤です。ご質問やフィードバックがあれば、以下にコメントをお寄せください。

著者

本記事は、Best Practices for Deploying AWS DevOps Agent in Production を翻訳したものです。翻訳は Technical Account Manager の日平が担当しました。

Amazon Web Services ブログ