【新機能】CloudWatch agentのビジュアル設定エディタをやってみた

導入

EC2のメモリ使用率を取りたい。ただそれだけのために、CloudWatch agentをインストールして、設定JSONを書いて、SSMパラメータストアに置いて、fetch-configで反映して……という手順を踏んだ経験はありませんか。

CloudWatch agentは便利な反面、この「設定JSONの作成と配布」が長年の面倒ポイントでした。2026年4月のアップデートで、EC2コンソールからCloudWatch agentのインストールと設定がGUIで完結するウィザードが追加されました。今回は、従来のJSON手書きと比べてどこまで楽になったのかを実際に試して確かめます。結論を先に言うと「メトリクスもログもGUIで設定できる。ただしOS側の前提はGUIでは面倒を見てくれない」でした。

なお、この機能は執筆時点でベータ扱い・一部リージョンのみ・Linuxインスタンスのみ対応です。ドキュメント上の正式名称は「Install and configure the CloudWatch agent using the Amazon EC2 console」で、アナウンスにあった「visual editor」という名前は画面にもドキュメントにも出てきません（探すときのつまずきポイントなので先に書いておきます）。

出典： https://aws.amazon.com/blogs/mt/aws-observability-icymi-jan-may-2026/ （2026年4月リリースの項）
機能のドキュメント: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-and-configure-cloudwatch-agent-using-ec2-console.html

従来のCloudWatch agent設定（Before）

おさらいとして、これまでのCloudWatch agent導入は大きく3ステップでした。

インストール: SSM Run Command（AWS-ConfigureAWSPackage）やdnfでagentを各インスタンスに入れる
設定JSONの作成: ウィザード（amazon-cloudwatch-agent-config-wizard）で対話生成するか、手で書く
配布・反映: JSONをSSMパラメータストアに置き、amazon-cloudwatch-agent-ctl -a fetch-configで読み込ませる

たとえば「メモリ・ディスク使用率と/var/log/messagesの収集」という定番構成でも、これくらいのJSONを用意していました。

{
  "metrics": {
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    },
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": ["used_percent"],
        "resources": ["/"],
        "metrics_collection_interval": 60
      }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/messages",
            "log_group_name": "konishi-test-cwagent-messages",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

初見だとmeasurementに何が書けるのか、used_percentとdisk_used_percentのどちらなのか、といったところでドキュメントの確認が必要になります。これがGUIでどこまで潰れるのかが今回のテーマです。

検証環境の準備

※検証は東京リージョン（ap-northeast-1）で行いました。前述のとおり一部リージョンのみの提供ですが、東京リージョンでは執筆時点で利用できます。

検証構成は次のとおりです。EC2を1台用意し、EC2コンソールのウィザードからagentのインストールとメトリクス・ログ収集を設定して、CloudWatch側に届くことを確認します。

リソース	名前	用途
EC2インスタンス	`konishi-test-cwagent`	検証対象（Amazon Linux 2023 / t3.micro）
IAMロール	`konishi-test-cwagent-role`	`CloudWatchAgentServerPolicy`+`AmazonSSMManagedInstanceCore`
ロググループ	`konishi-test-cwagent-messages`	/var/log/messagesの送信先

準備はAWS CLIで行います。ポイントはIAMロールで、agentがメトリクス・ログを送るためのCloudWatchAgentServerPolicyと、SSM管理下に置くためのAmazonSSMManagedInstanceCoreの2つを付けておきます。この2つは本機能の前提条件としてドキュメントに明記されています。ただし後述のとおり、CloudWatchAgentServerPolicyのアタッチはウィザード側でも面倒を見てくれるので、事前に必須なのは実質「SSM管理下にあること」（AmazonSSMManagedInstanceCore）です。

# IAMロール＋インスタンスプロファイル
aws iam create-role \
  --role-name konishi-test-cwagent-role \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ec2.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name konishi-test-cwagent-role \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws iam attach-role-policy --role-name konishi-test-cwagent-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam create-instance-profile --instance-profile-name konishi-test-cwagent-profile
aws iam add-role-to-instance-profile \
  --instance-profile-name konishi-test-cwagent-profile \
  --role-name konishi-test-cwagent-role

