【ITニュース解説】Automate CloudWatch Agent Setup on EC2 with Terraform and AWS SSM

システムを運用する上で、サーバーの状態を常に監視することは非常に重要だ。しかし、たくさんのサーバーがあったり、新しいサーバーが次々と追加されたりする場合、一台一台手作業で監視設定を行うのは大変な労力となり、設定ミスも発生しやすくなる。今回解説する記事では、この課題を解決するため、AWS（アマゾン ウェブ サービス）の主要なサービスであるEC2、CloudWatch、Systems Manager（SSM）をTerraformというツールと組み合わせて、監視エージェントのセットアップを自動化する方法について詳しく説明している。

まず、この自動化システムで中心となるサービスとツールについて簡単に説明する。AWS EC2は、インターネット上で利用できる仮想サーバーを提供するサービスだ。このEC2インスタンス上にアプリケーションを動かし、その稼働状況を監視する必要がある。AWS CloudWatchは、これらのサーバーやアプリケーションから様々な情報（ログやメトリクス）を集めて、分析し、可視化するための監視サービスだ。CloudWatchエージェントは、EC2インスタンス上で動作する小さなソフトウェアで、CPU使用率やメモリ使用率、ディスクI/Oといったシステムの状態を示す数値（メトリクス）や、システムが出力する記録（ログ）を収集し、CloudWatchに送信する役割を担う。そして、AWS Systems Manager（SSM）は、多数のEC2インスタンスを効率的に管理し、運用タスクを自動化するためのサービスだ。具体的には、サーバーにソフトウェアをインストールしたり、設定を適用したりといった作業を自動で行える。最後に、Terraformは、AWSのようなクラウドサービスのインフラ構成をコードとして記述し、自動的に作成・変更・削除できるツールだ。これにより、手動での作業をなくし、常に同じ状態でインフラを構築できるようになる。

今回紹介されている自動化の仕組みは、Terraformを使って、これらのAWSサービスや設定を一括で構築する。具体的には、以下のような要素がTerraformによって定義され、自動的にデプロイされる。

最初に作成されるのは、IAMロールとインスタンスプロファイルだ。IAMはAWSのリソースに対するアクセス権限を管理するサービスで、IAMロールは、AWSのサービスやユーザーに特定の権限を与える「役割」のようなものだ。EC2インスタンスがSSMを使って指示を受けたり、CloudWatchエージェントとして監視データをCloudWatchに送信したりするためには、これらの操作を許可する権限が必要だ。この自動化では、AmazonSSMManagedInstanceCoreとCloudWatchAgentServerPolicyという、SSMとCloudWatchエージェントの動作に必要な権限をまとめたAWSが提供するポリシーをIAMロールに付与する。そして、このIAMロールをEC2インスタンスが利用できるようにするための仕組みがインスタンスプロファイルとなる。これにより、EC2インスタンスは安全に必要な操作を行えるようになる。

次に、CloudWatchロググループが作成される。これは、監視対象のEC2インスタンスから送られてくるログデータを種類別に整理して保存する場所だ。Linuxサーバー用の/aws/ec2/var/log/messagesと、Windowsサーバー用の/aws/ec2/windows/logsという二つのロググループが作成され、それぞれでログが14日間保持されるように設定される。これにより、過去のログも確認でき、システムの問題発生時に原因を特定しやすくなる。

さらに、SSMパラメータという仕組みを使って、CloudWatchエージェントの具体的な設定内容が保存される。CloudWatchエージェントは、どのメトリクス（CPU、メモリ、ディスク、ネットワークなど）を収集し、どのログファイルを監視するかを記述した設定ファイルに基づいて動作する。この設定ファイルの内容を、JSON形式というデータ記述形式でSSMパラメータに保存しておくことで、SSMを使って各インスタンスに一元的に設定を配布できるようになる。Linux用とWindows用でそれぞれ異なる設定が用意され、それぞれのOSの特性に合わせた最適な監視が行える。

