AWS DevOps Agent によるネットワークインシデント対応の自動化

本記事は、2026 年 4 月 21 日に Networking & Content Delivery で公開された Automated network incident response with AWS DevOps Agent を翻訳したものです。翻訳は Technical Account Manager の由原が担当しました。
※AWS DevOps Agent が日本語をサポートしていることに伴い、aws-samples GitHub リポジトリのコードを用いた再現検証を行った結果をもとに一部内容を変更しています。

オンコールのエンジニアが深夜 2 時に呼び出しを受けたことを想像してください。
呼び出しの内容は Workload Account 内の決済サービスが、Shared Services Account 内の共有データベースに到達できなくなったというものでした。Amazon CloudWatch アラームは 8 分前に通知されていました。オンコールエンジニアはまず、原因の切り分けのために2 つのアカウントにまたがるルートテーブル、Amazon Virtual Private Cloud (Amazon VPC) のアタッチメントの状態、両側のセキュリティグループルール、ネットワーク ACL、そして DNS における名前解決ログを確認していきます。
確認から1 時間後、根本原因は、その日の夕方に行われたネットワーク移行の際に、AWS Transit Gateway のルートテーブルの関連付けが誤ったルートテーブルに切り替えられていたことだと原因を特定しました。この原因により、他のすべてのスポークは問題なく動作し続けている一方で、2 つの VPC 間のトラフィックだけが気付かれないまま破棄された結果決済サービスと共有データベース間の通信に失敗するようになったというものです。

AWS DevOps Agent を用いることで、調査プロセス全体を自動化することができ、このような問題を解決することが可能になります。DevOps Agent は Webhook を介して CloudWatch アラートを受信することができ、メトリクス、ログ、ネットワークフローデータ、API 変更履歴の相関分析を開始することができます。その後、DevOps Agent は即座に実行可能な修正策とともに根本原因分析を提供し、手動で相関分析に費やしていた 1 時間を、自動化された分析によって数分に短縮することが可能です。

この記事では、CloudWatch モニタリングを DevOps Agent と統合して、ネットワーク障害に対するインシデント対応を自動化する方法を紹介します。

この記事では、一般的な 4 つのシナリオとして、セキュリティグループの設定ミス、NAT Gateway のルーティング問題、VPC エンドポイントポリシーの制限、インターフェイスエンドポイントのサブネット問題を取り上げていきます。ご自身のアカウントにデプロイして手順を実施できる CloudFormation テンプレートを用いて、各シナリオで DevOps Agent がどのように自動的に調査を行い、人による承認を伴う修復プランを生成するかを紹介します。さらに、複数アカウントにまたがる複雑なシナリオとして、Transit Gateway のルートテーブルの設定ミスによりアカウント間の VPC 通信がブロックされるケースを取り上げ、DevOps Agent がエンタープライズ環境にもスケールできることを紹介します。

シミュレートされたワークロードアプリケーションのフルスタックは aws-samples GitHub リポジトリ で入手可能です。

紹介用にシミュレートされたワークロードの概要

DevOps Agent の自動インシデントレスポンス機能を紹介するため、シミュレーションされたワークロードを使用します。このワークロードは、Application Load Balancer (ALB) の背後に Amazon Elastic Compute Cloud (Amazon EC2) 上で動作する Node.js サービスが配置されています。このアプリケーションは、ループでヘルスチェックを実行し、ステータスダッシュボードに結果を表示します。

このアプリケーションは、シンプルさと分かりやすさのため 4 種類のリソースへの接続の確認を行うようになっています。

• Amazon RDS インスタンスへのデータベース接続性 (5 秒ごと)。
• NAT Gateway 経由でのアウトバウンドインターネット到達性 (15 秒ごと)。
• VPC ゲートウェイエンドポイント経由での Amazon Simple Storage Service (Amazon S3) バケットへのアクセス (10 秒ごと)。
• インターフェイス VPC エンドポイント経由での Amazon Bedrock へのアクセス (60 秒ごと)。

チェックが失敗すると、アプリケーションは Amazon CloudWatch カスタムメトリクスを発行し、アラームをトリガーするようになっています。スタック全体は、単一の AWS CloudFormation テンプレートからデプロイすることが可能です。図 1 は、シミュレートされたワークロードのアーキテクチャ図を示しています。