# Amazon Linux 2023の最新AMIでt3.microを起動
AMI_ID=$(aws ssm get-parameter \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query 'Parameter.Value' --output text)
aws ec2 run-instances \
  --image-id "$AMI_ID" \
  --instance-type t3.micro \
  --iam-instance-profile Name=konishi-test-cwagent-profile \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=konishi-test-cwagent}]' \
  --metadata-options HttpTokens=required

SSHは使わないのでキーペアもインバウンド開放も不要です。起動後、SSMマネージドインスタンスとして認識されたことを確認しておきます。

aws ssm describe-instance-information \
  --filters Key=InstanceIds,Values="$INSTANCE_ID" \
  --query 'InstanceInformationList[].[InstanceId,PingStatus,PlatformName]' --output table

---------------------------------------------------
|           DescribeInstanceInformation           |
+----------------------+---------+----------------+
|  i-0xxxxxxxxxxxxxxxx |  Online |  Amazon Linux  |
+----------------------+---------+----------------+

ひとつ注意点として、コンソールを操作する側のIAMユーザー/ロールにも専用の権限（一時的なSSMパラメータへの読み書きやssm:SendCommandなど）が必要です。管理者権限で試す分には意識しませんが、権限を絞った運用アカウントで使う場合はドキュメントのポリシー例を参照してください。ただし後述のとおり、ドキュメントに書かれたパラメータ名と実際に使われる名前が違っていたので、ポリシー例をそのまま使うと動かない可能性があります。

ウィザードを使ってみる（After）

入口はここ

入口は2つあります。

インスタンス詳細の「モニタリング」タブ右上にある「CloudWatchエージェントを設定」ボタン
インスタンス一覧でインスタンスを選択 → 「アクション」→「モニタリングとトラブルシューティング」→「CloudWatchエージェントを設定」

2つ目のルートは複数インスタンスをまとめて選択できるので、複数台への一括適用もこの機能でカバーできます。

ボタンを押すと、「エージェントのステータス」→「設定を編集」→「レビューとデプロイ」の3ステップウィザードが開きます。従来手順の「①インストール ②設定作成 ③配布」がそのまま3画面になった構成です。

ステップ1: インストールとIAM権限の付与

最初の画面では、選択したインスタンスのSSMエージェントとCloudWatchエージェントのインストール状況がチェックされます。今回はagentを一切入れていない素のAL2023なので、「SSMエージェント: インストール済み / CloudWatchエージェント: 未インストール」と表示されました。

「エージェントをインストール」を押すと、すぐ実行されるのではなく「インストールの設定」ダイアログが開きました。このダイアログでIAM権限の付与まで行えます。

AWS-QuickSetup-CwagentPermissionsロールを作成して、CloudWatchAgentServerPolicyをEC2のインスタンスプロファイルへ自動アタッチできるようにする案内が出る（「ロールを作成」ボタン）
「テレメトリ公開を有効にする」のチェックで、選択したインスタンスにCloudWatchAgentServerPolicyをアタッチするかを選べる

「ロールを作成」を押すとロールが作成され、あわせて「選択したEC2インスタンスにアタッチされているIAMインスタンスプロファイルが変更されます。先に進む前に、この変更をセキュリティチームとレビューして承認したことを確認してください」という警告が表示されます。ボタン1つでインスタンスのIAMが変わるため、権限管理が厳しい環境では事前にレビューが必要です。

そのままダイアログの「エージェントをインストール」で、SSM経由でCloudWatch agentのインストールが実行されます。従来のBefore手順①と、その前段のIAM権限付与が、ダイアログ1つに収まりました。所要時間は1分もかからず、Run Commandの履歴を見るとインストール開始から状態確認の成功まで約30秒でした。

「ロールを作成」で実際に何が起きたか

IAMに何が起きたかをCLIで確認しました。

# 検証用ロールのポリシーが増減していないか
aws iam list-attached-role-policies --role-name konishi-test-cwagent-role \
  --query 'AttachedPolicies[].PolicyName' --output text
# → CloudWatchAgentServerPolicy     AmazonSSMManagedInstanceCore（変化なし）

