AWS CloudWatch Agent導入・設定ガイド: Windows/EC2監視を最適化

AWS CloudWatch Agentで実現する多角的な監視の全体像と最短導入パス

CloudWatch Agentの必要性と監視の全体像

AWSの標準監視機能では、EC2インスタンスのCPU使用率やネットワークI/Oなど、ハイパーバイザー側から収集可能な基本的な情報に限定されます。しかし、OS内部のメモリ使用率、ディスク使用率、スワップ利用率といったOSレベルの詳細なメトリクスや、Windowsイベントログ、アプリケーションログなどは標準機能では取得できません。

ここで登場するのがCloudWatch Agentです。Agentを導入することで、これらのOS内部情報を収集し、CloudWatchへ送信できるようになります。これにより、より多角的な視点での監視が可能となり、問題の早期発見やパフォーマンス最適化に不可欠なデータを手に入れることができます。現代の企業においてクラウドサービスの利用率は高く、日本国内の企業では80.6%がクラウドサービスを利用しているというデータ（総務省 令和7年版 情報通信白書）もあり、クラウドインフラの効率的な運用監視は、ITエンジニアにとって必須のスキルとなっています。

CloudWatch Agentは、AWS環境におけるシステムの健全性を深く理解し、予期せぬ障害やパフォーマンスボトルネックに迅速に対応するための、まさに「目の役割」を果たすツールと言えるでしょう。

CloudWatch Agentが解決する課題と得られるメリット

CloudWatch Agentの導入は、AWSインフラ運用における多くの課題を解決し、運用担当者に大きなメリットをもたらします。最も大きな課題は、EC2インスタンス内部の状態がブラックボックス化しやすい点です。Agentを導入することで、このブラックボックスを解消し、OSレベルの詳細なパフォーマンスデータやログデータを可視化できます。

具体的なメリットとしては、例えばメモリ使用率が異常に高まった際にアラートを発し、アプリケーション障害が発生する前に対応できること、ディスクの空き容量が少なくなった際に事前に拡張計画を立てられることなどが挙げられます。これにより、障害発生後の対応ではなく、障害の予防へと監視体制をシフトさせることが可能になります。国内パブリッククラウドサービス市場規模が4兆1,423億円（総務省 令和7年版 情報通信白書）に達する中、このような先行的な運用監視は、システムの安定稼働とコスト効率の両面で極めて重要です。Agentは、運用の自動化、インシデント対応時間の短縮、そしてサービス品質の向上に貢献します。

Agent導入の最短パス：SSMを活用した効率的展開

CloudWatch Agentの導入は、AWS Systems Manager（SSM）を活用することで非常に効率的に進められます。SSMは、EC2インスタンスの運用管理を簡素化するサービスであり、Agentのインストールや設定ファイルのデプロイを大規模な環境でも容易にします。手動でのインストール作業は、特に多数のインスタンスを管理する場合には大きな負担となりますが、SSMを利用すれば、定義済みのRun CommandやState Managerを通じて、複数インスタンスに一度にAgentを展開することが可能です。

具体的な手順としては、まず対象のEC2インスタンスに「AmazonSSMManagedInstanceCore」および「CloudWatchAgentServerPolicy」という2つのIAMロールを付与します。これにより、SSMとCloudWatchの両サービスへのアクセス権限をAgentに与えます。次に、SSMのRun Command機能を使用して、CloudWatch Agentパッケージをインスタンスにインストールします。このアプローチにより、手動でのサーバーログインやコマンド実行の手間を省き、セキュリティリスクを低減しつつ、迅速かつ標準化されたAgentの導入を実現します。特にWindows環境では、PowerShellスクリプトをSSMで実行することで、エージェントのインストールから設定、起動までの一連のプロセスを自動化できます。

出典：総務省 令和7年版 情報通信白書

Agentのインストールから設定ファイル作成までのステップバイステップ

ステップ1: IAMロールの準備とSSMのセットアップ

