はじめに
昨年、Windows10のサポートが終了した後、Windows11にバージョンアップできないPCをLinux化（Ubuntu24.04）しました。活用方法に困っていましたが、AWS Systems Manager(以下、SSM）とAmazon CloudWatch(以下、CloudWatch）の勉強も兼ねて、Linux PC管理環境を作ってみようと思いました。
１つ困ったのが、オンプレ環境にインストールしたCloudWatchエージェントの認証情報に、IAMユーザーのアクセスキーおよびシークレットキーを指定する手順となっていることでした。
個人の検証用とはいえ、アクセスキー漏洩によるAWS環境への侵害が気になり躊躇しました。調べたところ、Systems Manager の機能 「ハイブリッドアクティベーション」 でマネージドノードにした端末ならば、アクセスキーを使わずにCloudWatchエージェントの認証設定もできることが分かりました。
今回はSSM AgentとCloudWatchエージェントのインストール、CloudWatchエージェントの認証設定について、記事を書いていきます。
本記事は、筆者個人の見解です。個人利用の範囲で試した結果のため、参考程度に留めてください。また、記載内容の不備不足等がありましたらご指摘いただけますと幸いです。
今回の構成
以下の図の通りです。Linux PCにはCloudWatchエージェント とSystems Manager Agent の２つをインストールする必要があります。
エージェントの概要
AWS Systems Manager Agent
AWS Systems Manager（以下、SSM）から端末（EC2インスタンス、オンプレミスサーバー、仮想マシン）を管理、更新、設定できるようにするエージェントです。
一部AMIsにはプリインストールされています。今回のようなオンプレミス端末には、個別インストールが必要です。
オンプレミス端末をSSMの管理対象にするには、ハイブリッドアクティベーションを使ってマネージドノードに登録する必要があります。
CloudWatch エージェント
Amazon EC2 インスタンス、オンプレミスサーバー、コンテナ化されたアプリケーションからメトリクス、ログ、トレースを収集します。CloudWatchでメトリクス表示、CloudWatch Logs にてログ監視をすることができるようになります。
以下URLに、取得できるメトリクスについて書かれています。メモリ使用率、CPU使用率、ネットワークインターフェイスでの送受信量などを取得できます。
CloudWatchエージェント認証情報にSSM Agent の一時認証情報を使う理由
- アクセスキー漏洩によるAWS環境への侵害を予防するため
- 手動キーローテーションの手間を無くすため
この２つに尽きます。
CloudWatchエージェントを使うためとはいえ、アクセスキーのような長期認証情報を端末内に保管しておきたくありません。漏洩したらAWS環境を侵害される恐れがあります。
SSM Agent は、ハイブリッドアクティベーションで関連付けたIAMロールを、一時認証として引き受けることができます。引き受けるIAMロールにアタッチされているIAMポリシーの権限を使うことができます。
つまり、CloudWatchエージェントからログをPutできる権限を持つIAMポリシーがアタッチされていれば、オンプレミスからログをPutすることができます。
SSM Agentインストール
以下を参照してSSM Agentのインストールを行いました。
オンプレからSSMに接続するための権限が必要になりますので、ハイブリッドアクティベーションを作成してからSSMにマネージドノード登録します。
ハイブリッドアクティベーションの設定
本セクションに記載のコマンドは、筆者はAWS CloudShellにて実行しました。
①以下の信頼ポリシーJSONファイルを作成します。ファイル名は任意ですが、TrustPolicy.jsonとしました。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
②信頼ポリシーJSONファイルを指定して、IAMロールを作成します。
aws iam create-role \
--role-name IAMRoleName \
--assume-role-policy-document file://SSMService-Trust.json
③SSMの基本機能を使うためのIAMポリシーAmazonSSMManagedInstanceCoreと、CloudWatchエージェントがメトリクスとログを送信するために必要なIAMポリシーCloudWatchAgentServerPolicyをアタッチします。
# SSM基本機能
aws iam attach-role-policy \
--role-name IAMRoleName \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
# CloudWatchエージェントがメトリクス・ログを送信するため
aws iam attach-role-policy \
--role-name IAMRoleName \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
CloudWatchエージェントを使わないならば、IAMポリシーはAmazonSSMManagedInstanceCoreだけで十分ですが、今回の目的である、アクセスキーを使わないCloudWatchエージェントのメトリクスとログ送信を実現するために、ここでCloudWatchAgentServerPolicyを設定します。
③ハイブリッドアクティベーションを作成します。筆者は以下の設定で作成しました。
- マネジメントインスタンス名："instance-name"
- 指定するIAMロール名：IAMRoleName
- マネジメントインスタンスに登録するインスタンスの制限数：１
- ハイブリッドアクティベーションを作成するリージョン：ap-northeast-1（東京リージョン）
- アクティベーションの有効期限：YYYY-MM-DD 0:00:00（YYYYは年、MMは月、DDは日）
aws ssm create-activation \
--default-instance-name "instance-name" \
--iam-role IAMRoleName \
--registration-limit 1 \
--region ap-northeast-1 \
--expiration-date "YYYY-MM-DDT00:00:00"
④上記コマンド実行後に出力されるActivation IdとActivation Codeを控えます。
{
"ActivationId": "<Activation Id>"
"Activation Code": "<Activation Code>"
}
SSM Agentインストールとマネージドノード登録
本セクションで実行するコマンドは、SSM Agentをインストールする端末で実行します。
①ssm-setup-cliをダウンロードします。
②Activation IdとActivation Code、登録するリージョンを指定し、ssm-setup-cliを実行します。
mkdir /tmp/ssm
curl https://amazon-ssm-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "<Activation Code>" -activation-id "<Activation Id>" -region "ap-northeast-1"
③成功すると、以下のようなメッセージが表示されます。
（略）
2026-10-08 02:12:32 INFO Starting agent using SnapSystemctl service manager
2026-10-08 02:12:32 INFO Agent is running
2026-10-08 02:12:32 INFO Successfully started agent, reloading registration info
2026-10-08 02:12:32 INFO Successfully registered the instance with AWS SSM using Managed instance-id: mi-xxxxxxxxxxxxxxxxx
2026-10-08 02:12:37 INFO Process Path: /snap/amazon-ssm-agent/xxxxx/amazon-ssm-agent
2026-10-08 02:12:37 INFO Agent process count: 1
2026-10-08 02:12:37 INFO Agent registration completed
④以下コマンドを実行し、Active: active (running)と表示されること（SSM Agent が稼働していること）を確認します。
sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service
プライベートキーの自動ローテーション設定
オンプレミスの秘密鍵の最大有効期間（日数）が0日（ローテーションしない）になっているため、最大有効期間を1日に変更します。
①/etc/amazon/ssm/amazon-ssm-agent.jsonをバックアップ取得します。
sudo cp /etc/amazon/ssm/amazon-ssm-agent.json /etc/amazon/ssm/amazon-ssm-agent.json.bak
②以下のJSONの内容をすべてコピーします。
③/etc/amazon/ssm/amazon-ssm-agent.jsonをすべて空にしてから、②でコピーしたJSONを貼り付けます。
④KeyAutoRotateDaysの値を"1"（１日でローテーション）に変更します。
⑤保存して閉じます。
以上で、SSM Agentのインストール、マネージドノード登録が完了です。
CloudWatch エージェントインストール及び設定
以下を参考にして、エージェントインストールと認証情報の設定をしました。
※エージェントインストール参考
※認証情報設定参考（AWS re:Postの記事）
本セクションに記載のコマンドは、筆者はAWS CloudShellにて実行しました。
エージェントインストール
①SSM Run Command にて以下実行します。
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--targets "Key=instanceids,Values=mi-xxxxxxxxxxxxxxxxx" \
--parameters '{"action":["Install"],"name":["AmazonCloudWatchAgent"]}' \
--region ap-northeast-1
②以下のように表示されます。
{
"Command": {
"CommandId": "XXXXXXXX-XXXX-XXXX-xxxx-xxxxxxxxxxxx",
"DocumentName": "AWS-ConfigureAWSPackage",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": "2026-10-08T15:47:53.058000+00:00",
"Parameters": {
"action": [
"Install"
],
"additionalArguments": [
"{}"
],
"name": [
"AmazonCloudWatchAgent"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "instanceids",
"Values": [
"mi-XXXXXXXXXXXXXXXXX"
]
}
],
"RequestedDateTime": "2026-10-08T12:47:53.058000+00:00",
"Status": "Pending",
"StatusDetails": "Pending",
"OutputS3Region": "ap-northeast-1",
（略）
CloudWatchエージェントの認証情報設定
本セクションに記載のコマンドは、セッションマネージャーでLinux PCに接続して実行しました。
①common-config.toml を編集します。Linuxマシンの場合、このファイルは通常 /opt/aws/amazon-cloudwatch-agent/etc/ 配下にあります。
sudo nano /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml
②[credentials]がコメントアウトされていたら外し、クレデンシャルプロファイルとクレデンシャルファイルを指定します。
非EC2インスタンスの場合 SSM Agent の認証情報は /root/.aws/credentials に保管されます。
※認証情報については、以下「SSM Agent 認証情報の優先順位」を参照
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
[credentials]
shared_credential_profile = "default"
shared_credential_file = "/root/.aws/credentials"
③/root/.aws/config にリージョンを設定します。
sudo mkdir -p /root/.aws
sudo nano /root/.aws/config
④CloudWatchエージェントの設定ファイルを作成します。JSON形式で /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json に保存します。
設定は一例です。
- メトリクス
- CPU使用率
- メモリ使用率
- ディスク使用率
- CloudWatch Logs
- 送信対象は、"/var/log/syslog" のログ
- CloudWatch Logs ロググループ"ubuntu-pc-syslog"
- CloudWatch Logs ストリーム{hostname}に送信
{
"agent": {
"metrics_collection_interval": 60,
"run_as_user": "root"
},
"metrics": {
"metrics_collected": {
"cpu": {
"measurement": ["cpu_usage_idle", "cpu_usage_user", "cpu_usage_system"],
"totalcpu": true
},
"mem": {
"measurement": ["mem_used_percent"]
},
"disk": {
"measurement": ["used_percent"],
"resources": ["/"]
}
}
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/syslog",
"log_group_name": "ubuntu-pc-syslog-all",
"log_stream_name": "{hostname}"
}
]
}
}
}
}
⑤作成したCloudWatchエージェント設定JSONファイルを指定して、CloudWatchエージェントを起動します。Configuration validation succeededと表示されたら成功です。
各オプションの意味：
-a fetch-config: 設定を読み込む
-m onPremise: オンプレミスモード
-s: 読み込み後にエージェントを起動
-c file:...: 設定ファイルのパス
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config \
-m onPremise \
-s \
-c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
⑥以下コマンドを実行して、"status": "running"と表示されることを確認します。
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status
以上でCloudWatchエージェントのインストールと認証情報設定は完了です。
動作確認
マネージドノードに登録されていることを確認
マネージドノードに該当するノード情報を出力します。
AWS CLIの場合
aws ssm describe-instance-information \
--filters "Key=ResourceType,Values=ManagedInstance" \
"Key=PingStatus,Values=Online" \
--query "InstanceInformationList[*].[InstanceId,PingStatus,AgentVersion,PlatformType,ComputerName,ResourceType]" \
--output table \
--region ap-northeast-1
--------------------------------------------------------------------------------------------
| DescribeInstanceInformation |
+-----------------------+---------+-------------+--------+-------------+-------------------+
| mi-xxxxxxxxxxxxxxxx | Online | 3.3.4793.0 | Linux | XXXXXXXXXX | ManagedInstance |
+-----------------------+---------+-------------+--------+-------------+-------------------+
フリートマネージャーの場合、miから始まるノードIDの有無を確認します。
メトリクスの取得
CloudWatchエージェントに設定したメトリクスを、CloudWatchメトリクスで取得できていることを確認します。
AWS CLIの場合（メモリ使用率）
aws cloudwatch get-metric-statistics \
--namespace "CWAgent" \
--metric-name "mem_used_percent" \
--dimensions Name=host,Value=XXXXXXXXXX \
--start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--period 300 \
--statistics Average \
--region ap-northeast-1
--output table
------------------------------------------------------------------
| GetMetricStatistics |
+------------------+---------------------------------------------+
| Label | mem_used_percent |
+------------------+---------------------------------------------+
|| Datapoints ||
|+---------------------+-----------------------------+----------+|
|| Average | Timestamp | Unit ||
|+---------------------+-----------------------------+----------+|
|| 25.064903122713268 | 2026-10-10T06:08:00+00:00 | Percent ||
|| 24.864319857743233 | 2026-10-10T06:18:00+00:00 | Percent ||
|| 25.052294740787254 | 2026-10-10T06:13:00+00:00 | Percent ||
|+---------------------+-----------------------------+----------+|
マネジメントコンソールより確認
CloudWatch Logs でログ取得
CloudWatchエージェントに設定したログを、CloudWatch Logs で取得できていることを確認します。
AWS CLIの場合
aws logs get-log-events \
--log-group-name "LogGroupName" \
--log-stream-name "StreamName" \
--limit 50 \
--query "events[*].[timestamp,message]" \
--output table \
--region ap-northeast-1
マネジメントコンソールからの場合
注意すべきこと
CloudWatchエージェントの認証情報としてSSM Agent の一時認証情報を使うことで、アクセスキーの発行してPCへの保存にしたり、アクセスキーのローテーションしてPC側の認証情報を変更するというが不要となりました。しかし、
- エージェントをインストールした端末そのものの認証情報漏洩
- 端末の盗難（PCの場合）
これらのリスクは残ります。また、SSM Agent の一時認証情報を使ってCloudWatchにメトリクスとログを送っているため、ハイブリッドアクティベーションのIAMロールにアタッチするIAMポリシーにも注意をしなければなりません。例えば、S3のオブジェクトを参照できるIAMポリシーがアタッチされていると、端末を盗まれたらS3バケット内のオブジェクトを不正に参照される恐れがあります。
- IAMロールにアタッチするIAMポリシーは 最小権限の原則 に従う
- 端末の紛失防止
- 端末のアカウント管理
これらの対策も検討しましょう。
最後に
今回は、SSM Agent と CloudWatchエージェントのインストール方法、CloudWatchエージェントの認証設定について書きました。
CloudWatchエージェントを使うためとはいえ、アクセスキーとシークレットアクセスキーを使うのは運用負荷と漏洩リスクがあります。オンプレミス端末にCloudWatchエージェントをインストールするならば、SSM Agentも一緒にインストールしてマネージドノード化した方が、運用負荷が低くセキュアで良さそうです。
公式ドキュメントでの手順がアクセスキーを使う手順にしている背景に何か理由があるのかもしれませんが、アクセスキーの使用が推奨されなくなった今、可能であればSSM Agentも一緒にインストールする手順をメインにした方がよさそうと思いました。
個人PCをSSMでの端末統制、CloudWatchでリソース監視やログ監視をすることができましたので、今後の学習に活用していきたくなりました。2026/8/28にCloudWatch Logs がjournaldログをサポートされましたので、こちらを試してまた記事を書きたいです。
これからオンプレ環境管理を始めようとしている方の参考になれば幸いです。
最後まで読んでいただき、ありがとうございました！