# インスタンスに紐づくプロファイルが差し替わっていないか
aws ec2 describe-iam-instance-profile-associations \
  --filters Name=instance-id,Values="$INSTANCE_ID" \
  --query 'IamInstanceProfileAssociations[].IamInstanceProfile.Arn' --output text
# → arn:aws:iam::123456789012:instance-profile/konishi-test-cwagent-profile（変化なし）

今回は事前にCloudWatchAgentServerPolicyを付けてあったため、インスタンス側のロール・プロファイルはどちらも変更されていませんでした。既にポリシーがあれば重複して何かされることはないようです。

一方で「ロールを作成」で作られたものは、CloudFormationスタックAWSQuickSetupCWAgentPermissionsStack経由のAWS-QuickSetup-SetupCWAgentPermissionsというIAMロールでした（ダイアログに表示されるAWS-QuickSetup-CwagentPermissionsとは名前が異なります）。中身を見ると、EC2に付けるロールではなく、SSM Automationが「インスタンスプロファイルにポリシーを付ける作業」を実行するためのロールです。

aws iam get-role --role-name AWS-QuickSetup-SetupCWAgentPermissions \
  --query 'Role.AssumeRolePolicyDocument.Statement[0].Principal' --output json
# → {"Service": "ssm.amazonaws.com"}（automation-execution からの AssumeRole に限定）

aws iam list-attached-role-policies --role-name AWS-QuickSetup-SetupCWAgentPermissions \
  --query 'AttachedPolicies[].PolicyName' --output text
# → AWSQuickSetupManagedInstanceProfileExecutionPolicy

つまり「ボタン1つでインスタンスのIAMが変わる」の裏では、Quick Setupの仕組み（CloudFormation＋SSM Automation）が動いています。このロールとスタックは検証を終えても残るので、片付けの対象に入れておく必要があります。

なお画面上部には「ワークロード検出は無効です」というバナーが出ます。有効化するとインスタンス上のワークロードに応じた推奨設定項目を自動取得してくれる任意機能とのことです。今回は無効のまま進めました。

ステップ2: メトリクスもログもGUIで選べる

従来ならJSONのmetrics_collectedに書いていたメモリ使用率・ディスク使用率を、GUIで選んでいきます。選べるカテゴリはCPU・メモリ・ディスク・ディスクI/O・ネットワーク・netstat・プロセス・スワップ・ethtool（ENIの帯域超過など）・EBSの10種類でした。

画面上部の「エージェント設定」には、すべてのメトリクスに適用されるグローバル設定がまとまっています。収集間隔（秒）はここで変更でき、既定の60を30にすることもできました。JSONでいうagent.metrics_collection_intervalです。ほかにも名前空間（既定CWAgent）、リージョン、全メトリクスに付けるグローバルディメンション（InstanceId / InstanceType / ImageId / AutoScalingGroupName）、集計ディメンション、強制フラッシュ間隔まで、従来ならagentセクションやappend_dimensionsに手で書いていた項目がフォームになっています。

また、画面左上に「ビジュアル / JSON」の切り替えがあります。GUIで選んだ内容がそのままJSONとして表示されるので、「この操作がJSONのどこに効くのか」をその場で確認できます。

次にログ収集です。ドキュメントのタイトルは「additional metrics」でログには触れていませんが、画面下部の「統合を追加 (metrics, logs, traces)」から「ログ収集」を追加できました。ログファイル単位で次の項目が設定できます。

ファイルパス／ロググループ名／ログストリーム名（既定は{instance_id}）
含めるフィルター・除外フィルター（正規表現）
タイムスタンプ形式／複数行の開始パターン
保持期間／自動削除（ローテーション後のファイルハンドル解放）

従来JSONのcollect_listに書いていた項目が、そのままフォームになっています。ここまでは「JSONを書かずに済む」が完全に成立しています。

1点、コストには注意が必要です。ドキュメントに明記されているとおり、agentが送るメトリクスはすべてカスタムメトリクスとして課金されます。課金単位は「メトリクス名×ディメンションの組み合わせ」で、今回のように全カテゴリを選ぶとCWAgent名前空間に約70個のメトリクスが作られました。東京リージョンのカスタムメトリクスは1個あたり月額0.30USD（最初の10,000個まで。無料枠は月10個。2026年9月2日に料金ページで確認）なので、1台で月額20USD程度になります。GUIで選びやすいぶん、必要なカテゴリだけに絞ることを意識してください。

