EC2メモリ使用率をCloudWatchで監視する方法：CloudWatchエージェント完全ガイド

EC2インスタンスのCPU使用率はCloudWatchコンソールで即座に確認できるのに、メモリ使用率を見ようとすると何も表示されない——この状況に直面したエンジニアは多い。アラームを設定しようとして初めて「なぜRAMのメトリクスが存在しないのか」に気づく。これはAWSの設計上の理由があり、CloudWatch Agentをインストールすることで解決できる。

TL;DR：EC2メモリ監視の要点

項目	内容
デフォルトで取得できるメトリクス	CPUUtilization、ネットワーク、ディスクI/O（ハイパーバイザーレベル）
デフォルトで取得できないメトリクス	メモリ使用率、ディスク空き容量、スワップ使用率
解決策	CloudWatch Agentをインスタンスにインストールし、OSレベルのメトリクスを送信
必要なIAM権限	CloudWatchAgentServerPolicyをインスタンスプロファイルにアタッチ
メトリクス名前空間	CWAgent（デフォルト）

なぜEC2メモリ使用率はCloudWatchに表示されないのか

CloudWatchがデフォルトで収集するEC2メトリクスは、AWSのハイパーバイザー（基盤となる仮想化レイヤー）が観測できる情報に限定される。CPUの使用サイクル数やネットワークパケット数はハイパーバイザーから見えるが、ゲストOS内部のメモリ割り当て状況はハイパーバイザーには見えない。

ハイパーバイザーとゲストOSの関係は、ビルのオーナーと入居テナントに似ている。オーナーは電力消費量（CPU）や出入りする荷物の量（ネットワーク）は把握できるが、部屋の中で何がどこに置かれているか（メモリの中身）は見えない。

これはAWSの制限ではなく、クラウド仮想化の構造的な特性だ。ゲストOS内部の状態を取得するには、OS内部で動作するエージェントプロセスが必要になる。それがCloudWatch Agentの役割だ。

graph TD HV["AWSハイパーバイザー
仮想化レイヤー"] EC2["EC2インスタンス
ゲストOS"] CWA["CloudWatch Agent
OSプロセス"] CW["Amazon CloudWatch"] NS1["AWS/EC2 名前空間
CPU・ネットワーク・EBS"] NS2["CWAgent 名前空間
メモリ・ディスク・スワップ"] HV -->|"自動収集（設定不要）"| NS1 NS1 --> CW EC2 -->|"OS内部で動作"| CWA CWA -->|"IAM権限で送信"| NS2 NS2 --> CW style NS1 fill:#f0f4ff,stroke:#4a6cf7 style NS2 fill:#fff4e6,stroke:#f7944a style CWA fill:#e6ffe6,stroke:#2d9e2d

ハイパーバイザーレイヤー：AWSインフラがCPU・ネットワーク・EBSのI/Oを自動収集し、CloudWatchへ送信する。インスタンス側の設定は不要。
ゲストOSレイヤー：メモリ・スワップ・ファイルシステムの空き容量はOS内部の情報。CloudWatch Agentがこれを収集してCloudWatchへ送信する。
メトリクスの分離：ハイパーバイザー由来のメトリクスはAWS/EC2名前空間に、エージェント由来のメトリクスはCWAgent名前空間に格納される。

CloudWatch Agentのインストールと設定手順

ステップ1：IAMインスタンスプロファイルの準備

CloudWatch AgentがメトリクスをCloudWatchへ書き込むには、EC2インスタンスに適切なIAMロールが必要だ。エージェントを起動してもメトリクスが届かない場合、まずここを疑う。AWSが提供するマネージドポリシーCloudWatchAgentServerPolicyをインスタンスプロファイルにアタッチするのが最小権限の観点から適切だ。

# インスタンスプロファイル用のIAMロールを作成
aws iam create-role \
  --role-name EC2CloudWatchAgentRole \
  --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 EC2CloudWatchAgentRole \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

# インスタンスプロファイルを作成してロールを追加
aws iam create-instance-profile \
  --instance-profile-name EC2CloudWatchAgentProfile

aws iam add-role-to-instance-profile \
  --instance-profile-name EC2CloudWatchAgentProfile \
  --role-name EC2CloudWatchAgentRole

# 既存インスタンスにプロファイルをアタッチ（instance-idは実際の値に置き換える）
aws ec2 associate-iam-instance-profile \
  --instance-id i-1234567890abcdef0 \
  --iam-instance-profile Name=EC2CloudWatchAgentProfile

ステップ2：CloudWatch Agentのインストール

インスタンスにSSH接続し、OSに応じたコマンドでエージェントをインストールする。Systems Manager経由でのリモートインストールも可能だが、ここでは直接インストールの手順を示す。

🔽 Amazon Linux 2 / Amazon Linux 2023 の場合

sudo yum install -y amazon-cloudwatch-agent

🔽 Ubuntu / Debian の場合

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

🔽 Windows Server の場合

# PowerShellで実行
Invoke-WebRequest -Uri https://s3.amazonaws.com/amazoncloudwatch-agent/windows/amd64/latest/amazon-cloudwatch-agent.msi -OutFile amazon-cloudwatch-agent.msi
Start-Process msiexec.exe -ArgumentList '/i amazon-cloudwatch-agent.msi /quiet' -Wait

ステップ3：エージェント設定ファイルの作成

ウィザードを使う方法と、設定ファイルを直接記述する方法がある。本番環境では設定をコード管理するため、JSONファイルを直接作成するアプローチが再現性の面で優れている。以下はメモリ・ディスク・スワップを収集する最小構成だ。

🔽 /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json（クリックして展開）

{
  "agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "cwagent"
  },
  "metrics": {
    "namespace": "CWAgent",
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}",
      "InstanceType": "${aws:InstanceType}"
    },
    "metrics_collected": {
      "mem": {
        "measurement": [
          "mem_used_percent",
          "mem_available",
          "mem_total"
        ],
        "metrics_collection_interval": 60
      },
      "swap": {
        "measurement": [
          "swap_used_percent"
        ],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": [
          "used_percent",
          "inodes_free"
        ],
        "metrics_collection_interval": 60,
        "resources": [
          "/",
          "/data"
        ]
      }
    }
  }
}

