CloudWatchAgentを自動でEC2にインストールしてみた
2025.08.01【はじめに】
こんにちは。コンサルティング部の津谷です。
EC2複数台のマルチAZ構成をハンズオンや案件の中で手動構築した経験はありますでしょうか。アプリサーバやWebサーバを立てる場合まず、EC2を検討してみますよね。私もマルチAZ構成のEC2の状態を同期する作業を初期構築段階や運用時に経験したのですが結構面倒です。アプリコードだけではなく、環境変数やログの設定、MWやSWの設定、OSのシステム設定ファイル、監視エージェントの設定など数えればきりがありません。何か運用する際にこれらが変更となった場合の作業工数は侮れないでしょう。
今回はこれらの設定情報をAWSのマネージドサービスで格納して、一括配信するといった内容を実現してみます。1つずつ試すのは大変（お許しください）なので、今回はOSログ転送でマストなCloudWatchAgentを複数台のEC2に一括適用してみようと思います。
今回は新規で作成しますが、運用の際も格納情報を編集して一括反映するだけなので楽になりますね。設定情報の格納をPatameterStore、一括配信をSSM RunCommandでやってみたいと思います。各サービスの概要は下記に添付していますので是非見てください。
・Parameter Store
・SSM RunCommand
【構成図】
構成は以下になります。
構築リソースは下記です。
-
EC2
CloudWatchAgentを配布・起動するサーバとして使います。そのほかの設定はデフォルトでいいですが今回はエンドポイント経由でAWSリソースのAPIにアクセスするのでプライベートサブネットに置いておきましょう。
ネットワークの設定（RouteTable,NACL,SG)もエンドポイント経由(ポート443)で通信できるようにしておきましょう。今回はクイックスタートで起動できる標準Linux2023を利用します。
-
VPCEndpoint
下記のインターフェースエンドポイントを追加します。
【ssm】
SystemManagerの基本機能を利用するためのAPIにアクセスするために利用します。ParameterStoreの操作などが該当します。
【ssmmessage】
ユーザがEC2にアクセスするためのセッションを張ります。SessionManagerでの操作認可や、HTTPSからSSHへのポートフォワーディングなどが該当します。
【ec2message】
SystemManagerがEC2を認知するため必要です。またRunCommandはSystemManagerが実行するのではなくEC2が実行するので実行結果の送信なども含まれています。
【logs】
EC2がCloudWatchにOSログを格納するために利用します。
また、下記のゲートウェイエンドポイントを追加します。
【S3】
CloudWatchAgentのインストーラを取得します。
【補足】
CloudWatchAgentをインストールする際のパッケージは実はAWSが管理するパブリックのS3に保管されています。
そのため、内部経由アクセスでインストールする際はS3へのアクセス経路の確保が必要です。
こちらにダウンロードURLを記載してありますのでOSとアーキテクチャを見てダウンロードする場所を確認してみてください。 -
IAM
EC2がSSM、CloudWatchlogsにアクセスするための権限を指定します。付与する権限は以下とします。
検証なので、管理ポリシーで強めの権限を付けます。
・CloudWatchAgentServerPolicy
・AmazonSSMManagedInstanceCore -
ParameterStore
CloudWatchAgentで設定するConfigファイルの情報をパラメータとして格納します。
SSM Runcommandで実行する際に、ParameterStoreからデータを取り出します。 -
SSM RunCommand
CloudWatchAgentのインストール実行と設定反映・起動を行います。
既に、ドキュメントとしてパッケージ化されているのでそれをそのまま使います。
【構築手順】
前提として構成図のネットワークの部分（VPC,サブネット、Routetable,NACL,SG,Endpoint）
とEC2の作成までは完了させましょう。今回の手順はあくまで自動化の部分にフォーカスしますのでそこから手順説明をします。
①Parameter StoreにAgentファイルを保存するところから見てみます。
今回はシンプルなOSログを収集するConfigファイルを作成します。
名前は「/kensyou/CloudWatchAgent/config」にしました。
タイプは「文字列」を指定し、データ型は「text」で問題ありません。
値の部分に実際のConfigファイルの中身を記載します。今回は下記のように記載します。試しにLinux2023でセキュリティ監査ログとインスタンスOS初期設定時の動作ログを集めてみようと思います。ファイルパスの指定と、出力するロググループの指定、ストリームの指定を行います。（検証タイミングでロググループが「system」になっているのはご容赦ください。Cloud-init.logとSystemログでは情報は異なるので訂正させてください）
すべてのSystemログを一括で取得するのであれば、rsyslog（Linux2もこれ）をインストールしてmessageファイルに出力するか、Configファイル上で収集方法を「systemd journal」と指定するかになります。この場合はアプリケーションログなども含まれるので、厳密にログ種別を分けたい場合はファイルを分けて必要な情報だけ出力するとかしたほうがいいです。
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/audit/audit.log",
"log_group_name": "/aws/ec2/security",
"log_stream_name": "{instance_id}",
"timezone": "UTC"
},
{
"file_path": "/var/log/cloud-init.log",
"log_group_name": "/aws/ec2/system",
"log_stream_name": "{instance_id}",
"timezone": "UTC"
}
]
}
}
}
}
②Run Commandで実行します。
ドキュメントを基に2つ実行します。
- CloudWatchAgentをインストールする。
- Configファイルを適用する。
まずはCloudWatchAgentの一括インストールからいきます。SSMの「RunCommand」から実行設定を行います。
コマンドドキュメントは「AWS-ConfigureAWSPackage」を指定します。
コマンドのパラメータ設定ではActionが「Install」になっていることを確認しましょう。
ターゲットはCloudWatchAgentをインストールしたいインスタンスを指定します。
SSMへのIAM権限付与とエンドポイント経由での通信経路が確立されていないと出現しないので出てこない場合は確認しましょう。今回は「インスタンスを手動で選択する」を押下します。
コマンド出力をログとして吐き出すことも可能です。今回は実行成功したことが確認できればいいのでオフにしておきます。実行後にコマンド履歴を確認すると、下記のようにステータスが「成功」と出ていますね。
次に、CloudWatchAgentの設定ファイル（Config)の配布、起動までやっていきます。Run Commandからドキュメントを選択していきます。ドキュメントは「AmazonCloudWatch-ManageAgent」を指定します。
コマンドパラメータを確認します。
Actionは「configure」になっていることを確認します。
⇒これは、Configファイル設定を適用するためのアクションになります。
Modeは「ec2」になっていることを確認します。
⇒起動するサーバがEC2に立っていることを指します。（オンプレミスサーバとかも指定可能です）
Optional Configuration Sourceは「ssm」になっていることを確認します。
⇒設定情報を取得する場所としてSSM Parameter Storeを指定しています。
Optional Configuration Locationは実際の格納場所を指定します。
⇒ParameterStoreのパラメータ名として「/kensyou/CloudWatchAgent/config」を指定します。
Optional Restartは、Agentの設定を反映するために再起動を実施します。
⇒「yes」にしておきましょう。
Agentのインストール同様にインスタンスを指定します。
下記のように成功の履歴が表示されればOKです。
【動作確認】
CloudWatchAgentをインストールしたタイミングで正常に稼働しているか確認しました。
Statusコマンドを打つと、Activeになっていますね。
次にConfig設定を反映して再起動した後、ログが正常に出力されているか確認します。CloudWatchから確認してみます。
Securityログは無事出力されていますね。インスタンスIDはマスキングしていますが2台とも出力成功しています。
初期設定動作ログも確認してみます。こっちも正常にログ出力されていますね。
これで検証は完了なのですが、一応、Configファイル（JSON形式）がどこに格納されているかも確認してみました。（rsyslogの方も試したので、画像のConfigは検証用と少し異なり、パスはvar/log/配下のファイルを指定しています。）
下記のパスにJSONファイルが配置されてました。
opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/
【最後に】
お読みいただきありがとうございました。さきほども触れましたがLinux2の時とログ出力のルールが変わっているので調べてみました。こちらの公式ページに記載がありました。Linux2023ではテキスト型ログのrsyslogがデフォルトインストールされていないみたいです。/var/log/配下のディレクトリを指定できないので使いたい場合は別途インストールするしかないようです。または、systemd jornalでログを収集するかですね。もっぱらWindowsしか触ってこなかったので、新しいログ出力形式にも慣れていきたいですね。AWSは勉強すると、いろいろな予備知識が伝搬していって楽しいです。OSのこともこれから学んでいきたいと思います。
