[アップデート]Amazon CloudWatch Application Mapが、インストルメント化されていないサービスの検出をサポートするようになりました

こんにちは。たかやまです。

Amazon CloudWatchのApplication Mapが、インストルメント化されていないサービスの検出をサポートするようになりました。

https://aws.amazon.com/jp/about-aws/whats-new/2025/11/amazon-cloudwatch-application-map-un-instrumented-discovery/

と書きながら私自身、CloudWatch Application Mapはなんだと思っていたのですが、こちらは2025年10月に一般提供開始されたばかりのサービスで、その追加機能となります。

https://aws.amazon.com/jp/about-aws/whats-new/2025/10/application-map-generally-available-amazon-cloudwatch/

それでは、機能を確認していきたいと思います。

CloudWatch Application Mapとは

新機能を確認する前に、ちゃんと触るのが初めてなのでCloudWatch Application Mapの概要を確認しておきたいと思います。

Amazon CloudWatch Application Mapは、Application Signalsを起点に利用できるアプリケーショントポロジーの可視化機能です。

従来はCloudWatch Service Mapとして提供されていましたが、リブランドされてApplication Mapとして提供されています。

旧画面(Service Map)

新画面(Application Map)

旧画面のService Mapとは言うと引き続き「X-Rayトレースマップ」として残っているようです。

The CloudWatch application map replaces the Service Map. To see a map of your application based on AWS X-Ray traces, open the X-Ray Trace Map. Choose Trace Map under the X-Ray section in the left navigation pane of the CloudWatch console.

（翻訳）
CloudWatchApplication Mapは従来のService Mapに置き換わりました。AWS X-Rayトレースに基づいたアプリケーションのマップを表示したい場合は、X-Rayトレースマップを開いてください。CloudWatchコンソールの左側ナビゲーションペインのX-Rayセクション内にある「Trace Map」を選択します。
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceMap.html

主な機能

Application Mapを使用することで、SREチームやDevOpsチームは複雑な分散システムの構造を一目で把握でき、効率的な監視とトラブルシューティングが可能になります。

• トポロジーの可視化: クライアント、カナリア、サービス、依存関係ノード間の接続を表示
• 運用上の健全性監視: SLO達成状況の確認と問題の根本原因特定
• 動的グループ化: 関連サービス、環境、カスタム属性でサービスを整理

これまでは、Application Signalsでインストルメント化されたサービスのみが表示対象でしたが、今回のアップデートでインストルメント化されていないサービスも可視化できるようになりました。

そもそもインストルメント化されていないサービスとは

インストルメント化されていないサービスとは、Application Signalsが設定されておらず、メトリクスやトレースなどのテレメトリデータを積極的に送信していないサービスのことです。

Application Signalsを利用したインストルメント化については以下のブログをご覧ください。

• [アップデート]Amazon CloudWatch Application SignalsがGAしました！CDKでサンプル作ってみた | DevelopersIO
• EKS で CloudWatch Application Signals を有効化してみた | DevelopersIO

従来のApplication Mapでは、Application Signalsでインストルメント化されたサービスのみが表示されていました。そのため、まだApplication Signalsの設定が完了していないサービスは可視化されず、システム全体の把握が困難でした。

今回のアップデートにより、Resource Explorerを活用してアプリケーション名やタグから自動的にサービスを検出し、インストルメント化されていないサービスもApplication Map上に表示されるようになりました。

今回追加された主な機能

インストルメント化されていないサービスの検出をサポートの他、今回のアップデートで追加された主な機能は以下の通りです。

• インストルメント化されていないサービスの検出
  • Resource Explorerを活用した自動検出（最大3,000リソース）
  • インストルメンテーションガイダンスとセットアップドキュメントへのリンク表示
• 変更履歴のサポート
  • 以前の「最後の展開追跡」からCloudTrailイベントからの「変更イベント」への機能拡張
• クロスアカウント間ビュー
  • CloudWatchクロスアカウントオブザーバビリティの機能を利用したクロスアカウント間ビュー

やってみた

まずはインストルメントされているものとされていないものの比較として、インストルメントされていないOne Observability Workshopの環境とインストルメントされているapplication-signals-demoの環境をデプロイしたいと思います。

デモ環境 のデプロイ

One Observability Workshopのデプロイ

今回インストルメント化されていないサービスとして、One Observability Workshopを使用して検証環境を作成します。

以下のコマンドでCloudFormationスタックをデプロイします。

curl -O https://raw.githubusercontent.com/aws-samples/one-observability-demo/main/codepipeline-stack.yaml

aws cloudformation create-stack --stack-name Observability-Workshop \
  --template-body file://codepipeline-stack.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameters ParameterKey=UserRoleArn,ParameterValue=$(aws iam get-role --role-name $(aws sts get-caller-identity --query Arn --output text | awk -F/ '{print $(NF-1)}') --query Role.Arn --output text)

application-signals-demoのデプロイ

次にインストルメント化されているサービスとして、application-signals-demo を使用して検証環境を作成します。

application-signals-demoではEKS/EC2/K8s/ECS/Bedrock AgentCoreのデモが用意されています。

今回はEC2のサンプルアプリケーションをデプロイします。

cd scripts/ec2/appsignals/ && ./setup-ec2-demo.sh --region=ap-northeast-1

Application Mapの確認