ステップ3: 適用。裏側はどうなっているのか

「レビューとデプロイ」で設定内容を確認して適用します。

この裏側の仕組みはドキュメントに明記されています。

選択した設定は、いったんSSMパラメータストアに一時保存される
SSM（Run Command）経由でagentに設定が配布される
配布が完了すると、一時パラメータはEC2側が自動削除する（プロセスが中断された場合だけ残る）

つまり従来手順の「JSONをパラメータストアに置いてfetch-config」を、ウィザードが一時パラメータを使って代行してくれている形です。恒久的な設定置き場としてパラメータストアを使うわけではない点が、従来手順との違いです。

CLIでも裏取りしました。Run Commandの実行履歴を見ると、インストールと設定配布に使われたドキュメントが分かります。なお検証は2日に分けて実施しており、9月1日にステップ1のインストール、9月2日にステップ2〜3の設定配布を行っています。履歴の日付が2日にまたがっているのはそのためです。

aws ssm list-commands --instance-id "$INSTANCE_ID" \
  --query 'Commands[].[RequestedDateTime,DocumentName,Status]' --output table

+-----------------------------------+--------------------------------+----------+
|  2026-09-02T14:48:35.910000+09:00 |  AmazonCloudWatch-ManageAgent  |  Success |  ← ステップ3（設定配布）
|  2026-09-02T14:45:10.242000+09:00 |  AmazonCloudWatch-ManageAgent  |  Success |  ← ステップ1（状態確認）
|  2026-09-01T18:47:12.154000+09:00 |  AmazonCloudWatch-ManageAgent  |  Success |
|  2026-09-01T18:46:53.268000+09:00 |  AmazonCloudWatch-ManageAgent  |  Success |
|  2026-09-01T18:46:42.462000+09:00 |  AWS-RunShellScript            |  Success |  ← インストール
|  2026-09-01T18:46:42.268000+09:00 |  AWS-ConfigureAWSPackage       |  Success |  ← インストール
|  2026-09-01T18:44:27.583000+09:00 |  AmazonCloudWatch-ManageAgent  |  Failed  |  ← 未インストール時の状態確認
|  2026-09-01T18:33:12.233000+09:00 |  AmazonCloudWatch-ManageAgent  |  Failed  |
+-----------------------------------+--------------------------------+----------+

インストールはAWS-ConfigureAWSPackage＋AWS-RunShellScript、設定配布と状態確認はAmazonCloudWatch-ManageAgent（action=configure / status）でした。従来手動で叩いていたドキュメントそのものです
agent未インストールの時点ではstatusがFailedになっており、ウィザードはこれで「未インストール」を判定しているようです（ステップ1を開くたびに1回飛びます）

配布に使われた一時パラメータの名前は、削除された後でもRun Commandのパラメータから確認できます。

aws ssm list-commands --instance-id "$INSTANCE_ID" \
  --query 'Commands[?DocumentName==`AmazonCloudWatch-ManageAgent`].[RequestedDateTime,Parameters.action[0],Parameters.optionalConfigurationLocation[0]]' --output table

/cloudwatch-agent/config/console-metrics-cpu-1788328114320,
/cloudwatch-agent/config/console-metrics-mem-1788328114538,
/cloudwatch-agent/config/console-metrics-disk-1788328114635,
（中略: net / diskio / swap / netstat / processes / ethtool / ebs）
/cloudwatch-agent/config/console-logs-1788328115411

ここで1つ発見がありました。ドキュメントには一時パラメータの名前がEC2-Custom-Metrics-*と書かれているのですが、実際に使われていたのは/cloudwatch-agent/config/console-metrics-<カテゴリ>-と/cloudwatch-agent/config/console-logs-でした。メトリクスのカテゴリごとに1つ、ログで1つ、計11個のパラメータをカンマ区切りでoptionalConfigurationLocationに渡しています。適用から1時間後にdescribe-parametersすると0件だったので、自動削除もドキュメントどおりでした。

