![[アップデート] Amazon CloudWatch の運用調査機能が一般提供を開始したため、概要をまとめてみた](https://images.ctfassets.net/ct0aopd36mqt/6mDy5OHyuWO0BYkCTdEVsb/fb81a40db3365780c00e8d5c8927d5c0/eyecatch_awssummitjapan2025_nomal_1200x630.jpg)
[アップデート] Amazon CloudWatch の運用調査機能が一般提供を開始したため、概要をまとめてみた
2025.06.30こんにちは！クラウド事業本部コンサルティング部のたかくに（@takakuni_）です。
先日、Amazon CloudWatch の運用調査機能が一般提供を開始しました。
もともと Amazon Q Developer の運用調査と呼ばれていた機能が名前を変えて一般提供されました。
今回はこの機能の概要をまとめてみたいと思います。
運用調査機能
CloudWatch の運用調査機能は、システムのテレメトリデータ（メトリクス、ログ、デプロイメントイベントなど）を自動的にスキャンし、生成 AI を利用して問題に関連する可能性のある情報や根本原因の仮説を迅速に提示する機能です。
この機能がないケースだと、自身でリソースの設定値やメトリクスから、あたりをつける必要がありましたが、初動を補助するツールとして非常に便利そうな印象です。
利用方法
利用方法にいくつかパターンがあります。
とくに「CloudWatch アラームのトリガーアクションとして実行するパターン」は、インシデント発生時の調査に役立ちそうなイメージがつきますね。
ネイティブに統合されているパターン
コンソールから接続するパターン
CloudWatch アラームのトリガーアクションとして実行するパターン
サポートしているサービス
以下の AWS サービスの調査にサポートしています。
- Amazon EC2
- Amazon ECS on Amazon EC2
- Amazon ECS on Fargate
- Amazon EKS
- Amazon DynamoDB
- Amazon S3
- Amazon EBS
- Lambda
- Amazon Kinesis Data Streams
- Amazon Data Firehose
- Amazon API Gateway
- Amazon SQS
- Amazon SNS
一般提供に際して、リソース数の変化はなかったものの、リソース数の拡充が見込まれていますね。
The list of services will continue to be expanded over time.
追加のコンテキスト
本機能を最大限利用するために、ベストプラクティスガイドが提供されています。その中で以下の機能を有効にすることで、追加のコンテキストとして情報収集するようです。
- CloudWatch agent（v1.300049.1 以上に上げること）
- Amazon EC2, Amazon EBS を利用している場合
- AWS CloudTrail
- CloudWatch Application Signals
- X-Ray
- Container insights
- Amazon ECS on Amazon EC2, Amazon ECS on Fargate, Amazon EKS を利用している場合
他システムとの統合
運用調査機能は AWS Chatbot と SSM Automation と統合しています。（個人的に Chatbot で Slack や Teams へ通知できるのはとてもありがたいですね。）
データの取り扱い周り
調査データの保管
まず初めに、運用調査機能は調査 と呼ばれる単位で調査結果がまとめられ、7 から 90 日の間で保持し続けられます。デフォルトで AWS が所有するマネージドキーで暗号化されますが、必要に応じて CMK を利用した暗号化も可能です。
推論時のデータの扱い
運用調査機能はクロスリージョン推論を利用して、LLM の推論を行っています。
たとえば、東京リージョンの運用調査機能はバージニア北部、オハイオ、オレゴンのどれかのリージョンの LLM を利用して、推論を行います。
調査データはプライマリリージョンにのみ保存されますが、推論の関係から、一時的にリージョン外に移動される可能性があります。（すべてのデータは Amazon の安全なネットワークを介して暗号化されて送信されます。）
また、AI サービスのオプトアウトポリシーを利用することで、サービス品質の向上や開発のためにデータを利用しないよう、オプトアウトが可能です。必要に応じて設定しておきましょう。
クロスアカウント調査
この機能の興味深いポイントとして、クロスアカウントを跨いで最大 25 アカウントまで調査可能であることです。前提条件やセットアップにいくつかステップが必要ですが、クロスアカウントでシステム間連携しているアプリケーションであれば、非常に有用な機能だと思います。
料金
最後に料金です。一般提供後もなんと無償で利用可能です。ただし、ListMetrics や GetDashboard などの CloudWatch API、GetServiceGraph や GetTraceSummaries などの X-Ray API に対しての利用費は一部発生するようです。LLM 自体の利用費が無料なのは非常にありがたいですね。
CloudWatch investigations use a wide range of data sources to determine dependency relationships and plan analysis paths, including telemetry data configurations, service configurations, and observed relationships. These dependency relationships are found more easily if you use CloudWatch Application Signals and AWS X-Ray. When Application Signals and X-Ray aren't available, CloudWatch investigations will attempt to infer dependency relationships through co-occurring telemetry anomalies.
ただし、各アカウントごとに、最大 2 件まで調査を同時に実行可能。毎月最大、 150 件まで調査を作成可能である点は注意しておきましょう。
Each account may have up to 2 concurrent investigations. Only investigations with active analysis count towards this limit. Each month, each account may create up to 150 investigations with AI analysis.
まとめ
以上、「Amazon CloudWatch の運用調査機能が一般提供を開始したため、概要をまとめてみた」でした。
実際に使ってみると内容が分かりやすいかと思いますが、まずは導入に向けて個人的に気になるポイントをまとめてみました。このブログがどなたかの参考になれば幸いです。
クラウド事業本部コンサルティング部のたかくに（@takakuni_）でした！
![[アップデート]Amazon Route 53リゾルバーエンドポイントのキャパシティ使用率メトリクスが追加され、エンドポイントのステータスが取得できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-abb8f6015ca9ca8ce4d38fd37d2ab700/ee9c71478937f038e1364aa400fecf15/amazon-route-53)
