Introduction
Last year, after support for Windows 10 ended, I converted a PC that couldn't be upgraded to Windows 11 into a Linux machine (running Ubuntu 24.04). I wasn't sure how to put it to use, but I decided to try setting up a Linux PC management environment as a way to learn about AWS Systems Manager (SSM) and Amazon CloudWatch.
One issue I encountered was that the standard procedure for configuring authentication for the CloudWatch agent on an on-premises machine requires specifying an IAM user's access key and secret key.
Even though this was just for personal testing, I hesitated because I was concerned about the risk of an AWS environment compromise resulting from an exposed access key. However, I discovered that if the device is registered as a managed node using the Systems Manager "Hybrid Activations" feature, it is possible to configure authentication for the CloudWatch agent without using access keys.
In this article, I will cover the installation of the SSM Agent and CloudWatch agent, as well as the authentication configuration for the CloudWatch agent.
This article reflects the author's personal views. As the results are based on personal use, please treat them only as a reference. I would also appreciate it if you could point out any errors or omissions in the content.
Configuration
The setup is as shown in the diagram below. You need to install two components on the Linux PC: the CloudWatch agent and the Systems Manager Agent.
Agent Overview
AWS Systems Manager Agent
This agent enables the management, updating, and configuration of devices (EC2 instances, on-premises servers, and virtual machines) via AWS Systems Manager (SSM).
It comes pre-installed on some AMIs. However, for on-premises devices like the ones in this scenario, manual installation is required.
https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html
To bring an on-premises device under SSM management, you must register it as a managed node using hybrid activation.
https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html
CloudWatch Agent
This agent collects metrics, logs, and traces from Amazon EC2 instances, on-premises servers, and containerized applications. It enables you to view metrics in CloudWatch and monitor logs using CloudWatch Logs.
The URL below details the metrics that can be collected, such as memory utilization, CPU utilization, and network interface traffic volume.
Reasons for Using SSM Agent Temporary Credentials for the CloudWatch Agent
- To prevent AWS environment compromise resulting from access key leakage
- To eliminate the burden of manual key rotation
These are the two primary reasons.
Even though the goal is to use the CloudWatch agent, you generally do not want to store long-term credentials—such as access keys—on the device itself. If they were to leak, it could lead to a compromise of your AWS environment.
The SSM Agent can assume the IAM role associated via hybrid activation as temporary credentials. This allows it to utilize the permissions defined in the IAM policies attached to that role. In other words, if an IAM policy granting permission to upload (Put) logs via the CloudWatch agent is attached, you can upload logs from an on-premises environment.
Installing the SSM Agent
I installed the SSM Agent by following the instructions below.
Since permissions are required to connect to SSM from an on-premises environment, I created a hybrid activation and then registered the instance as an SSM managed node.
https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-hybrid-multicloud.html
Configuring Hybrid Activation
I executed the commands described in this section using AWS CloudShell.
① Create the trust policy JSON file shown below. You can choose any filename; I used TrustPolicy.json.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
② Create an IAM role by specifying the trust policy JSON file.
aws iam create-role \
--role-name IAMRoleName \
--assume-role-policy-document file://SSMService-Trust.json
③ Attach the AmazonSSMManagedInstanceCore IAM policy (required for basic SSM functionality) and the CloudWatchAgentServerPolicy IAM policy (required for the CloudWatch agent to send metrics and logs).
# Basic SSM functionality
aws iam attach-role-policy \
--role-name IAMRoleName \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
# For the CloudWatch agent to send metrics and logs
aws iam attach-role-policy \
--role-name IAMRoleName \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
If you are not using the CloudWatch agent, the
AmazonSSMManagedInstanceCoreIAM policy alone is sufficient; however, to achieve the goal of sending CloudWatch agent metrics and logs without using access keys, we configure theCloudWatchAgentServerPolicyhere.
④ Create a hybrid activation. I used the following settings:
- Management instance name: "instance-name"
- IAM role name to specify: IAMRoleName
- Registration limit for instances: 1
- Region for hybrid activation: ap-northeast-1 (Tokyo Region)
- Activation expiration date: YYYY-MM-DD 0:00:00 (YYYY = year, MM = month, DD = day)
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"
⑤ Make a note of the Activation ID and Activation Code output after executing the command above.
{
"ActivationId": "<Activation Id>"
"Activation Code": "<Activation Code>"
}
SSM Agent Installation and Managed Node Registration
The commands in this section are to be executed on the device where SSM Agent is being installed.
① Download ssm-setup-cli.
② Run ssm-setup-cli, specifying the Activation ID, Activation Code, and the region for registration.
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"
③ Upon success, a message like the following will be displayed.
(Omitted)
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
④ Run the following command and verify that Active: active (running) is displayed (confirming that the SSM Agent is running).
sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service
Private Key Automatic Rotation Settings
The maximum validity period (in days) for the on-premises private key is currently set to 0 days (no rotation); change this maximum validity period to 1 day.
① Create a backup of /etc/amazon/ssm/amazon-ssm-agent.json.
sudo cp /etc/amazon/ssm/amazon-ssm-agent.json /etc/amazon/ssm/amazon-ssm-agent.json.bak
② Copy the entire contents of the following JSON:
https://github.com/aws/amazon-ssm-agent/blob/mainline/amazon-ssm-agent.json.template
③ Clear the contents of /etc/amazon/ssm/amazon-ssm-agent.json completely, then paste the JSON copied in step ②.
④ Change the value of KeyAutoRotateDays to "1" (rotation every day).
⑤ Save and close the file.
This completes the installation of the SSM Agent and the registration of the managed node.
CloudWatch Agent Installation and Configuration
I installed the agent and configured the credentials by referring to the following:
*Reference for agent installation
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-premise.html
*Reference for authentication information settings (AWS re:Post article)
https://repost.aws/ja/knowledge-center/cloudwatch-on-premises-temp-credentials
The commands described in this section were executed by the author using AWS CloudShell.
Agent Installation
① Execute the following using 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
② It will be displayed as follows.
{
"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",
(Omitted)
CloudWatch Agent Credential Configuration
The commands described in this section were executed after connecting to the Linux PC using Session Manager.
① Edit common-config.toml. On a Linux machine, this file is typically located under /opt/aws/amazon-cloudwatch-agent/etc/.
sudo nano /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml
② If [credentials] is commented out, uncomment it and specify the credential profile and credential file.
For non-EC2 instances, SSM Agent credentials are stored in
/root/.aws/credentials.
*For details regarding credentials, please refer to "SSM Agent Credential Precedence" below.
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
[credentials]
shared_credential_profile = "default"
shared_credential_file = "/root/.aws/credentials"
③ Set the region in /root/.aws/config.
sudo mkdir -p /root/.aws
sudo nano /root/.aws/config
④ Create the CloudWatch agent configuration file. Save it in JSON format at /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json.
The following is an example configuration:
- Metrics
- CPU usage
- Memory usage
- Disk usage
- CloudWatch Logs
- Target for transmission: "/var/log/syslog"
- CloudWatch Logs log group: "ubuntu-pc-syslog"
- Sent to CloudWatch Logs stream: {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}"
}
]
}
}
}
}
⑤ Start the CloudWatch agent by specifying the CloudWatch agent configuration JSON file you created. Success is indicated when "Configuration validation succeeded" is displayed.
Meaning of each option:
-a fetch-config: Load configuration
-m onPremise: On-premises mode
-s: Start the agent after loading
-c file:...: Path to the configuration 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
⑥ Execute the following command and confirm that "status": "running" is displayed.
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status
This completes the installation of the CloudWatch agent and the configuration of credentials.
Verification
Confirm registration as a managed node
Output the node information for the corresponding managed node.
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 |
+-----------------------+---------+-------------+--------+-------------+-------------------+
Retrieving Metrics
Verify that the metrics configured for the CloudWatch agent are being retrieved in CloudWatch Metrics.
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 ||
|+---------------------+-----------------------------+----------+|
Retrieving Logs with CloudWatch Logs
Verify that the logs configured for the CloudWatch agent are being collected in CloudWatch Logs.
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
Points to Consider
By using SSM Agent's temporary credentials for the CloudWatch agent, you eliminate the need to generate and store access keys on your PC or manually rotate keys and update local credentials. However, certain risks remain:
- Compromise of the credentials on the device where the agent is installed
- Theft of the device (in the case of a PC)
Additionally, since SSM Agent's temporary credentials are used to send metrics and logs to CloudWatch, you must pay close attention to the IAM policies attached to the hybrid activation IAM role. For example, if an IAM policy allowing access to S3 objects is attached, a stolen device could potentially be used to access objects in your S3 buckets without authorization.
- Ensure IAM policies attached to the IAM role adhere to the principle of least privilege
- Prevent device loss
- Manage device accounts
You should consider these countermeasures as well.
Conclusion
In this article, I covered how to install the SSM Agent and CloudWatch agent, as well as how to configure authentication for the CloudWatch agent.
Using access keys and secret access keys—even just for the CloudWatch agent—entails operational overhead and the risk of credential leakage. If you are installing the CloudWatch agent on an on-premises device, installing the SSM Agent alongside it to convert the device into a managed node is likely the better, more secure, and less labor-intensive approach.
There may be specific reasons why the official documentation prioritizes procedures using access keys; however, given that the use of access keys is no longer recommended, I believe it is better to focus on procedures that include the SSM Agent whenever possible.
I was able to successfully manage my personal PC via SSM and monitor resources and logs using CloudWatch, so I look forward to utilizing these tools for future learning. Since CloudWatch Logs added support for journald logs on August 28, 2026, I plan to try that out and write another article about it.
https://aws.amazon.com/jp/about-aws/whats-new/2026/08/amazon-cloudwatch-agent-journald/
I hope this serves as a helpful reference for those about to start managing on-premises environments.
Thank you for reading to the end!

Top comments (0)