図 1: ALB、プライベートサブネット内の EC2 インスタンス、RDS、S3 ゲートウェイエンドポイント、インターフェイス VPC エンドポイント、NAT ゲートウェイ、およびアラームパイプラインで構成される、シミュレートされたワークロードのアーキテクチャ

シミュレーションされたワークロードと DevOps Agent でできることを理解したところで、環境のセットアップとシナリオの実行手順を見ていきましょう。

AWS CloudFormation を使用したシミュレーションワークロードのデプロイ

GitHub リポジトリから CloudFormation テンプレートをダウンロードし、us-east-1 リージョンで AWS CloudFormation コンソールを開きます。

1. スタックの作成 を選択し、新しいリソースを使用 (標準) を選択。
2. テンプレートファイルのアップロード を選択し、ダウンロードしたファイルをアップロードして 次へ を選択。
3. スタック名を入力し、IAM に関するチェックボックスに同意し、送信 を選択。

CloudFormation のデプロイが完了したら、CloudFormation コンソールの Outputs タブに移動してください。そこで、シミュレーションされたワークロードアプリケーションのステータスページにアクセスするためのリンクを確認できます。ステータスページでは、アプリケーションが正常に動作していることが表示され、緑色の 「Connected」 ボックスによってすべてのチェックが成功していることが確認できます。

図 2: シミュレートされたワークロードアプリケーションのステータスページ

シミュレーションワークロードアプリケーションが実行されたら、AWS DevOps Agent をセットアップします。DevOps Agent Space を作成し、Webhook 統合を設定して、接続性の確認を行います。セットアップが完了したら、設定変更によってアプリケーションの一部に障害が発生する 4 つのネットワーキングシナリオを確認し、DevOps Agent がそれらを自動的に診断する様子を見ていきます。

AWS DevOps Agent のセットアップ

1. DevOps Agent Space を作成。
2. DevOps Agent Webhook を設定。
3. Webhook を作成し CSV ファイルをダウンロードした後、AWS コンソール (us-east-1 リージョン) の AWS Secrets Manager に移動し、シークレット devops-agent-sample-app-webhook-credentials を見つけて、CSV ファイルの Webhook URL とシークレットで 2 つの値を更新。
4. 次に進む前に、Webhook をテストして連携が機能していることを確認。
   1. AWS コンソールで Lambda を開き、関数 devops-agent-sample-app-DevOpsAgent-Webhook を見つけて、Test タブを選択。
   2. TestAlarm という名前の新しいテストイベントを、以下の JSON で作成。

      {
        "Records": [
          {
            "Sns": {
              "Message": "{\"AlarmName\":\"TEST-webhook-verification\",\"AlarmDescription\":\"[[TEST]] This is a webhook integration test - not a real incident. No investigation needed.\",\"NewStateValue\":\"ALARM\",\"NewStateReason\":\"[[TEST]] Manual test to verify webhook connectivity from Lambda to DevOps Agent. Safe to ignore.\",\"Region\":\"us-east-1\"}"
            }
          }
        ]
      }

   3. Save をクリックし、次に Test をクリックします。以下が返されることを確認。

      {
        "statusCode": 200,
        "body": "{\"message\": \"DevOps Agent investigation triggered\", \"alarmName\": \"TEST-webhook-verification\", \"webhookStatus\": 200}"
      }

   4. DevOps Agent Web アプリで、CloudWatch Alarm: TEST-webhook-verification という名前のテスト調査が Incident タブに表示されることを確認。

次の図 3 は、この特定のテスト出力が DevOps Agent Web App でどのように表示されるかを示しています。

図 3: 手動でトリガーされた DevOps エージェントの実行結果。Webhook 連携が機能していることを確認しています

アラームパイプラインの仕組み：障害発生から調査まで

すべての障害は、DevOps Agent まで同じ経路をたどるようにしています。アプリケーションは Amazon CloudWatch にカスタムメトリクスを発行し、CloudWatch アラームはそのメトリクスを評価、ALARM 状態に遷移します。アラームは Amazon SNS トピックに通知されます。Amazon SNS は AWS Lambda 関数を呼び出し、この関数は AWS Secrets Manager から Webhook の認証情報を読み取り、インシデントのペイロードを構築し、HMAC SHA-256 で署名した上で DevOps Agent の Webhook に POST します。DevOps Agent は署名を検証し、調査を開始します。このパイプラインは図 4 に示されています。

