CloudWatch Agent と CloudWatch Logs の関係｜「ログが来ない」を解決する設定のキモ（Linux/Windows）

「Agentを入れて設定したのに CloudWatch Logs に何も出てこない」——監視で最初にハマる典型です。本記事は CloudWatch / Logs / Agent の役割を切り分け、コピペで動く設定JSON（Linux・Windows）と、症状→原因→対処の逆引き表で「ログが来ない」を最短で解決します。

01まず整理：CloudWatch / Logs / Agent は別物

「ログが来ない」で消耗する原因のほとんどは、名前が似た3つを同じものだと思い込むことです。まず役割を切り分けます。

• CloudWatch：監視サービスの総称（傘）。メトリクス・アラーム・ダッシュボード・Logs などを束ねる名前。
• CloudWatch Logs：ログの保管・検索の「置き場」。ロググループ／ログストリームに貯め、Logs Insights で検索する。
• CloudWatch Metrics：CPU使用率などの「数値」。アラームやグラフの対象。
• CloudWatch Agent：サーバーに入れて、ログファイルやOSメトリクスを送る「配達員」。

02Agentは要る？要らない？（既定で取れるもの・取れないもの）

EC2 は既定で AWS/EC2 名前空間に CPUUtilization・ネットワーク・ディスクI/O（EBS）・ステータスチェックを送っています。ただしこれらはハイパーバイザー視点の数値で、OSの中身は見えていません。

• 既定で取れる：CPU使用率、ネットワーク量、EBSのディスクI/O、ステータスチェック。
• 既定では取れない → Agent必要：メモリ使用率、ファイルシステムの空き容量（disk）、そしてOS内のログファイル。

つまり「メモリ・ディスク空きを監視したい」「アプリやOSのログを CloudWatch Logs に集めたい」なら Agent が要ります。逆に CPU とネットワークだけで足りるなら Agent は不要、という判断もアリです。

なお旧 awslogs（CloudWatch Logs エージェント）は非推奨です。IMDSv2 環境では統一 CloudWatch Agent が必須。新規は統一エージェント一択で進めてください。監視の位置づけの基礎は クラウドエンジニアの教科書（可用性・監視） も合わせてどうぞ。

03動かす前提：IAMロール・SSM・制御コマンド

Agent がログ・メトリクスを送れるのは、サーバーに付いたIAMロール（インスタンスプロファイル）のおかげです。ここが抜けていると、設定が正しくても Logs に何も出ません。最初に必ず確認します。

• CloudWatchAgentServerPolicy：メトリクス／ログ／トレース送信と、ロググループの保持期間設定を許可するAWS管理ポリシー。ロールにアタッチする。
• AmazonSSMManagedInstanceCore：SSM経由でインストール・設定配布する場合に付与。
• 制御は amazon-cloudwatch-agent-ctl（Linux）／ amazon-cloudwatch-agent-ctl.ps1（Windows）で行う。

# 1) IAMロール(インスタンスプロファイル)に必要な権限を付ける
#    - CloudWatchAgentServerPolicy   … メトリクス/ログ送信・保持期間設定
#    - AmazonSSMManagedInstanceCore  … SSM経由でインストール/配布する場合

# 2) SSM Run Command で統一エージェントを配布インストール
#    ドキュメント: AWS-ConfigureAWSPackage / パッケージ: AmazonCloudWatchAgent

# 3) インストール後の稼働確認は agent-ctl の status
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status

04Configのキモ①：agent / metrics / logs の3ブロック

設定ファイルは JSON で、agent / metrics / logs（＋X-Ray用の traces）のセクションで構成します。ログだけ集めたいなら metrics は省略可、メトリクスだけなら logs を省略可、という足し引きで考えると迷いません。

{
  "agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "cwagent"
  },
  "metrics": {
    "metrics_collected": { }
  },
  "logs": {
    "logs_collected": { }
  }
}

• agent：全体設定。収集間隔（秒）、実行ユーザ、リージョン上書きなど。
• metrics：送る数値の定義（メモリ・ディスク等）。
• logs：送るログの定義（ファイル or Windowsイベント）。

推奨の置き場所は Linux が /opt/aws/amazon-cloudwatch-agent/etc/ 配下、Windows が %ProgramData%\Amazon\AmazonCloudWatchAgent\ 配下です。ファイル名は任意ですが、切り分けやすいよう分かりやすい名前にします。

05Configのキモ②：metrics（メモリ・ディスクはここだけ）

メモリとディスク空きはこの metrics セクションにしか出てきません。逆に言えば、ここを書かない限りメモリ監視は永遠に始まりません。

{
  "metrics": {
    "namespace": "CWAgent",
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    },
    "metrics_collected": {
      "cpu":  { "resources": ["*"], "measurement": ["usage_active"], "totalcpu": true },
      "mem":  { "measurement": ["used_percent", "available_percent"] },
      "disk": { "resources": ["/"], "measurement": ["used_percent", "inodes_free"] }
    },
    "metrics_collection_interval": 60
  }
}

• namespace：メトリクスの置き場名。既定は CWAgent。
• metrics_collected：mem／disk／diskio／cpu などを列挙（mem・disk・diskio・swap は Linux専用）。
• append_dimensions：InstanceId を付けてインスタンス別に見分ける。値は ${aws:InstanceId} と書く。
• metrics_collection_interval：収集間隔（秒）。60未満にすると高解像度メトリクス扱いになる。

06Configのキモ③：logs（collect_listが本体）

ログファイルは logs_collected.files.collect_list に1エントリ＝1ログ種として並べます。ここでの指定ミスが「一部だけ来ない」の主因です。