CloudWatch AgentをEC2インスタンスに導入する最初のステップは、適切なIAMロールの準備です。AgentがメトリクスやログをCloudWatchに送信するためには、そのための権限が必要です。具体的には、EC2インスタンスにアタッチするIAMロールに、以下の2つのポリシーを付与します。

1. **AmazonSSMManagedInstanceCore**: EC2インスタンスがSSMサービスと通信し、SSM Run Commandなどで管理されるための基本権限です。これにより、SSMを通じてAgentのインストールや設定のデプロイが可能になります。
2. **CloudWatchAgentServerPolicy**: AgentがCloudWatchサービスに対してメトリクスやログをパブリッシュするための権限です。このポリシーには、`cloudwatch:PutMetricData`や`logs:CreateLogGroup`, `logs:PutLogEvents`などの必要なアクションが含まれています。

これらのポリシーをアタッチしたIAMロールを作成し、対象のEC2インスタンスにアタッチしてください。既存のインスタンスにアタッチする場合は、インスタンスを停止する必要はなく、実行中の状態でも変更が可能です。SSMが正しく機能しているか確認するには、AWS Systems Managerコンソールの「フリートマネージャー」で、対象インスタンスが「オンライン」と表示されているか確認しましょう。これにより、Agentのインストール準備が整います。

ステップ2: Systems ManagerによるAgentの展開とインストール

IAMロールの準備が完了したら、AWS Systems Manager (SSM) を利用してCloudWatch AgentをEC2インスタンスにインストールします。この方法は、手動で各インスタンスにログインして作業するよりも、はるかに効率的でエラーのリスクを低減します。

1. **SSM Run Commandの利用**: AWSコンソールからSSMサービスに移動し、「Run Command」を選択します。
2. **コマンドの選択**: 「AWS-ConfigureAWSPackage」というドキュメントを選択します。このドキュメントは、AWSが提供するパッケージ（CloudWatch Agentなど）のインストール、アンインストール、更新を行うためのものです。
3. **パラメータの設定**:
   • **Action**: 「Install」を選択します。
   • **Name**: 「AmazonCloudWatchAgent」と入力します。
   • **Version**: 最新バージョンを使用する場合は空欄にします。特定のバージョンを指定することも可能です。
4. **ターゲットの選択**: AgentをインストールするEC2インスタンスを選択します。タグ指定や手動選択が可能です。
5. **実行**: コマンドを実行し、インストールの完了を待ちます。Windowsインスタンスの場合、エージェントはサービスとしてインストールされ、自動的に起動するよう設定されます。

インストールが完了したら、EC2インスタンスにログインし、Windowsの場合はサービスマネージャーで「Amazon CloudWatch Agent」サービスが実行中であることを確認してください。

ステップ3: JSON形式の設定ファイル作成と配置

CloudWatch Agentは、JSON形式の設定ファイルに基づいて、どのメトリクスやログを収集するかを決定します。この設定ファイルは、Agentの挙動をカスタマイズするための最も重要な要素です。Windows環境では、AWSが提供する`amazon-cloudwatch-agent-config-wizard`コマンドラインツールを使用するのが最も簡単で推奨される方法です。

1. **ウィザードの実行**: Windowsインスタンスにリモートデスクトップ接続し、PowerShellまたはコマンドプロンプトを開きます。
   `&”C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-config-wizard.exe”` を実行します。
2. **質問への回答**: ウィザードは、EC2かオンプレミスか、監視するOS、メトリクス収集の間隔、どのメトリクスを収集するか（CPU、メモリ、ディスクなど）、ログ収集の有無など、一連の質問を対話形式で尋ねてきます。Windowsに特有の質問には、イベントログやIISログの収集に関するものも含まれます。
3. **設定ファイルの生成**: 回答に基づき、ウィザードは`config.json`という設定ファイルを生成します。このファイルは、デフォルトでAgentのインストールディレクトリ（通常は`C:\ProgramData\Amazon\AmazonCloudWatchAgent\config.json`）に配置されます。
4. **設定の適用**: 生成された設定ファイルをAgentに適用するには、以下のコマンドを実行してAgentを再起動します。
   `&”C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1″ -a fetch-config -m ec2 -c file:C:\ProgramData\Amazon\AmazonCloudWatchAgent\config.json -s`