図 4: アラームパイプライン

図 5 は、シミュレートされたワークロードアプリケーションを監視するために構成された 4 つの CloudWatch アラームを示しています。

図 5: CloudWatch アラーム

Amazon SNS を Amazon CloudWatch と AWS Lambda の間に配置しているのには、3 つの理由があります。
まず、Lambda がスロットリングされた場合に配信を再試行できること (デッドレターキューのサポートあり)、次に、アラームに手を加えずに追加のサブスクライバー (メール、チャットツール、インシデント管理システム) にファンアウトできること、そして、クロスアカウントでの発行をサポートしているため、複数アカウントからのアラームを単一の運用パイプラインに集約できることです。

シナリオ 1: セキュリティグループルールの削除によりデータベースがダウン

データベースのセキュリティグループ (devops-agent-sample-app-DB-SG) は、アプリケーションのセキュリティグループ (devops-agent-sample-app-App-SG) からの MySQL トラフィック (ポート 3306) のインバウンド通信を許可しています。次の図 6 は、このインバウンドルールが削除される様子を示しています。

図 6: セキュリティグループのインバウンドルールが削除される様子

インバウンドルールを削除すると、アプリケーションは数秒以内にデータベースへの接続を失います。セキュリティグループは、どのルールにも一致しないパケットを何も通知せずに破棄するため、アプリケーションの接続試行には応答がなく、タイムアウトします (ステータスダッシュボードに ETIMEDOUT が表示されます)。他の 3 つのチェック (外部接続、S3、Bedrock) はポート 3306 を使用しないため、緑色のままです。

図 7: シミュレーションされたワークロードのアプリケーションステータスページ

DevOps Agent は DatabaseConnectionFailures アラームを受信し、調査を行います:

1. RDS インスタンスの正常性を確認 – データベースは利用可能だが、接続数がゼロであることを報告していることを確認。
2. CloudTrail ログを検索 – RevokeSecurityGroupIngress API コールを発見し、誰がいつ実行したか (アラームが発生する 1 分 30 秒前) を特定。
3. リソースの関係性をマッピング – トポロジーを使用して、EC2 から RDS への接続依存関係を特定。
4. 根本原因を特定 – データベースセキュリティグループでポート 3306 上のアプリケーションセキュリティグループからのトラフィックを許可していたインバウンドルールが削除されており、データベース自体は正常な状態を維持していたものの、すべての MySQL 接続が即座にブロックされていたことが判明。

図 8 と図 9 に、調査のタイムラインと根本原因のタブを示しています。根本原因を確認した後、問題を解決する方法を確認するための対応計画を生成できます。図 10 は、セキュリティグループを修正するために必要な手順 (AWS CLI コマンド) を記載した対応計画を示しています。

図 8: DevOps Agent の調査タイムライン

図 9: DevOps Agent による根本原因分析

図 10: DevOps Agent から提示された影響緩和策

修正が適用されると、シミュレートされたワークロードアプリケーションのページでは、データベース接続のステータスが緑色の Connected 状態で表示されます。

シナリオ 2: NAT ゲートウェイルートが削除され、アウトバウンドインターネット接続が失われる

プライベートルートテーブル (devops-agent-sample-app-Private-RT) には、VPC 外へのすべてのトラフィックを NAT Gateway に送信するデフォルトルートがあります。次の図 11 は、ルートが削除される様子を示しています。

図 11: プライベートルートテーブルからデフォルトルートを削除

誰かがこのルートを削除した場合、アプリケーションはパブリックインターネットに到達できなくなります。本環境では、データベース、Amazon S3 、 Amazon Bedrock への疎通性は、パブリックインターネットへの接続性に依存しない設計となっているため、赤く表示されるのは外部接続チェックのみです。

図 12: シミュレートされたワークロードアプリケーションのステータスページ

DevOps Agent は ExternalConnectivityFailures アラームを受信し、調査を行います:

