Getting OpenClaw Logs into CloudWatch

March 21, 2026

#aws #lightsail #cloudwatch #openclaw #monitoring #devops

Using the AWS Lightsail OpenClaw blueprint? Here’s the one monitoring step it doesn’t set up for you.

The OpenClaw Lightsail blueprint handles a lot out of the box: Bedrock auth, TLS, the AI stack. What it doesn’t set up is log forwarding. If your instance goes sideways with inference errors, a crashed service, a bootstrap problem, you’ll want those logs somewhere you can query them without SSH-ing in. Here’s how to add CloudWatch log forwarding with CloudWatch Agent to an instance running the OpenClaw blueprint.

Why this might annoying on Lightsail

On EC2 you attach an IAM role with CloudWatchAgentServerPolicy and be done in a few minutes. On Lightsail it’s a bit more complicated. OpenClaw’s Bedrock setup script does create a modifiable IAM role (LightsailRoleFor-[instance-id]) but that role carries Bedrock and Marketplace permissions and not CloudWatch ones. You shouldn’t repurpose it because attaching CloudWatchAgentServerPolicy to it would give your AI workload broader AWS permissions than it needs. The agent also can’t pick up usable credentials from instance metadata on its own.

The fix: create a dedicated IAM user, generate access keys, and configure the agent to use those credentials explicitly. Yes, IAM users with static keys feel old-fashioned. It’s still the right call here, the agent may not obtain usable credentials any other way on Lightsail, and without them logs never make it to CloudWatch.

Step 1: Create the IAM user

Run these on your local machine, not on the Lightsail instance. The access key output will be in your terminal and you don’t want it captured by any remote session logging:

aws iam create-user --user-name openclaw-cloudwatch-agent --path /lightsail/openclaw/
aws iam attach-user-policy \
  --user-name openclaw-cloudwatch-agent \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws iam create-access-key --user-name openclaw-cloudwatch-agent

Save the AccessKeyId and SecretAccessKey from the last command. You won’t see the secret again.

CloudWatchAgentServerPolicy covers both metrics (cloudwatch:PutMetricData) and logs (logs:PutLogEvents, logs:CreateLogGroup, logs:CreateLogStream) — no custom policy needed.

** Rotate these keys periodically and use this IAM user only for the CloudWatch agent on this Lightsail instance.

Step 2: Install the agent on the instance

SSH into your OpenClaw instance (ssh ubuntu@<your-ip>) and run:

wget -q https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
sudo dpkg -i amazon-cloudwatch-agent.deb
rm amazon-cloudwatch-agent.deb

Step 3: Store the credentials

The agent looks for a specific profile name in a specific location:

sudo mkdir -p /root/.aws

sudo tee /root/.aws/credentials > /dev/null << 'EOF'
[AmazonCloudWatchAgent]
aws_access_key_id = AKIA...
aws_secret_access_key = ...
EOF

sudo tee /root/.aws/config > /dev/null << 'EOF'
[profile AmazonCloudWatchAgent]
region = us-east-1
EOF

sudo chmod 600 /root/.aws/credentials /root/.aws/config

The profile name AmazonCloudWatchAgent is what the agent looks for by default. Don’t change it unless you enjoy reading configuration docs.

The credentials aren’t stored in bash history this way — heredoc body content isn’t recorded, only the command line itself. If you’d rather not type secrets into a terminal at all, sudo -H aws configure --profile AmazonCloudWatchAgent is cleaner. The -H flag matters: without it, sudo may not set HOME=/root, and the config ends up in the wrong user’s .aws/ directory instead of /root/.aws/.

Then tell the agent to use this file instead of guessing:

sudo mkdir -p /opt/aws/amazon-cloudwatch-agent/etc

sudo tee /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml > /dev/null << 'EOF'
[credentials]
shared_credential_profile = "AmazonCloudWatchAgent"
shared_credential_file = "/root/.aws/credentials"
EOF

Step 4: Configure what to forward

Create the agent config at /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json:

sudo tee /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json > /dev/null << 'EOF'
{
    "agent": {
        "metrics_collection_interval": 60,
        "run_as_user": "root"
    },
    "logs": {
        "logs_collected": {
            "files": {
                "collect_list": [
                    {
                        "file_path": "/var/log/openclaw/*.log",  // verify this path on your install
                        "log_group_name": "/lightsail/openclaw/my-instance",
                        "log_stream_name": "openclaw-app",
                        "timezone": "UTC"
                    },
                    {
                        "file_path": "/var/log/syslog",
                        "log_group_name": "/lightsail/openclaw/my-instance",
                        "log_stream_name": "syslog",
                        "timezone": "UTC"
                    }
                ]
            }
        }
    }
}
EOF

Replace my-instance with your actual instance name. If you also want CPU/memory/disk metrics, add a "metrics" block, but for log-only setup this is all you need. This is a demo config and you should make your own.

Step 5: Start the agent

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
    -a fetch-config \
    -m onPremise \
    -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
    -s

The -m onPremise flag is important. -s means “restart after reconfiguring” — on a fresh install it’s effectively a start, and it also calls systemctl enable internally so the agent survives reboots.

Verify it’s running:

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status

You should see "status": "running".

Step 6: Verify logs are arriving

Give it a couple of minutes, then check from your local machine:

aws logs describe-log-groups \
  --log-group-name-prefix "/lightsail/openclaw/" \
  --region us-east-1

aws logs tail "/lightsail/openclaw/my-instance" --follow

The first command confirms the log group was created. The second streams live logs which is useful for watching what OpenClaw is doing in real time. (Note: aws logs tail requires AWS CLI v2.) ** Replace us-east-1 with the AWS Region where your Lightsail instance runs.

Doing this at boot (Recommended)

Running through these steps manually works, but if you ever rebuild the instance you’ll have to repeat it. The cleaner approach is a user_data script that runs on first boot. The Terraform template in this repo handles exactly that — the IAM user is created by Terraform, keys are injected via templatefile(), and the agent is configured and started automatically.

If you’re not using Terraform, the same script logic works as a launch script through the Lightsail console. It’s only available at creation time — look for the “Add launch script” field at the bottom of the instance creation wizard, below the SSH key selection.

The three log streams worth forwarding from an OpenClaw instance: openclaw-app (verify the path on your install — the AWS docs don’t pin down a default log directory) for inference/session errors, syslog (/var/log/syslog) for OS-level issues, and the bootstrap log (/var/log/user-data.log) to debug first-boot failures. Everything else is noise until you need it.