この手順により、Agentは定義された設定に基づいてメトリクスとログの収集を開始します。必要に応じて、生成された`config.json`を直接編集して、より詳細なカスタマイズを行うことも可能です。

出典：Amazon CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する

WindowsイベントログやEC2ログ収集のための設定テンプレート集

Windowsイベントログを収集する基本的な設定

Windowsサーバーを監視する上で、イベントログの収集は非常に重要です。システムの状態、セキュリティイベント、アプリケーションエラーなどを把握するために不可欠な情報源となります。CloudWatch Agentの設定ファイルでは、`logs`セクション内で`metrics_collected`や`log_stream_name`などのパラメータを使ってイベントログを定義します。

以下は、一般的なWindowsイベントログ（アプリケーション、システム、セキュリティ）を収集するための設定の例です。

"logs": {
  "logs_collected": {
    "windows_events": {
      "collect_list": [
        {
          "event_name": "Application",
          "event_levels": ["CRITICAL", "ERROR", "WARNING", "INFORMATION", "VERBOSE"],
          "log_group_name": "/aws/ec2/windows/application",
          "log_stream_name": "{instance_id}/Application"
        },
        {
          "event_name": "System",
          "event_levels": ["CRITICAL", "ERROR", "WARNING", "INFORMATION", "VERBOSE"],
          "log_group_name": "/aws/ec2/windows/system",
          "log_stream_name": "{instance_id}/System"
        },
        {
          "event_name": "Security",
          "event_levels": ["CRITICAL", "ERROR", "WARNING", "INFORMATION", "VERBOSE"],
          "log_group_name": "/aws/ec2/windows/security",
          "log_stream_name": "{instance_id}/Security"
        }
      ]
    }
  }
}

この設定では、各イベントログの種類ごとに専用のCloudWatch Logsグループが作成され、インスタンスIDをストリーム名に含めることで、どのインスタンスからのログであるかを識別しやすくなります。`event_levels`で収集するログレベルを細かく指定することで、不要なログの収集を抑制し、コスト最適化にも繋がります。

パフォーマンスカウンタとカスタムメトリクスの設定例

CloudWatch Agentは、Windowsのパフォーマンスカウンタをメトリクスとして収集する機能を提供します。これにより、CPU使用率、メモリ使用率、ディスクI/O、ネットワークトラフィックなど、OSレベルの詳細なパフォーマンスデータをCloudWatch Metricsで可視化できるようになります。ウィザードで基本的な設定は可能ですが、より細かく監視したい場合は手動での追加も有効です。

以下に、Windowsインスタンスのメモリ使用率とディスクI/Oを収集する設定の例を示します。

"metrics": {
  "metrics_collected": {
    "windows": {
      "measurement": [
        {"name": "Memory % Committed Bytes In Use", "rename": "Memory_CommittedBytesInUse", "unit": "Percent"},
        {"name": "PhysicalDisk % Disk Time", "rename": "PhysicalDisk_DiskTime", "unit": "Percent", "resources": ["*"]},
        {"name": "PhysicalDisk Avg. Disk Queue Length", "rename": "PhysicalDisk_AvgDiskQueueLength", "unit": "Count", "resources": ["*"]}
      ],
      "metrics_collection_interval": 60 // 60秒間隔で収集
    },
    "Processor": {
      "measurement": [
        {"name": "% Processor Time", "unit": "Percent", "resources": ["_Total"]}
      ],
      "metrics_collection_interval": 60
    }
  }
}