1. プライベートルートテーブルを確認 – NAT Gateway を指すデフォルトルート (0.0.0.0/0) が欠落していることを特定。
2. NAT Gateway の正常性を確認 – NAT Gateway 自体が正常であり、キャパシティの問題やエラーがないことを検証。
3. CloudTrail ログを検索 – DeleteRoute API コールを見つけ、誰がいつ実行したかを特定。
4. リソース関係のマッピング – トポロジーを使用して、EC2 から NAT Gateway への依存関係を特定。
5. 根本原因を特定 – プライベートルートテーブルからデフォルトルートが削除されており、EC2 インスタンスがインターネット宛てのトラフィックのルーティングパスを持たない状態になっている。

図 13 と図 14 に、調査のタイムラインと根本原因のタブを示します。根本原因を確認した後、対応策を生成して問題の解決方法を確認できます。図 15 は、NAT ゲートウェイルートを復元するために必要な手順（ AWS CLI コマンド）を詳細に示した対応策です。

図 13: DevOps Agent による調査のタイムライン

図 14: DevOps Agent の根本原因

図 15: DevOps Agent による移行計画

修正が適用されると、シミュレートされたワークロードアプリケーションのページでは、外部接続のステータスが緑色の Reachable 状態で表示されます。

シナリオ 3: VPC エンドポイントポリシーによる S3 バケットアクセスの制限

S3 VPC ゲートウェイエンドポイント (devops-agent-sample-app-S3-Endpoint) には、5 つすべてのアプリケーションバケットへのアクセスを許可するポリシーが設定されています。次の図 16 は、VPC エンドポイントポリシーの変更内容を示しています。

図 16: VPC エンドポイントポリシーの変更

誰かがこのポリシーを編集して 5 つのバケットのうち 3 つだけを許可するように変更すると、他の 2 つは AccessDenied を返し始めます。これは多くの人を最も混乱させるシナリオです。なぜなら、AWS Identity and Access Management (IAM) ポリシーは依然として 5 つすべてへのアクセスを許可しているからです。Gateway Endpoint を経由する Amazon S3 トラフィックでは、3 つのポリシー層すべてで許可されている必要があります。3 つのポリシー層とは IAM、バケットポリシー、そしてエンドポイントポリシーです。これらのいずれかの層がリクエストを拒否すると、Access Denied (HTTP 403 Forbidden) エラーが返されます。

それ以外のすべての項目は引き続き動作します:

• データベースが機能します (VPC ローカルルートで接続可能)。
• Amazon Bedrock が機能します (インターフェイスエンドポイントが ENI をサブネット内に直接配置)。
• インターネットへのアウトバウンド接続が機能します (NAT ゲートウェイのルートが維持されている)。

S3 バケットのアクセスチェックのみが赤くなります。

図 17: シミュレートされたワークロードアプリケーションのステータスページ

DevOps Agent は S3AccessFailures アラームを受信し、調査を行います。

1. ポリシーレイヤーを比較 – エンドポイントポリシーを、IAM アクセス許可およびアプリがアクセスしようとしているバケットと照合して検査を実行。
2. ブロックしているレイヤーを特定 – エンドポイントポリシーがアクセスを制限していると判断。
3. CloudTrail ログを検索 – ModifyVpcEndpoint API 呼び出しを見つけ、ポリシーを変更した人物と時刻を特定。
4. リソースの関係をマッピング – トポロジを使用して、EC2 と S3 ゲートウェイエンドポイント間の依存関係を特定。
5. 根本原因を特定 – VPC エンドポイントポリシーが、アプリケーションの 5 つのバケットのうち 3 つのみへのアクセスを許可するように変更されており、残り 2 つのバケットへのアクセスがブロックされていたことを特定。

図 18 と図 19 には、調査タイムラインと根本原因のタブが表示されています。根本原因を確認した後、問題を解決する方法を確認するための修復プランを生成できます。図 20 には、5 つの S3 バケットすべてへのアクセスを復元するために必要な手順 (AWS CLI コマンド) を詳述した修復プランが示されています。

図 18: DevOps Agent の調査タイムライン

図 19: DevOps Agent が特定した根本原因

図 20: DevOps Agent の移行計画

修正が適用されると、シミュレーションされたワークロードアプリケーションページには、S3 Bucket Access のステータスが緑色の All Accessible 状態として表示されます。