ドキュメントのIAMポリシー例はarn:aws:ssm:*:*:parameter/EC2-Custom-Metrics-*に対する権限になっているので、これをそのまま絞った権限で使うと動かない可能性があります。今回は管理者権限で検証したため未確認ですが、権限を絞って使う場合はparameter/cloudwatch-agent/config/console-*も許可対象に含めておくのが安全です。ベータ機能なので、ドキュメントが追いつく前に実装が変わっているのかもしれません。

動作確認

メトリクスがCWAgent名前空間に届いた

数分待って、CWAgent名前空間を確認します。

aws cloudwatch list-metrics --namespace CWAgent \
  --query 'Metrics[].MetricName' --output text | tr '\t' '\n' | sort -u

cpu_usage_active / cpu_usage_idle / cpu_usage_iowait / cpu_usage_system / cpu_usage_user
disk_free / disk_inodes_free / disk_used_percent / diskio_io_time
ethtool_bw_in_allowance_exceeded / ethtool_bw_out_allowance_exceeded / ethtool_conntrack_allowance_exceeded / ethtool_linklocal_allowance_exceeded / ethtool_pps_allowance_exceeded
mem_active / mem_used_percent / net_bytes_recv / net_bytes_sent
netstat_tcp_established / netstat_tcp_time_wait / processes_running / processes_total / swap_used_percent

メモリ使用率の実データも1分間隔で取れています。

aws cloudwatch get-metric-statistics \
  --namespace CWAgent --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value="$INSTANCE_ID" \
  --start-time "$(date -u -v-30M +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 60 --statistics Average \
  --query 'sort_by(Datapoints,&Timestamp)[].[Timestamp,Average]' --output table

+----------------------------+----------------------+
|  2026-09-02T15:04:00+09:00 |  22.937153269373074  |
|  2026-09-02T15:05:00+09:00 |  22.883258979173707  |
|  2026-09-02T15:06:00+09:00 |  23.057346091166895  |
（以下1分刻みで続く）
+----------------------------+----------------------+

モニタリングタブには「CWAgent名前空間にメトリクスを含める」というトグルがあり、ONにするとCPU使用率などの標準メトリクスと同じ画面にagentのメモリ・ディスクメトリクスが並びます。設定した結果をその場で確認できて便利です。

ログはすぐには届かなかった

メトリクスは問題なく届いたのですが、ロググループkonishi-test-cwagent-messagesがいつまで待っても作成されませんでした。GUI上にはエラーも警告も一切出ません。結論から言うと原因は2つあり、どちらも「エディタの外側」の話でした。

原因1: AL2023には/var/log/messagesが無い

Amazon Linux 2023は既定でrsyslogが入っておらず、ログはjournaldのみです。つまり/var/log/messagesというファイル自体が存在しません。CloudWatch agentは監視対象ファイルが無いと何も送らず、ロググループは初回送信時に作られるので、いつまでも作成されないという状態になっていました。エディタはファイルパスの存在を検証しないので、設定は「成功」します。

SSM Run Command経由でagentのログを覗くと、設定自体は正しく届いていました。

file_path = "/var/log/messages"
log_group_name = "konishi-test-cwagent-messages"
I! [logagent] start logs plugin file paths [/var/log/messages]
ls: cannot access '/var/log/messages': No such file or directory

rsyslogを入れて/var/log/messagesを生成させます（これもSSM経由でSSH不要）。

aws ssm send-command --instance-ids "$INSTANCE_ID" --document-name AWS-RunShellScript \
  --parameters 'commands=["dnf install -y rsyslog","systemctl enable --now rsyslog"]'

原因2: 生成された設定はrun_as_user: cwagent固定で、rootのファイルが読めない

ファイルができてもまだ届きません。今度はagentのログにこれが毎秒出ていました。

E! [inputs.logfile] Failed to tail file /var/log/messages with error: open /var/log/messages: permission denied