`measurement`配下で収集したいパフォーマンスカウンタを指定します。`rename`オプションでCloudWatch上でのメトリクス名を分かりやすく変更でき、`unit`で単位を設定します。ディスク関連のメトリクスでは`”resources”: [“*”]`とすることで、すべての物理ディスクに対してメトリクスを収集できます。これらのメトリクスは、CloudWatchダッシュボードでグラフ化し、アラーム設定を行うことで、システムの異常を早期に検知するための基盤となります。

ログ収集設定のベストプラクティスとコスト最適化

CloudWatch Logsは、収集したログの量に応じて料金が発生するため、無計画なログ収集は予期せぬコスト増大を招く可能性があります。効果的なログ収集を実現しつつコストを最適化するためには、いくつかのベストプラクティスを適用することが重要です。

1. **必要なログのみを収集**: すべてのログを収集するのではなく、トラブルシューティングやセキュリティ監査に本当に必要なログのみに絞り込みましょう。例えば、デバッグレベルのログは通常運用時には収集せず、特定の条件で有効にするなどの運用が考えられます。
2. **ログのフィルタリング**: Agentの設定ファイル内で、特定のキーワードを含むログのみを収集したり、特定のパターンに一致するログを除外したりするフィルタリング設定が可能です。これにより、不要なログをCloudWatch Logsに送信する前に破棄できます。
3. **ログの保持期間の設定**: CloudWatch Logsのロググループごとに、ログの保持期間を設定できます。デフォルトでは「無期限」ですが、不要なログを長期間保持しないように、適切な期間（例: 30日、90日）を設定しましょう。これは、ログストレージのコストに直結します。
4. **ロググループとストリーム名の設計**: 複数のインスタンスからログを収集する場合、インスタンスIDやアプリケーション名などを`log_stream_name`に含めることで、ログの検索性と管理性が向上します。

これらの対策を講じることで、必要な情報を確実に手に入れながら、CloudWatch Logsの運用コストを効果的に管理できます。特に、アプリケーションログなどの詳細なログを収集する際は、ログレベルの調整とフィルタリングが極めて重要になります。

出典：CloudWatch エージェント設定ファイルを手動で作成または編集する

Agent設定時の一般的な落とし穴とその回避策

IAM権限不足によるAgent起動失敗の回避策

CloudWatch Agentの導入において最も頻繁に遭遇する問題の一つが、IAM権限の不足です。Agentは、EC2インスタンスにアタッチされたIAMロールの権限を使用して、CloudWatchにメトリクスやログを送信します。このIAMロールに必要なポリシー（前述の`CloudWatchAgentServerPolicy`など）が正しく付与されていないと、Agentはデータを送信できず、最終的に起動に失敗したり、正常に動作しなかったりします。

この問題の回避策は、まずIAMロールに**`CloudWatchAgentServerPolicy`**が確実にアタッチされていることを確認することです。さらに、SSM経由でAgentを管理する場合は、**`AmazonSSMManagedInstanceCore`**ポリシーも必須です。エラー発生時には、インスタンスのシステムログ（Windowsイベントビューア）や、CloudWatch Agent自身のログファイル（`C:\ProgramData\Amazon\AmazonCloudWatchAgent\Logs\amazon-cloudwatch-agent.log`）を確認してください。権限エラーに関するメッセージが出力されているはずです。IAMポリシーの`Action`や`Resource`が、Agentが必要とする操作と完全に一致しているか細かく見直すことも重要です。最小権限の原則に基づきつつも、Agentが動作するために必要な権限は不足なく付与するようにしましょう。

WindowsとLinuxでの設定差異と命名規則への対応

CloudWatch Agentの設定ファイルは、OSによって一部の違いがあります。特にWindows環境では、Linuxとは異なる命名規則やパスの指定方法に注意が必要です。例えば、Linuxのディスクは`/dev/xvda1`のような形式ですが、Windowsでは`C:`や`D:`といったドライブレターが使用されます。パフォーマンスカウンタの名前も、Linuxでは`cpu_usage_idle`のような形式ですが、Windowsでは`% Processor Time`といった形になります。