{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/messages",
            "log_group_name": "/ec2/linux/messages",
            "log_stream_name": "{instance_id}",
            "timestamp_format": "%b %d %H:%M:%S",
            "retention_in_days": 30
          },
          {
            "file_path": "/var/log/nginx/error.log",
            "log_group_name": "/app/nginx/error",
            "log_stream_name": "{instance_id}",
            "timestamp_format": "%Y/%m/%d %H:%M:%S",
            "multi_line_start_pattern": "{timestamp_format}",
            "retention_in_days": 90
          }
        ]
      }
    }
  }
}

• file_path：収集元。* や **（super asterisk）で複数ファイルにマッチ可。
• log_group_name / log_stream_name：Logs上の置き場。ストリーム名は {instance_id} でインスタンス別に分ける。
• timestamp_format：ログの時刻書式（%Y %m %d %H %M %S %b 等の記号）。未指定だと取り込み時刻になり、時系列がずれる。
• multi_line_start_pattern：スタックトレース等の複数行を1件にまとめる。{timestamp_format} を指定すると時刻行を区切りにできる。
• retention_in_days：保持日数（1,3,5,7,14,30,60,90,…,3653）。未指定は無期限。

07適用と配布：fetch-config と SSM Parameter Store

設定はファイルを置いただけでは反映されません。fetch-config で読み込ませ、-s で（再）起動して初めて有効になります。ここを忘れて「変えたのに効かない」となる人が非常に多いです。

# ローカルのファイルから読み込んで起動（-s で start）
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/etc/config.json

# SSM Parameter Store に置いた設定を複数台へ一元配布
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux

# 状態確認 / 停止
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a stop

Windows では PowerShell から .ps1 を同じ引数で呼びます。

& "$Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" `
  -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-windows

• -a：アクション（fetch-config / start / stop / status / append-config / remove-config）。
• -m：モード（ec2 / onPremise / auto）。
• -c：設定ソース（file:パス / ssm:パラメータ名 / all）。
• -s：取得後に起動する。

08取るべきログ：Linux と Windows（表2つ）

「とりあえず全部」は費用と検索性の両面で損です。まずはトラブル解析に効く定番を押さえます。Linux はファイル収集が中心です。

一方 Windows は「ファイルではなくイベントログが主役」で、設定ブロックが別になります。System / Application / Security は windows_events セクションで event_name を指定して収集します。IIS のアクセスログだけはテキストファイルなので、Linux 同様に files 側で収集します。

Windowsイベントログの設定断片は次の通りです。event_levels でレベルを絞り、event_format は xml（イベントビューアと同じ形式）か text（旧エージェント形式）を選べます。

{
  "logs": {
    "logs_collected": {
      "windows_events": {
        "collect_list": [
          {
            "event_name": "System",
            "event_levels": ["ERROR", "CRITICAL", "WARNING"],
            "log_group_name": "/win/system",
            "log_stream_name": "{instance_id}",
            "event_format": "xml",
            "retention_in_days": 30
          },
          {
            "event_name": "Application",
            "event_levels": ["ERROR", "CRITICAL"],
            "log_group_name": "/win/application",
            "log_stream_name": "{instance_id}",
            "event_format": "xml"
          }
        ]
      },
      "files": {
        "collect_list": [
          {
            "file_path": "C:\\inetpub\\logs\\LogFiles\\**",
            "log_group_name": "/win/iis",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

ログの中身の読み方・grep での絞り込みは Linux実践コマンドリファレンス にまとめています。

09ユースケース：メモリ/ディスクのアラーム化・ログ調査

やりたいこと①：メモリ逼迫でアラートを出す。 Agentが送る CWAgent 名前空間の mem_used_percent（ディスクなら disk_used_percent）にアラームを張ります。

aws cloudwatch put-metric-alarm \
  --alarm-name mem-high \
  --namespace CWAgent \
  --metric-name mem_used_percent \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 80 --comparison-operator GreaterThanThreshold \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0

CLIの基本操作は AWS CLI実践リファレンス を参照してください。

やりたいこと②：アプリのエラーを追う。 集めたログは Logs Insights で横断検索します。

fields @timestamp, @message
| filter @message like /ERROR|Exception/
| sort @timestamp desc
| limit 50

10「ログが来ない」チェックリスト

Logs に何も出ない・一部だけ来ないときは、上から順に潰します。ほとんどはこの中にあります。

• IAMロール：CloudWatchAgentServerPolicy が付いているか（未アタッチ・権限不足が最多）。
• リージョン：送信先リージョンと、コンソールで見ているリージョンが一致しているか。
• file_path：パス・glob（* / **）が実在ファイルにマッチしているか。ファイルの読み取り権限があるか。
• timestamp_format：ログ実物の時刻書式と一致しているか（ずれると時系列が乱れる）。
• fetch-config / -s：設定変更後に読み直し＋再起動したか（置いただけは反映されない）。
• retention_in_days：未設定で無期限保管になっていないか（コスト膨張の原因）。
• ロググループ：未作成でも権限があれば自動作成される。出ないのは「作っていないから」ではなく上記が原因のことが多い。

11コンテナは別物（ECS / EKS）

EC2/オンプレの CloudWatch Agent 設定は、コンテナにはそのまま流用しません。ECS / EKS ではログ収集は Fluent Bit（FireLens / aws-for-fluent-bit）、メトリクスや Container Insights は CloudWatch agent や ADOT（AWS Distro for OpenTelemetry）を使う、という別の枠組みになります。

12早見表：症状 → 原因 → 対処（逆引き）

13よくある質問（FAQ）