シナリオ 4: Bedrock インターフェイスエンドポイントからサブネットを削除し、AI 機能が動作しなくなる

Bedrock Runtime インターフェイスエンドポイント (devops-agent-sample-app-Bedrock-Endpoint) は、2 つのプライベートサブネットに ENI を作成しています。プライベート DNS は、bedrock-runtime.us-east-1.amazonaws.com でそれらの ENI の IP アドレスを解決します。次の図 21 は、サブネット関連付けの削除を示しています。

図 21: インターフェイス VPC エンドポイントに関連付けられたサブネットの変更

2 つのサブネットの関連付けを両方とも削除すると、ENI は削除されます。エンドポイント自体は引き続き存在し、プライベート DNS もホスト名をエンドポイントに解決し続けますが、トラフィックを処理するものが何もなくなります。このシナリオは手動で発見するのが特に難しいもので、リクエストが応答なしでタイムアウトしているにもかかわらず、コンソール上ではエンドポイントが「利用可能 (Available)」と表示されたままになるからです。
ここで 2 種類のエンドポイントタイプの違いについて触れておきます。VPC ゲートウェイエンドポイント (Amazon S3、Amazon DynamoDB) はルートテーブルのエントリとエンドポイントポリシーを介して動作するため、そこで設定ミスがあると「Access Denied (HTTP 403 Forbidden)」エラーを返します。インターフェイス VPC エンドポイント (Amazon Bedrock やその他多くの AWS サービス) は、サブネット内にある、独自のセキュリティグループを持つ ENI を介して動作するため、それらの ENI が削除されると、代わりに接続タイムアウトが発生します。しかし、データベースは引き続き動作し (VPC ローカルルート)、Amazon S3 も引き続き動作し (VPC ゲートウェイエンドポイントには独自のルートテーブルエントリがある)、アウトバウンドのインターネット接続も引き続き動作します (NAT ゲートウェイのルートは維持されている)。赤く表示されるのは、Bedrock AI のチェックだけです。

図 22: シミュレートされたワークロードのアプリケーションステータスページ

DevOps Agent は BedrockAccessFailures アラームを受信し、調査を開始します：

1. エンドポイント設定を確認 – インターフェイス VPC エンドポイントにサブネットの関連付けがゼロであることを検出。
2. CloudTrail ログを検索 – ModifyVpcEndpoint API コールを検出し、誰がいつサブネットの関連付けを削除したかを特定。
3. リソースの関係をマッピング – トポロジーを使用して、EC2 から Bedrock インターフェイス VPC エンドポイントへの依存関係を特定。
4. 根本原因を特定 – Bedrock Runtime インターフェイス VPC エンドポイントから両方のサブネット関連付けが削除されたため、トラフィックを処理する ENI が削除された一方で、エンドポイント自体は「Available」状態のまま。

図 23 と図 24 は調査タイムラインと根本原因のタブを表示しています。根本原因を確認した後、問題を解決する方法を確認するために緩和策を生成できます。図 25 は、Bedrock Runtime Interface VPC Endpoint を復元するために必要な手順 (AWS CLI コマンド) を詳述した緩和策を示しています。

図 23: DevOps Agent の調査タイムライン

図 24: DevOps Agent が特定した根本原因

図 25: DevOps Agent の移行計画

修正が適用されると、シミュレートされたワークロードアプリケーションのページで、Bedrock AI のステータスが緑色の Connected 状態として表示されます。

応用編: 複雑なネットワークシナリオ

本投稿の 4 つのシナリオではネットワーキングの基礎的な概念を扱っていますが、実際の本番環境はより複雑です。冒頭のシナリオを思い出してください。ネットワーク移行中に AWS Transit Gateway のルートテーブルの関連付けが誤ったテーブルに切り替えられたことで、Workload Account の決済サービスが Shared Services Account の共有データベースに到達できなくなり、2 つの VPC 間のすべてのトラフィックが遮断されました。以下の図はその構成を示しています。

図 26: DevOps Agent マルチアカウント構成図

マルチアカウントアクセスを設定すると、DevOps Agent は複数のリージョンとアカウントにまたがる運用データを取得でき、前述の 4 つのシンプルなケースと同じ方法で問題を調査できます。両方のアカウントにまたがる Transit Gateway のトポロジーをマッピングし、関連付けと伝播状態についてルートテーブルをチェックし、どの関連付けが誤ったテーブルを指しているかを特定します。対処プランでは、どのアタッチメントで、どのルートテーブルを再関連付けすべきかを正確に示します。