この差異に対応するためには、以下の点に留意してください。

1. **設定ウィザードの活用**: Windowsインスタンスで`amazon-cloudwatch-agent-config-wizard`を実行する際、ウィザードがOSに適したデフォルト設定を生成してくれるため、手動で一から作成するよりもエラーが少なくなります。
2. **ディスクの命名規則**: ディスク関連のメトリクスを収集する場合、Windowsでは`PhysicalDisk`や`LogicalDisk`といったオブジェクト名と、そのインスタンス（`C:`、`D:`、`_Total`など）を正確に指定する必要があります。
3. **パスの記述**: ログファイルパスを指定する際、Windowsではバックスラッシュ（`\`）ではなくスラッシュ（`/`）を使用するか、バックスラッシュをエスケープ（`\\`）する必要があります。JSON形式の文字列として正しく記述することが重要です。

これらのOSごとの特性を理解し、適切な設定を適用することで、AgentはWindows環境でも意図通りに動作します。公式ドキュメントにはOSごとの詳細な設定例が記載されているため、参照することをおすすめします。

過剰なログ収集によるコスト増大と最適化戦略

CloudWatch Agentは非常に便利ですが、設定を誤ると予期せぬコスト増大を招く可能性があります。特に、ログの収集量が多くなると、CloudWatch Logsへのデータ取り込み料金やストレージ料金が膨らみ、運用コストを圧迫することになります。この落とし穴を回避し、コストを最適化するためには、賢い設定戦略が必要です。

主な最適化戦略は以下の通りです。

1. **必要なログのみに絞る**: デバッグレベルのログや、ほとんど情報価値のない大量のINFOレベルログは、通常運用時には収集しないように設定を見直しましょう。
2. **フィルタリングの活用**: CloudWatch Agentの設定ファイルには、特定のパターンに一致するログ行のみを収集したり、逆に特定のパターンを無視したりするフィルタリング機能があります。これにより、CloudWatch Logsに送信されるデータ量を削減できます。
3. **ログ保持期間の適切な設定**: CloudWatch Logsのロググループごとに、ログの保持期間を設定できます。無期限ではなく、ビジネス要件やコンプライアンス要件に応じた期間（例: 30日、90日、1年）を設定することで、ストレージコストを削減できます。
4. **メトリクスの収集間隔**: メトリクスの収集間隔を短くしすぎると、`PutMetricData`のAPI呼び出し回数が増え、コストが増加します。監視要件に応じて、適切な間隔（例: 1分、5分）を設定しましょう。

これらの対策を事前に検討し、設定に盛り込むことで、監視の質を維持しつつ、コストを抑制したCloudWatch Agent運用が可能になります。

出典：AWS Documentation

【ケース】Agentが意図通りに動作しない際のトラブルシューティングと学び

ケース1: Agentが起動しない・メトリクスが上がらない場合の初動対応

CloudWatch Agentをインストールし、設定ファイルを適用したにもかかわらず、Agentが起動しない、またはCloudWatchコンソールにメトリクスが表示されない、という状況はよく発生します。このような場合の初動対応は、以下の手順で進めます。

1. **Agentのステータス確認**:
   • **Windows**: PowerShellまたはコマンドプロンプトで `&”C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1″ -m ec2 -a status` を実行し、Agentの状態を確認します。サービスマネージャーでも「Amazon CloudWatch Agent」サービスの状態を確認できます。
2. **Agentログの確認**:
   • **Windows**: Agentのログファイルは通常 `C:\ProgramData\Amazon\AmazonCloudWatchAgent\Logs\amazon-cloudwatch-agent.log` にあります。このログファイルに、起動エラーや設定ファイルのパースエラー、権限エラーなどの詳細な情報が記録されています。
3. **IAMロールとポリシーの再確認**: EC2インスタンスにアタッチされているIAMロールに、「AmazonSSMManagedInstanceCore」と「CloudWatchAgentServerPolicy」が正しく付与されているか、今一度確認してください。特に、誤ってポリシーが付与されていない別のロールがアタッチされているケースがあります。
4. **設定ファイルの構文チェック**: JSON形式の設定ファイルに構文エラーがないか、JSONバリデーターなどで確認します。ウィザードで生成した場合でも、手動で変更した際にエラーが入ることがあります。

これらの初動対応で、多くの場合、問題の原因を特定し、解決の糸口を見つけることができます。

ケース2: 想定したログがCloudWatch Logsに表示されない原因究明

メトリクスは上がっているものの、特定のアプリケーションログやWindowsイベントログがCloudWatch Logsに表示されない、というケースも発生します。この場合、ログ収集設定に問題がある可能性が高いです。

原因究明のためには、以下の点を重点的に確認します。

1. **ログファイルのパスと名前の確認**:
   • 設定ファイルで指定したログファイルのパス（例: `C:\inetpub\logs\LogFiles\W3SVC1\u_ex*.log`）が、インスタンス上の実際のログファイルの場所と正確に一致しているか確認します。ワイルドカードの使用方法も再確認が必要です。
   • Windowsイベントログの場合、`event_name`（Application, System, Securityなど）が正確に記述されているか確認します。
2. **ロググループ名の確認**: 設定ファイルで指定した`log_group_name`が、CloudWatch Logsコンソールで作成されているロググループ名と一致しているか確認します。誤字脱字がないか注意深く見ましょう。
3. **IAM権限の再確認**: CloudWatch Logsへの書き込み権限（`logs:CreateLogGroup`, `logs:PutLogEvents`など）がIAMロールに付与されているか再度確認します。
4. **Agentの再起動**: 設定ファイルを変更した後は、必ずAgentサービスを再起動しないと、新しい設定は適用されません。`amazon-cloudwatch-agent-ctl`コマンドで再起動を試みてください。
5. **ログレベルとフィルタリング設定**: 設定ファイルでログレベルを制限していたり、特定のキーワードでフィルタリングしている場合、想定外のログが収集されないことがあります。これらの設定が意図通りのものか確認します。

これらのチェック項目を一つずつ潰していくことで、ログが表示されない原因を特定し、解決に導くことができます。

Agentのトラブルシューティングから学ぶ運用のヒント

CloudWatch Agentのトラブルシューティングは、時に手間がかかる作業ですが、そこから得られる学びは今後の運用において非常に貴重です。問題解決のプロセスを通じて、CloudWatch Agentの内部動作、IAM権限管理の重要性、そしてログ管理のベストプラクティスを深く理解することができます。

今後の運用に役立つヒントをいくつかご紹介します。

1. **AWS公式ドキュメントの活用**: トラブルシューティングの際は、まずAWS公式ドキュメントを参照することを習慣にしましょう。最新の情報や、よくある問題とその解決策が網羅されています。
2. **テスト環境での十分な検証**: 本番環境に導入する前に、開発・ステージング環境でAgentの設定変更を十分にテストし、意図通りに動作することを確認します。これにより、本番環境でのリスクを最小限に抑えられます。
3. **段階的な設定変更**: 一度に多くの設定を変更するのではなく、小さな変更を加えてはテストするというプロセスを繰り返すことで、問題発生時の原因特定が容易になります。
4. **ログの重要性の理解**: Agent自身のログ (`amazon-cloudwatch-agent.log`) や、システムのイベントログは、トラブルシューティングの「宝庫」です。これらのログを定期的に確認し、異常がないか監視する習慣をつけましょう。
5. **コスト意識**: ログ収集量の増加はコストに直結します。定期的にCloudWatch Logsのデータ取り込み量やストレージを確認し、必要に応じてフィルタリングや保持期間の設定を見直しましょう。

これらのヒントを参考に、CloudWatch Agentをより堅牢かつ効率的に運用し、AWSインフラの健全性を高めていくことが可能です。

出典：AWS Documentation