ステップ4：エージェントの起動と動作確認

設定ファイルを読み込んでエージェントを起動する。起動直後にメトリクスが届かない場合、エラーログを確認するのが最速の診断方法だ。

# 設定ファイルを指定してエージェントを起動
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/amazon-cloudwatch-agent.json

# エージェントのステータス確認
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -m ec2 \
  -a status

# エラーログの確認（起動失敗時）
sudo tail -f /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log

起動後、約1〜2分でCloudWatchコンソールのCWAgent名前空間にメトリクスが表示され始める。

ステップ5：CLIでメトリクスの到達を確認する

コンソールを開かずにメトリクスの存在を確認したい場合、以下のCLIコマンドで直接確認できる。エージェントを起動したのにメトリクスが見えないとき、まずこのコマンドで名前空間の存在自体を確認する。

# CWAgent名前空間のメトリクス一覧を確認
aws cloudwatch list-metrics \
  --namespace CWAgent \
  --region us-east-1

# 特定インスタンスのメモリ使用率を取得（直近1時間）
aws cloudwatch get-metric-statistics \
  --namespace CWAgent \
  --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --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 us-east-1

よくある失敗パターン：メトリクスが届かない原因の診断

エージェントをインストールして起動したのにCloudWatchにメトリクスが表示されない——これは実際の運用でよく遭遇するパターンだ。

症状：amazon-cloudwatch-agent-ctl -a statusはrunningを返すが、CloudWatchコンソールのCWAgent名前空間が空のまま。

誤った診断：「エージェントのバージョンが古い」「設定ファイルの構文エラー」と判断してインストールをやり直す。しかし設定ファイルの構文エラーがあればエージェント自体が起動しないため、running状態であればそこは問題ない。

実際の原因：インスタンスプロファイルにCloudWatchAgentServerPolicyがアタッチされていないか、アタッチ後にインスタンスへの反映が遅延している。エージェントはメトリクスをCloudWatchへ送信しようとするが、IAM権限がなければAccessDeniedエラーとなり、ログに記録される。

確認と修正：

# インスタンスにアタッチされているプロファイルを確認
aws ec2 describe-iam-instance-profile-associations \
  --filters Name=instance-id,Values=i-1234567890abcdef0 \
  --region us-east-1

# エージェントのエラーログでAccessDeniedを確認
sudo grep -i 'error\|denied' /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log | tail -20

IAMポリシーをアタッチした後、インスタンスメタデータサービス経由の認証情報更新には数分かかることがある。エージェントを再起動することで即座に新しい認証情報を取得させられる。

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -m ec2 \
  -a stop

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/amazon-cloudwatch-agent.json

