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

Amazon CloudWatchがEC2インスタンスへのCloudWatchエージェントの自動インストールと設定を行うコンソール内機能を提供開始しました！

今まではSSM Run CommandやState Managerを使ってエージェントのインストールや設定更新を個別に行う必要がありましたが、この機能によりCloudWatchコンソール上からまとめてインストールと設定を行うことができるようになりました。

https://aws.amazon.com/jp/about-aws/whats-new/2025/11/cloudwatch-in-console-agent-management-ec2/

ドキュメントはこちらです。

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-cloudwatch-agent-workload-detection.html

では実際にやってみたいと思います。

さきにまとめ

• CloudWatchコンソールからCloudWatchエージェントのインストールと設定を一元的に行えるようになった
• インストール方法は手動とタグベースの2種類
  • 手動の場合は最大50台までまとめてインストールすることができる
  • タグベースの場合は現在のインスタンスおよび将来的に起動されるインスタンスにも自動設定が適用可能
• ワークロード検出を有効にすることで、手動インストール時にEC2のワークロードから推奨の設定を自動で選択してくれる(サポートされているワークロードは以下のとおり)
  • EC2 (Linux)
  • JVM
  • Kafka Broker
  • Kafka Producer
  • Kafka Consumer
  • NVIDIA GPU
  • Tomcat

やってみる

ドキュメントを確認すると新たに以下のページが追加されています。

• Install and Configure Amazon CloudWatch Agent with Workload Detection in the CloudWatch console - Amazon CloudWatch

前提条件として SSMエージェントのインストールが必須となります。

コンソールを確認すると新たに「ワークロード検出を有効にする」が追加されていることが確認できます。

デフォルトではワークロード検出は無効になっています。

「エージェントの管理」をのぞいてみると現在のインスタンスのエージェント状態が確認できます。

EC2が起動している必要はありますが、コンソール上でSSMエージェントとCloudWatchエージェントの有効化状態が一覧で確認できます。

手動インストール

「エージェントをインストールおよび設定」をクリックするとSSMエージェントがインストールされているインスタンスを対象にCloudWatchエージェントのインストールをすることができます。

最大50台までまとめてインストールすることができます。

インスタンスを選択した際に、指定したインスタンスにCloudWatchエージェントインストールに必要なインスタンスプロファイルがない場合に以下のメッセージが出てきます。

1 selected instance(s) lack an IAM instance profile. If Default Host Management Configuration (DHMC) is enabled, this can cause a 30-minute delay for the CloudWatch Agent IAM role to be recognized by SSM Agent. To avoid this, attach an instance profile , launch new instances with an instance profile, or disable DHMC.

翻訳 : 1つの選択されたインスタンスにIAMインスタンスプロファイルがない。デフォルトのホスト管理設定(DHMC)が有効な場合、CloudWatchエージェントのIAMロールがSSMエージェントに認識されるまで30分遅れる可能性があります。これを避けるには、インスタンスプロファイルを添付する、新しいインスタンスをインスタンスプロファイルで起動する、またはDHMCを無効にしてください。

要するに、CloudWatch Agent設定のために必要なインスタンスプロファイルがない場合、DHMCが有効であればよしなに設定してくれますが、その場合は設定反映まで30分遅れる可能性があるとのことです。

まとめて複数台のインスタンスをインストールする場合はDHMCに任せると楽そうですが、今回は時間短縮のために手動でAmazonSSMManagedInstanceCoreポリシーを付与したインスタンスプロファイルを付与しておきます。

「エージェントをインストール」を選択すると以下のような設定が出ます。

CloudWatch Agentsを利用したテレメトリ送信を利用する場合にはこの時点でロール作成をすることもできます。

テレメトリ送信を利用しない場合にはチェックを外すことでそのままエージェントをインストールすることも可能です。

エージェントのインストールが完了すると以下のような画面が表示されます。

次の設定画面では以下のプリセットが用意されています。(サポートされているワークロードは以下のとおり)