ウィザードが生成した設定JSONには"run_as_user":"cwagent"が入っており、agentは非rootのcwagentユーザーで動いています。一方、rsyslogが作る/var/log/messagesは-rw------- root rootで、cwagentユーザーには読み取り権限がありません。従来の対話ウィザードでは「rootで動かすかcwagentで動かすか」を最初に聞かれましたが、GUIにはこの選択肢がありません。

対処はファイル側の権限をcwagentグループに開けることです。ローテーション後に作られる新ファイルにも効くよう、rsyslog側の作成モードもあわせて変えました。

aws ssm send-command --instance-ids "$INSTANCE_ID" --document-name AWS-RunShellScript \
  --parameters 'commands=["printf \"\\$FileCreateMode 0640\\n\\$FileGroup cwagent\\n\" > /etc/rsyslog.d/00-cwagent-readable.conf","chgrp cwagent /var/log/messages && chmod 640 /var/log/messages","systemctl restart rsyslog"]'

agentは1秒間隔でファイルを開き直しているので、再起動も再デプロイも不要でした。権限を直した直後にagentログが切り替わります。

E! [inputs.logfile] Failed to tail file /var/log/messages with error: open /var/log/messages: permission denied
I! [logagent] piping log from konishi-test-cwagent-messages/i-0xxxxxxxxxxxxxxxx(/var/log/messages) to cloudwatchlogs with retention -1

1〜2分後にロググループが自動作成され、ログが届きました。ログストリーム名はGUIの既定値{instance_id}が展開されてインスタンスIDになっています。

aws logs tail konishi-test-cwagent-messages --since 15m | tail -n 3

2026-09-02T06:35:43.415000+00:00 i-0xxxxxxxxxxxxxxxx Sep  2 06:35:42 ip-10-0-x-x systemd[1]: Finished refresh-policy-routes@ens5.service - Refresh policy routes for ens5.
2026-09-02T06:35:48.827000+00:00 i-0xxxxxxxxxxxxxxxx Sep  2 06:35:43 ip-10-0-x-x amazon-ssm-agent[1884]: 2026-09-02 06:35:43.8616 INFO [CredentialRefresher] Next credential rotation will be in 11.02206435915 minutes
2026-09-02T06:36:48.826000+00:00 i-0xxxxxxxxxxxxxxxx Sep  2 06:36:43 ip-10-0-x-x amazon-ssm-agent[1884]: 2026-09-02 06:36:43.8487 INFO [CredentialRefresher] Next credential rotation will be in 10.02227845145 minutes

この2つは、どちらも従来手順でも起きる問題です。ただ従来はJSONを書く過程で、ファイルの存在や実行ユーザーを一度は確認します。GUIだとその工程がまるごと無くなるぶん、OS側のログの出方とファイル権限を知らないと、何も表示されずに詰まる。切り分けにはagentのログ（/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log）を見る必要があります。

裏側でどんなJSONができているのか

GUIの操作が最終的にどんな設定JSONになったのか、インスタンス内を覗いてみます。SSM Run Commandを使えばSSH不要です。