新機能確認の前にApllication Mapの表示を軽く確認しておきます。

Application Mapは 「CloudWatch」 > 「Application Map」からアクセスできます。

デプロイが完了する前のApplication Mapの表示です。

One Observability Workshopとapplication-signals-demoのデプロイが完了した後のApplication Mapです。

デフォルトはグループ化条件が「関連サービス」となっていて、Application Map側でサービス間の呼び出し関係に基づいて自動的にグループ化してくれます。

グルーピングされたリソースを選択すると以下のように関連リソースをトポロジーマップで表示してくれます。

そこからさらに個別のサービスを選択することで、Application Signralsのサービスダッシュボードにアクセスすることもできます。

他にAWSサービス群ごとにグルーピングしている「環境」グループも用意されています。

またユーザー側で個別にAWSタグやOpenTelemetryのリソース属性を利用してグループ化することもできます。

インストルメント化されていないサービスの検出

ここからはアップデート後の機能を確認していきます。

一つ目がインストルメント化されていないサービスの検出です。

uninstrumented と書かれている通り、Application Signalsがインストルメント化されていないサービスが表示されていることが確認できますね。

仕組みとしてはResource Explorerを使っているようで、最大3,000個のリソースまで自動検出されるようです。

Un-instrumented services appear on the Application Map even when they haven't been configured with Application Signals. These services are automatically discovered by leveraging Resource Explorer using application names and tags. The system can automatically detect up to 3,000 resources in your AWS account.

（翻訳）
インストルメント化されていないサービスは、Application Signalsが設定されていない場合でも、Application Mapに表示されます。これらのサービスは、アプリケーション名とタグを使用してリソースエクスプローラーを活用することで自動的に検出されます。システムはAWSアカウント内の最大3,000個のリソースを自動的に検出できます。
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceMap.html

テレメトリデータとしても他のインストルメント化されているサービスに比べ、リアルタイム性は劣るので正確に確認する場合にはインストルメント化することをお勧めします。

Un-instrumented services display limited telemetry data since they don't actively send metrics or traces.

（翻訳）
インストルメント化されていないサービスは、メトリクスやトレースを積極的に送信していないため、テレメトリデータが限定されて表示されます。
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceMap.html

インストルメント化されていないサービスを確認することで以下に役立てることができます。

• 監視範囲のギャップを特定する
• アーキテクチャ内の位置に基づいて、次にインストルメントするサービスの優先順位を決定する
• 完全なインストルメンテーションを行う前でも、完全なアプリケーショントポロジを理解する
• 組織全体で計測機器の展開を計画する

変更履歴のサポート

2つ目は変更履歴のサポートです。

変更履歴はサービスの「View more」から確認できます。

変更履歴で表示されるリンクをクリックすると対象リソースの変更で利用されたCloudTrailイベントを確認できます。

正常稼働していたサービスでSLI違反しているものやサーバー障害の傾向が見えた際には直近の変更ログを確認することで原因を特定しやすくなりそうですね。

また、問題箇所のメトリクスから「CloudWatch 自動調査機能」から調査を開始することもできます。

変更イベントは以下のリソースに対して対応しています。

• Autoscaling Group
• EKS Cluster
• EKS Workload (only deployments)
• ECS Cluster and Service
• ELB Load balancer and Target Group
• Lambda Function
• BedrockAgentCore Runtime and RuntimeEndpoint
  参考 : Application Signals - Amazon CloudWatch

クロスアカウントビュー

最後にクロスアカウントビューを確認してみます。

クロスアカウントビューはCloudWatchクロスアカウントオブザーバビリティの機能を利用して行います。

クロスアカウントオブザーバビリティの説明については以下のブログをご覧ください。

https://dev.classmethod.jp/articles/enabled-cloudwatch-cross-account-observability/

ではモニタリングアカウントから以下の設定をします。

ソースアカウントとの連携はURLをコピーしてソースアカウントのCloudWatchクロスアカウントオブザーバビリティの設定で貼り付けることで可能です。

ソースアカウント上でURLを踏むと以下のような画面が表示されるのでリンクします。

モニタリングアカウント側に戻ると以下のようにソースアカウントがリンクされていることがわかります。

Application Mapの画面に戻ると以下のように「モニタリングアカウント」のラベルが確認できます。

ソースアカウントでちょうどよくあったリソースがLambdaだったのでこちらをモニタリングアカウントで確認しようとしましたが、見つかりませんでした。

インストルメント化されていないリソースだったので見つからなかったかもしれませんね...
ひとまず、モニタリングアカウントとして識別されているのでよしとしましょう。

最後に

Amazon CloudWatch Application Mapのインストルメント化されていないサービス検出機能および変更履歴/クロスアカウントビューを試してみました。

インストルメント化されていないサービスもResource Explorerを活用することで、Application Signalsで自動的に検出され、視覚的に区別して表示されます。
これにより、システム全体の可観測性を向上させ、どのサービスがまだインストルメント化されていないかを一目で把握できるようになりました。

また、クロスアカウントビューや変更履歴のサポートも追加されたことで、大規模分散環境における監視とトラブルシューティングが効率化されそうですね。

他にもApplication Map からさまざまな機能にアクセスできるので CloudWatch だけで Observability を実現する場合に活用できそうです。

このブログがどなたかの参考になれば幸いです。

以上、たかやま(@nyan_kotaroo)でした。