• EC2 (Linux)
• JVM
• Kafka Broker
• Kafka Producer
• Kafka Consumer
• NVIDIA GPU
• Tomcat

EC2コンソールからもCloudWatchエージェントの設定を行うことはできましたが、そちらより今回の設定の方がよりシンプルに設定を行えるようになっています。

設定編集(必須)のものはデフォルトの内容では利用できず、ユーザー側で設定を行う必要があります。

内容に問題なければ「CloudWatch エージェントを設定」をクリックするとエージェントの設定が完了します。

{"agent":{"usage_metadata":[{"ObservabilitySolution":"EC2_HEALTH"}]},"metrics":{"append_dimensions":{"InstanceId":"${aws:InstanceId}"},"metrics_collected":{"cpu":{"append_dimensions":{"InstanceType":"${aws:InstanceType}","ImageId":"${aws:ImageId}","AutoScalingGroupName":"${aws:AutoScalingGroupName}"},"measurement":["cpu_usage_idle","cpu_usage_iowait","cpu_usage_user","cpu_usage_system"],"totalcpu":true},"disk":{"append_dimensions":{"InstanceType":"${aws:InstanceType}","ImageId":"${aws:ImageId}","AutoScalingGroupName":"${aws:AutoScalingGroupName}"},"measurement":["used_percent","inodes_free"],"resources":["*"],"dimensions":[["device","fstype","path"]]},"diskio":{"append_dimensions":{"InstanceType":"${aws:InstanceType}","ImageId":"${aws:ImageId}","AutoScalingGroupName":"${aws:AutoScalingGroupName}"},"measurement":["io_time"],"resources":["*"]},"mem":{"append_dimensions":{"InstanceType":"${aws:InstanceType}","ImageId":"${aws:ImageId}","AutoScalingGroupName":"${aws:AutoScalingGroupName}"},"measurement":["used_percent"]},"swap":{"append_dimensions":{"InstanceType":"${aws:InstanceType}","ImageId":"${aws:ImageId}","AutoScalingGroupName":"${aws:AutoScalingGroupName}"},"measurement":["used_percent"]}}}}

設定中はページ移動せずに設定が完了するまで待つ必要があります。

設定が完了すると以下のような画面が表示されます。

「設定の進行状況を表示」をクリックするとわかりますが、設定の実態はSSM Run Commandを利用してエージェントのインストールと設定を行っています。

CloudWatchメトリクス上でも問題なくメトリクスが収集されていることが確認できますね

ワークロード検出

次に「ワークロード検出」を有効にしてみたいと思います。

ワークロード検出を有効にすると、先ほどの一覧画面でワークロードに関する情報が表示されるようになります。

今回はEC2(Linux) が識別されていますね。

この状態でワークロードが識別されているインスタンスを選択し、「設定の選択」まで進めると自動でEC2(Linux) の設定が選択されるようになっています。

今回は EC2(Linux) ですが、リストされているソフトウェアをインストールしている際にはこの辺りを自動識別して設定を行う感じになると思います。

あとは先ほどと同様に進めることでエージェントの設定が完了します。

タグベースのポリシー作成

次にタグベースポリシーを試してみたいと思います。

最初の「インスタンスを選択」の画面で、インスタンスタグを指定することで現在および将来起動されるインスタンスを対象にエージェントの設定を行うことができます。

ここではCloudWatch がTrue のインスタンスを対象にエージェントの設定を行っていきたいと思います。

裏でSSM Quick Setupが動くのでしょうね。AWS-QuickSetup-LocalAdministrationRoleとAWS-QuickSetup-LocalExecutionRoleロールの作成が必要になります。

• Quick Setup オンボーディングのための IAM ロールと権限 - AWS Systems Manager

また、手動インストールの時と違い、「自動更新 - オプション」が追加されています。

従来はSSM State Managerを使って自動更新を設定する必要がありましたが、こちらもサクッとコンソール内で設定を行えるようになっています。

作成が完了するとタグベース設定が追加されていることが確認できます。

プリセットの選択はタグベース設定ごとに行う必要があるようです。
（ワークロードの自動検出は効かなそう...?）