aws ssm send-command \
  --instance-ids "$INSTANCE_ID" \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status","ls /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/","cat /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/*"]'

{
  "status": "running",
  "configstatus": "configured",
  "version": "1.300072.0b1766"
}
ssm__cloudwatch-agent_config_console-logs-1788330604253
ssm__cloudwatch-agent_config_console-metrics-cpu-1788330603223
ssm__cloudwatch-agent_config_console-metrics-disk-1788330603447
（中略）
ssm__cloudwatch-agent_config_console-metrics-swap-1788330603735

設定は1つのJSONではなく、カテゴリごとに分割された11ファイルとしてamazon-cloudwatch-agent.d/に置かれていました。ファイル名はSSMパラメータ名の/を_に置き換えたものです。ログの分とメモリの分を整形するとこうなります。

{
  "agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "cwagent",
    "region": "ap-northeast-1",
    "usage_metadata": [
      {"ObservabilitySolution": "ec2_health"},
      {"ObservabilitySolution": "log_collection"}
    ]
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/messages",
            "log_group_name": "konishi-test-cwagent-messages",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

{
  "agent": { "...同上..." },
  "metrics": {
    "namespace": "CWAgent",
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}",
      "InstanceType": "${aws:InstanceType}",
      "ImageId": "${aws:ImageId}",
      "AutoScalingGroupName": "${aws:AutoScalingGroupName}"
    },
    "aggregation_dimensions": [["InstanceId"]],
    "metrics_collected": {
      "mem": { "measurement": ["mem_used_percent"] }
    }
  }
}

冒頭に貼った手書きJSONと見比べると、GUIが吐くJSONは次の点が違います。

append_dimensionsが4種類フル指定、aggregation_dimensionsでInstanceId単位の集約が入る（手書きだと省略しがち）
measurementはmem_used_percentのような完全名で出る。used_percentとdisk_used_percentのどちらでも良いという曖昧さは無い
agent.usage_metadataにObservabilitySolutionが付く。コンソール経由で作られた設定だと分かる目印

「GUIの操作がこのJSONになる」という対応が見えるので、GUIで作ったあとにJSONを回収してIaC化する、という使い方もできそうです。

使ってみて分かったこと・制約

ドキュメントと実機で確認できた範囲をまとめます。

インストールから配布までウィザードが全部やってくれる。従来の3ステップのうち、人間に残るのは「GUIで項目を選ぶ」だけ。裏側はAWS-ConfigureAWSPackageとAmazonCloudWatch-ManageAgentで、従来手動で叩いていたSSMドキュメントそのもの
メトリクスもログもGUIで設定できる。ドキュメントは「metrics」としか言っていないが、「統合を追加」からログ収集（フィルター・タイムスタンプ形式・保持期間まで）が設定できる
IAM権限の付与までウィザードがやってくれる。CloudFormationスタック経由でAWS-QuickSetup-SetupCWAgentPermissionsロール（SSM Automation用）を作り、インスタンスプロファイルにCloudWatchAgentServerPolicyを付ける。既に付いていれば変更されない。警告メッセージのとおり権限管理が厳しい環境では事前レビューを。作成されたロールとスタックは後片付けしても勝手には消えない
OS側の前提はGUIでは面倒を見てくれない。ファイルの存在も、agent実行ユーザー（cwagent固定）に対する読み取り権限も検証されず、失敗してもGUIには何も出ない。AL2023で/var/log/messagesを取るならrsyslog導入と権限調整が別途必要
Linuxインスタンスのみ対応。Windowsは従来手順のまま
ベータ機能で一部リージョンのみ。EC2コンソールにメニューが出てこない場合はリージョン非対応の可能性がある（ドキュメントにも「別リージョンを試せ」と書いてある）
実行のたびに既存のagent設定を上書きする。以前選択したメトリクスのチェックを外して適用すると、そのメトリクスは収集されなくなる。手書きのカスタムJSONで運用しているインスタンスにうっかり使うと設定が消えるので要注意
複数台への一括適用は、インスタンス一覧から複数選択 → アクション経由で可能
コンソール操作側のIAMユーザーにも専用権限が必要。ただしドキュメントの一時パラメータ名（EC2-Custom-Metrics-*）と実際の名前（/cloudwatch-agent/config/console-*）が違うので、ポリシー例をそのまま使うと権限不足になる可能性がある（管理者権限で検証したため未確認）
収集間隔・名前空間・ディメンションなどのagentレベル設定もGUIで変更できる。「ビジュアル / JSON」切り替えで生成JSONの確認・直接編集も可能
追加したメトリクスはカスタムメトリクスとして課金される（ドキュメント明記）。全カテゴリを選ぶと1台あたり約70メトリクス、東京リージョンで月額20USD程度になる。必要なカテゴリだけ選ぶこと

後片付け

検証で作ったリソースを削除します。ウィザードが自動作成したロールはCloudFormationスタックの管理下なので、IAMを直接触らずスタック削除で消します。

# EC2の終了
aws ec2 terminate-instances --instance-ids "$INSTANCE_ID"

# ロググループの削除
aws logs delete-log-group --log-group-name konishi-test-cwagent-messages

# ウィザードが作ったQuick Setupロール（CloudFormationスタックごと削除）
aws cloudformation delete-stack --stack-name AWSQuickSetupCWAgentPermissionsStack
aws cloudformation wait stack-delete-complete --stack-name AWSQuickSetupCWAgentPermissionsStack

# 検証用のインスタンスプロファイルとIAMロール
aws iam remove-role-from-instance-profile \
  --instance-profile-name konishi-test-cwagent-profile \
  --role-name konishi-test-cwagent-role
aws iam delete-instance-profile --instance-profile-name konishi-test-cwagent-profile
aws iam detach-role-policy --role-name konishi-test-cwagent-role \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws iam detach-role-policy --role-name konishi-test-cwagent-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam delete-role --role-name konishi-test-cwagent-role

ステップ3で設定を配布するとき、ウィザードは設定JSONをSSMパラメータストアに/cloudwatch-agent/config/console-*として一時保存し、agentへの反映が終わるとEC2側がそのパラメータを自動で削除します。恒久的に残るものではないため、通常は片付けの対象になりません。配布の途中で中断した場合だけ削除まで進まず残ることがあるので、aws ssm describe-parameters --parameter-filters Key=Name,Option=BeginsWith,Values=/cloudwatch-agent/config/consoleで確認し、残っていればaws ssm delete-parameterで削除してください。CWAgent名前空間のメトリクスはデータが止まれば一覧から消えるので、削除操作は不要です。

まとめ

単発のLinux EC2にメモリ・ディスク監視を足すだけなら、コンソールで完結する時代になった。インストールも権限付与も配布もボタン1つで、JSONは1行も書かない
ログ収集もGUIで設定できる。ただし「そのファイルが存在するか」「agentがそれを読めるか」はOS側の話で、GUIは何も教えてくれない。動かないときはagentログを見る、という従来と同じ切り分け力は引き続き必要
既存のカスタム設定を上書きする挙動だけは要注意。まっさらなインスタンスに使うのが安全
追加メトリクスはカスタムメトリクス課金。全部入りにすると1台で月額20USD程度かかるので、選ぶカテゴリは絞る
Windows・IaC管理のケースでは引き続き従来手順（またはそれをコード化したもの）が現役。ただし細かい設定はGUIのJSONタブでかなり詰められるので、GUIで作ったJSONをIaCの雛形にする合わせ技は現実的
「まずメモリ使用率を取りたい」という最初の一歩は、従来より大幅に簡単になった

【新機能】CloudWatch agentのビジュアル設定エディタをやってみた

導入

従来のCloudWatch agent設定（Before）

検証環境の準備

ウィザードを使ってみる（After）

入口はここ

ステップ1: インストールとIAM権限の付与

「ロールを作成」で実際に何が起きたか

ステップ2: メトリクスもログもGUIで選べる

ステップ3: 適用。裏側はどうなっているのか

動作確認

メトリクスがCWAgent名前空間に届いた

ログはすぐには届かなかった

裏側でどんなJSONができているのか

使ってみて分かったこと・制約

後片付け

まとめ

Python × Ollama x Gemma4：ローカルLLMで業務を自動化する

Arduinoを初めて使う時のセットアップと実例集

Gemini Enterpriseのスキル（Skills）機能を試してみた

S3のストレージクラスの変更時に気をつけること

PagerDuty Summit Tokyo 2023レポート

導入

従来のCloudWatch agent設定（Before）

検証環境の準備

ウィザードを使ってみる（After）

入口はここ

ステップ1: インストールとIAM権限の付与

「ロールを作成」で実際に何が起きたか

ステップ2: メトリクスもログもGUIで選べる

ステップ3: 適用。裏側はどうなっているのか

動作確認

メトリクスがCWAgent名前空間に届いた

ログはすぐには届かなかった

裏側でどんなJSONができているのか

使ってみて分かったこと・制約

後片付け

まとめ

関連記事Related Articles

AWS Step FunctionsでJSONataを使ったSQSメッセージ処理バッチの構築と検証

QuickSightの出来る・出来ない

RDS のディスク容量不足がもたらす AWS Backup ジョブ期限切れ問題

「消したつもり」では消えない ── 初CTFで学んだ AWS シークレットが残る5つの場所

IAMユーザーにMFAを強制する方法 ── MFA未設定ならほぼ何もできなくする設定