AWS CloudWatchでメトリクスが表示されない？原因と解決策を徹底解説
生徒
「AWSでシステムを構築したのですが、CloudWatchの画面を見てもグラフにデータが表示されなくて困っています。設定は間違っていないはずなのですが...。」
先生
「CloudWatchでメトリクスが表示されない原因は、権限不足やエージェントの設定、あるいは表示期間の選択ミスなど、いくつかのパターンが考えられますね。」
生徒
「どこから確認していけば良いでしょうか？初心者でもチェックできるポイントを教えてください！」
先生
「もちろんです。まずはよくある原因を一つずつ整理して、解決方法を見ていきましょう！」
1. CloudWatchメトリクスの基本構造
CloudWatchは、AWSのリソースやアプリケーションを監視するためのサービスです。メトリクスとは、システムのパフォーマンスに関する時系列のデータポイントを指します。例えば、EC2インスタンスのCPU使用率や、ディスクの読み書き速度などがこれに該当します。
メトリクスが表示されない場合、まず理解しておくべきなのは「標準メトリクス」と「カスタムメトリクス」の違いです。標準メトリクスはAWSが自動的に収集するものですが、メモリ使用率やディスク空き容量などは標準では収集されず、カスタムメトリクスとして設定する必要があります。
2. EC2インスタンスのメトリクスが表示されない主な原因
EC2を利用している際、CPU使用率は見えるのにメモリ使用率が表示されないというケースが非常に多いです。これは、ハイパーバイザーレベルで取得できる情報と、OS内部でしか分からない情報があるためです。
OS内部の情報を取得するには、CloudWatch Agentをインストールし、正しく設定する必要があります。エージェントが動いていない、あるいは設定ファイルに不備がある場合、メトリクスは送信されません。また、IAMロールの権限が不足していると、エージェントがデータを書き込むことができず、結果としてグラフが空のままになります。
3. IAMロールと権限設定の確認
最も頻繁に発生するトラブルの一つが、IAMポリシーの設定ミスです。EC2などのリソースがCloudWatchにデータを送信するためには、適切な「許可」が必要です。具体的には「CloudWatchAgentServerPolicy」というマネージドポリシーがEC2インスタンスに関連付けられたIAMロールに付与されているかを確認してください。
もし、独自のポリシーを作成している場合は、PutMetricDataアクションが許可されているかを確認しましょう。これが許可されていないと、どんなにエージェントが頑張ってデータを送ろうとしても、AWS側で拒絶されてしまいます。
4. CloudWatch Agentのステータス確認コマンド
エージェントが正常に動作しているかを確認するには、Linuxサーバーにログインしてコマンドを実行するのが一番確実です。以下のコマンドを使って、サービスが起動しているかチェックしてみましょう。
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status
{
"status": "running",
"starttime": "2026-03-23T10:00:00Z",
"configstatus": "configured"
}もしステータスが「stopped」になっている場合は、設定ファイルを指定して起動する必要があります。設定ファイルが正しい場所に配置されているかも併せて確認してください。
5. 名前空間とディメンションの指定ミス
メトリクスを検索する際、「名前空間（Namespace）」や「ディメンション（Dimension）」を間違えていると、データが存在していても表示されません。デフォルトでは「CWAgent」という名前空間にカスタムメトリクスが保存されますが、設定ファイルで任意の名前に変更している場合があります。
また、インスタンスIDやイメージIDなどのディメンションが正確に一致していないと、フィルタリングの結果、何も表示されない状態になります。マネジメントコンソールの「すべてのメトリクス」タブから、ドリルダウン形式でデータが存在するか探してみるのが良い方法です。
6. 期間と統計設定の落とし穴
CloudWatchのグラフ画面右上にある「期間」の選択に注意してください。例えば、直近5分間のデータを表示したいのに、期間が「1時間」に設定されていると、最新のデータポイントがまだ集計されておらず、グラフが途切れて見えることがあります。
また、統計方法（平均、合計、最大、最小など）が適切かどうかも重要です。一度も発生していないイベントを「合計」で表示しようとしても、数値は0になります。表示されないのではなく、値が0であるためにグラフの底に張り付いているだけという可能性も疑ってみましょう。
7. ネットワーク設定とエンドポイントの確認
プライベートサブネットに配置されたインスタンスからメトリクスを送信する場合、インターネットゲートウェイやNATゲートウェイ経由でAWSのパブリックエンドポイントにアクセスできる必要があります。もし外部への通信が制限されている環境であれば、VPCエンドポイント（インターフェイス型）を作成して、CloudWatchへの経路を確保しなければなりません。
セキュリティグループの送信ルール（アウトバウンド）で、HTTPS（ポート443）の通信が許可されているかも確認のポイントです。通信が遮断されていると、エージェントのログに「Connection Timeout」などのエラーが出力されます。
8. ログファイルからの原因特定方法
どうしても原因がわからないときは、CloudWatch Agentが出力しているログファイルを直接確認しましょう。Linuxの場合、通常は以下のパスにログが保存されています。
tail -f /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log
2026-03-23T11:00:00Z E! [outputs.cloudwatchlogs] Private key not found
2026-03-23T11:00:05Z W! [outputs.cloudwatch] Error writing to CloudWatch: AccessDeniedこのようにログを確認することで、「認証エラー」なのか「ネットワークエラー」なのかを即座に判断できます。エラーメッセージをコピーして検索することで、より具体的な解決策にたどり着けるはずです。
9. 設定ファイルの記述ミスと反映方法
CloudWatch Agentの設定はJSON形式で記述されます。カンマの打ち忘れや括弧の閉じ忘れといった単純な構文エラーがあると、エージェントは起動しません。設定ファイルを編集した後は、必ずエージェントを再起動して設定を反映させましょう。
以下は、基本的なメモリ監視を有効にするための設定例です。これを参考に、自分の環境の設定と比較してみてください。
// これは設定のイメージを説明するための擬似的な構造です
{
"metrics": {
"metrics_collected": {
"mem": {
"measurement": [
"mem_used_percent"
],
"metrics_collection_interval": 60
}
}
}
}
設定を書き換えた後は、コマンドラインから設定の適用を行い、正常に読み込まれたかを確認するステップを忘れないようにしましょう。
10. 無料枠とデータ保持期間の制限
最後に、AWSの仕様による制限についても触れておきます。CloudWatchのメトリクスには保持期間があります。1分間隔のデータは15日間、5分間隔のデータは63日間保持されます。それ以上古いデータを見ようとしても、自動的に削除されているため表示されません。
また、古いインスタンスを削除（ターミネート）した場合、そのインスタンスに関連付けられていたメトリクスも一定期間が経過するとコンソールから見えなくなります。過去のトラブル調査を行う際は、データの保持期間内に確認を行うようにしましょう。