設定が問題なければ公開します。

ダッシュボードの方に新しく「タグベースの設定」が追加されています。

こちらからタグごとの適用状況を確認することができます。

タグベース名をクリックするとSSM QuickSetupの画面で設定を確認することができます。

では、新しいインスタンスに対してタグベースの設定を適用してみたいと思います。

タグベース設定に識別されるまで私の環境では5分程度かかりました。

識別後は裏でSSMが動きつつセットアップをしてくれます。

ただ私の環境ではCloudWatch Agentのセットアップでエラーが発生してしまいました。

Run Commandの実行ログを確認すると以下のようなエラーが発生していました。

エラーログを見るにQuickSetupで利用しているDHMCのIAMロールAWS-QuickSetup-SSM-DefaultEC2MgmtRole がSSMのパラメータストアの取得に失敗しているようです。

2025/11/22 23:35:13 E! fail to fetch/remove json config: error in retrieving parameter store content: AccessDeniedException: User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWS-QuickSetup-SSM-DefaultEC2MgmtRole-ap-northeast-1/i-09ad999c2a5288ccb is not authorized to perform: ssm:GetParameter on resource: arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:parameter/AmazonCloudWatch-Config-ec2-linux-1763853571520 because no identity-based policy allows the ssm:GetParameter actionstatus code: 400, request id: c67a2267-1552-4db4-997a-997597b556b7failed to run commands: exit status 1

11/23今日時点では以下のようなポリシーで取得ができないですね。

こちらは更新されるのを待つ必要がありそうです。
（ポリシー追加もできますが、IAMのDescriptionにもあるとおり非推奨です。）

{"Version":"2012-10-17","Statement":[{"Sid":"AllowSSMAgentPermissions","Effect":"Allow","Action":["ssm:DescribeAssociation","ssm:GetDeployablePatchSnapshotForInstance","ssm:GetDocument","ssm:DescribeDocument","ssm:GetManifest","ssm:ListAssociations","ssm:ListInstanceAssociations","ssm:PutInventory","ssm:PutComplianceItems","ssm:PutConfigurePackageResult","ssm:UpdateAssociationStatus","ssm:UpdateInstanceAssociationStatus","ssm:UpdateInstanceInformation"],"Resource":"*"},{"Sid":"AllowSSMChannelMessaging","Effect":"Allow","Action":["ssmmessages:CreateControlChannel","ssmmessages:CreateDataChannel","ssmmessages:OpenControlChannel","ssmmessages:OpenDataChannel"],"Resource":"*"},{"Sid":"AllowSSMLegacyMessaging","Effect":"Allow","Action":["ec2messages:AcknowledgeMessage","ec2messages:DeleteMessage","ec2messages:FailMessage","ec2messages:GetEndpoint","ec2messages:GetMessages","ec2messages:SendReply"],"Resource":"*"}]}

ちなみに対象のインスタンスに手動インストールを行うとすると、タグベース設定が適用されている場合、行えないようです。

手動で行う場合には一度タグ設定を外しましょう。

手動インストールであれば、無事CloudWatchエージェント設定を行うことができるのでワークアラウンド的にこちらを利用していただければと思います。

最後に

CloudWatchコンソール内でEC2インスタンスへのエージェント管理機能を試してみました。

手動インストールではコンソール上から最大50台までまとめてエージェントのインストールと設定が行えるようになり、従来のSSM Run Commandを個別に実行する手間が大幅に削減されました。

ワークロード検出機能では、インストールされているソフトウェアを自動識別して適切なプリセット設定を提案してくれるため、設定の手間も軽減されます。

タグベースポリシーでは、将来起動されるインスタンスにも自動的にエージェント設定が適用されるため、スケーラブルな運用が可能になります。

ただし、現時点（2025/11/23）ではDHMCで利用されるIAMロールにParameter Store取得権限が不足しているのでここは更新されるのを待つ必要がありそうです。

CloudWatchエージェントの運用管理が大幅に簡素化されるアップデートですね

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

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

この記事をシェアする