IAM権限とエージェント設定は独立した問題だ。どちらか一方だけを見ていると、もう一方の問題を見落とす。

CloudWatch Agentの設定をSSMパラメータストアで管理する

複数インスタンスに同じエージェント設定を展開する場合、設定ファイルをSystems Manager Parameter Storeに保存して一元管理するのが実用的だ。設定変更時にインスタンスに個別にSSH接続する必要がなくなる。

# 設定ファイルをSSMパラメータストアに保存
aws ssm put-parameter \
  --name "/cloudwatch-agent/config/standard" \
  --type String \
  --value file:///opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json \
  --region us-east-1

# SSMパラメータストアから設定を読み込んでエージェントを起動
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -s \
  -c ssm:/cloudwatch-agent/config/standard

SSMパラメータストアから設定を読み込む場合、インスタンスプロファイルにAmazonSSMManagedInstanceCoreポリシーまたはSSMパラメータの読み取り権限が別途必要になる点に注意する。

メモリ使用率アラームの設定

メトリクスが届いていることを確認したら、実際にアラームを設定する。メモリ使用率が85%を超えた状態が続く場合にSNS通知を送る構成の例だ。

aws cloudwatch put-metric-alarm \
  --alarm-name "EC2-Memory-High-i-1234567890abcdef0" \
  --alarm-description "EC2インスタンスのメモリ使用率が85%を超過" \
  --namespace CWAgent \
  --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 3 \
  --threshold 85 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ec2-alerts \
  --region us-east-1

graph LR OS["ゲストOS
メモリ統計"] CWA["CloudWatch Agent
60秒ごとに収集"] CW["CloudWatch
CWAgent名前空間"] ALM["CloudWatch Alarm
閾値評価"] SNS["SNS トピック
通知送信"] OS -->|"proc/meminfo等"| CWA CWA -->|"PutMetricData API"| CW CW -->|"mem_used_percent >= 85%
3評価期間連続"| ALM ALM -->|"ALARM状態遷移"| SNS style CWA fill:#e6ffe6,stroke:#2d9e2d style ALM fill:#fff4e6,stroke:#f7944a style SNS fill:#ffe6e6,stroke:#e74c3c

CloudWatch Agent：インスタンス内部で動作し、60秒ごとにOSのメモリ統計を収集してCloudWatchへ送信する。
CWAgent名前空間：エージェントが送信したメトリクスはこの名前空間に格納される。デフォルトのAWS/EC2とは分離されている。
CloudWatch Alarm：設定した閾値を超えると評価期間のカウントを開始し、連続して超過した場合にアクションを実行する。
SNS通知：アラーム状態への遷移をトリガーとしてSNSトピックへ通知を送信する。

EC2メモリ監視のまとめと次のステップ

CloudWatchがデフォルトでEC2メモリ使用率を収集しない理由は、ハイパーバイザーがゲストOS内部の状態を観測できない構造にある。CloudWatch Agentをインストールし、IAMインスタンスプロファイルに適切な権限を付与することで、メモリ・ディスク・スワップといったOSレベルのメトリクスをCloudWatchで監視できるようになる。

次のステップとして、以下を検討するとよい：

Auto Scalingグループ内の全インスタンスへのエージェント展開には、EC2起動テンプレートのユーザーデータでインストールを自動化する
CloudWatch Container Insightsを使ったECS/EKSのコンテナレベルメモリ監視
CloudWatch Dashboardで複数インスタンスのメモリ使用率を一画面に集約する

公式ドキュメント：CloudWatch Agentのインストール — AWS公式ドキュメント

用語集

用語	説明
CloudWatch Agent	EC2インスタンス内部で動作し、OSレベルのメトリクスとログをCloudWatchへ送信するプロセス
ハイパーバイザー	物理サーバー上で複数の仮想マシンを管理するAWSの仮想化レイヤー。ゲストOS内部は観測できない
インスタンスプロファイル	EC2インスタンスにIAMロールを関連付けるコンテナ。インスタンス上で動作するプロセスがAWS APIを呼び出す際に使用される
CWAgent名前空間	CloudWatch Agentが送信するメトリクスのデフォルト格納先。AWS/EC2名前空間とは分離されている
mem_used_percent	CloudWatch Agentが収集するメモリ使用率のメトリクス名。利用可能なメモリに対する使用済みメモリの割合

S3パブリックアクセス拒否の原因と解決策：バケットレベルの「Block Public Access」が優先される仕組み

6月 02, 2026

このブログを検索

SW BBANG J