図 27 は、両アカウントにおける Transit Gateway ルートテーブルの関連付けが誤っていることを特定した根本原因分析を示しています。図 28 は、アタッチメントに正しいルートテーブルを再関連付けするために必要な手順 (AWS CLI コマンド) を詳述した修正計画を示しています。

図 27: DevOps Agent が特定した根本原因

図 28: DevOps Agent の移行プラン

その他の考慮事項

本番環境では、1 つのインフラストラクチャ変更で複数のアラームが同時に発報することがあります。例えば、NAT Gateway のルートを削除すると、それらのサービスもアウトバウンドアクセスに依存している場合、外部接続、Amazon S3、Amazon Bedrock のアラームが同時にトリガーされる可能性があります。AWS Lambda 関数に相関ロジックを追加する (例えば、Amazon DynamoDB に 60 秒のウィンドウでアラームをバッファリングし、アプリケーション単位でグループ化する) ことで、重複した調査が積み重なることを防げます。

この構成における Amazon SNS トピックにはサブスクライバーが 1 つ (Webhook Lambda 関数) ありますが、アラーム定義を変更することなく、メール、Amazon SQS、または HTTP サブスクライバーを追加できます。既に CloudWatch アラームと SNS トピックを使用して監視やアラートを運用している場合、Webhook Lambda をそのトピックの追加サブスクライバーとして登録することで、既存のツールを妨げることなく DevOps Agent で状況を把握できるようになります。マルチアカウント環境では、他のアカウントにある Amazon CloudWatch アラームから集約用の Amazon SNS トピックに直接パブリッシュすることで、DevOps Agent への単一のパイプラインを構築できます。

ここで改めて強調しておきたいのは、DevOps Agent は緩和計画の案を作成しますが、AWS 環境に対して自動的に変更を加えることはありません。修復手順の実行には、引き続き人間による操作が必要です。

セットアップ時に接続したサードパーティツールおよびデータソースは、調査時にも適用されます:

• テレメトリソースを接続すると、DevOps Agent は根本原因分析の一環としてメトリクスやトレースを取得可能に。
• CI/CD パイプラインを接続すると、最近のデプロイメントと障害発生のタイムラインを関連付けることが可能に。
• MCP サーバーを設定することで、内部 API、ランブックデータベース、または任意のカスタムデータソースを Model Context Protocol 経由で利用可能に。DevOps Agent は、調査中にそのデータが関連する場合にこれらのツールを呼び出します。

クリーンアップ

すべてのリソースを削除するには、スタックの削除に従ってください。
スタックを削除すると、VPC、サブネット、ルートテーブル、セキュリティグループ、エンドポイント、EC2 インスタンス、RDS、ALB、SNS トピック、Lambda 関数、IAM ロールを含むすべてのリソースが削除されます。

まとめ

本投稿では、AWS DevOps Agent が障害を自動的に調査し、修復計画を生成する 4 つのネットワーキングシナリオをご紹介しました。
これにより、手動でのログ相関作業に何時間もかけることなく、数分以内に明確で実行可能な根本原因分析とすぐに実行できる修正策をチームに提供できます。各シナリオでは異なるトラブルシューティングパターンを示しているため、同じアプローチを皆様の環境にも適用できます。

DevOps Agent が VPC Flow Logs と CloudTrail の API 変更を関連付けて削除されたセキュリティグループルールを見つけ、ルートテーブル設定をマッピングして不足している NAT Gateway ルートを特定し、複数層のポリシーを比較して S3 Gateway Endpoint の制限を切り分け、エンドポイントの利用可否の状態を識別して Interface Endpoint のサブネット削除を検出する様子をご覧いただきました。これらの基本的なシナリオにとどまらず、DevOps Agent はマルチアカウントアクセス、サードパーティのオブザーバビリティ統合、カスタム MCP サーバーを備えた複雑な環境にも対応できます。

AWS DevOps Agent の開始方法 ガイドに従って、今すぐインシデント対応の自動化を始めましょう。

著者について