また、SSMの実行記録を保存するためのS3バケットも用意される。S3は、AWSが提供するオブジェクトストレージサービスで、様々なファイルを安全に保管できる。このバケットには、SSMがEC2インスタンスに対して行った操作のログが保存される。ログが古くなったら自動的に削除されるライフサイクルルールも設定されており、ストレージコストを最適化しつつ、必要な期間ログを保管できるようになっている。

そして、収集されたメトリクスを分かりやすく表示するためのCloudWatchダッシュボードも作成される。これは、CPU使用率、メモリ使用率、ディスク使用率などの重要な情報を一目で確認できるグラフや数値で表示する「監視画面」のようなものだ。これにより、サーバーの健康状態を素早く把握し、異常があればすぐに気づくことができる。

この自動化の最も重要な部分がSSMアソシエーションだ。これは、SSMに対して「特定の条件を満たすEC2インスタンスに対して、こんな作業を定期的に実行しなさい」という指示を出す仕組みだ。この記事では三つのSSMアソシエーションが作成される。 一つ目はinstall_cloudwatch_agentというアソシエーションで、cloudwatch=enabledというタグが付いているすべてのEC2インスタンスに対して、CloudWatchエージェントをインストールする。 二つ目はconfigure_cloudwatch_agent_linuxというアソシエーションで、cloudwatch=enabledかつos=Linuxというタグが付いたLinuxインスタンスに対し、SSMパラメータに保存しておいたLinux用のCloudWatchエージェント設定を適用する。 三つ目はconfigure_cloudwatch_agent_windowsというアソシエーションで、cloudwatch=enabledかつos=Windowsというタグが付いたWindowsインスタンスに対し、Windows用のCloudWatchエージェント設定を適用する。 これらのアソシエーションは、約30〜40分間隔で定期的に実行されるように設定されているため、新しいインスタンスが追加された場合でも、自動的にエージェントのインストールと設定が行われる。

この自動化システムを利用する手順は非常にシンプルだ。まず、監視したいEC2インスタンスに対して、cloudwatch=enabledというタグと、os=Linuxまたはos=Windowsというタグを付与する。次に、Terraformが作成したIAMインスタンスプロファイルをこれらのEC2インスタンスにアタッチする。これにより、インスタンスがSSMやCloudWatchと連携できるようになる。最後に、Terraformの設定ファイルをデプロイするだけで、IAMロール、ロググループ、SSMパラメータ、S3バケット、ダッシュボード、そしてSSMアソシエーションといったすべてのリソースがAWS上に自動で構築される。あとは、SSMが定期的にアソシエーションを実行し、CloudWatchエージェントのインストールと設定を自動で行い、作成されたCloudWatchダッシュボードで監視情報を確認するだけだ。

このアプローチの最大のメリットは、監視設定に関する手間を大幅に削減できる点にある。一台一台手動でエージェントをインストールしたり設定ファイルを編集したりする作業が不要になり、設定ミスも防げる。また、SSMパラメータを使うことで、すべてのインスタンスの監視設定を一元的に管理できるため、設定変更が必要になった場合でも、SSMパラメータを一度更新するだけで、すべての対象インスタンスに新しい設定が適用される。S3のライフサイクルポリシーによるログ管理は、不要になった古いログを自動で削除することで、ストレージコストを抑えることにも繋がる。さらに、LinuxとWindowsの両方のOSに対応しており、必要に応じて監視対象のインスタンスをタグ付けするだけで、簡単にシステムを拡張できる点も大きな利点だ。

このように、TerraformとAWS SSMを組み合わせることで、EC2インスタンスの監視環境構築を完全に自動化し、運用の手間を減らしつつ、信頼性の高いシステム監視を実現できる。これは、現代のクラウド環境におけるシステム管理の非常に効果的な手法であり、システムエンジニアを目指す上で理解しておくべき重要な考え方の一つだ。この自動化の設計図であるTerraformコードはGitHubリポジトリで公開されており、誰でも利用したり、必要に応じてカスタマイズしたりすることが可能である。