2025年10月に、AWSから「CloudWatch AgentでWindows Event Logフィルターをサポート」というアップデートが発表されました。
CloudWatch Agent自体は以前からWindowsイベントログをCloudWatch Logsに送信できましたが、「どのイベントを送るか」を細かくコントロールできるようになったようです。
このアプデを見たとき、真っ先に「これはコスト削減に使えそうだな」と感じました。
CloudWatchエージェントからCloudWatch Logsへのデータ転送には料金はかかりませんが、収集されたログの保存・管理には料金が発生します。そして、その保管料金はS3と比べると高めです。
| サービス | 料金 | 備考 |
|---|---|---|
| S3 標準 | USD 0.025/GB | 最初の 50 TB/月 |
| CloudWatch Logs スタンダード | USD 0.76/GB |
2025年11月現在のS3料金とCloudWatch料金から
このように、同じ「ログをためる」でも、CloudWatch Logsは約30倍近い料金になります。
とりあえずすべてのイベントログを送ってしまうと、気づいた頃には「監視はできているけど、コストもすごいことになっている」という状態になりかねません。
そこで今回の記事では、Windows Event Logフィルター機能を使ってフィルタリングする設定を紹介します。
Event Logフィルター使ってみた。
■1. 設定ファイル配置
先日投稿した「SSM Run CommandでWindows Server 2025にCloudWatch Agentをインストール＆起動」の「●3-1. 設定ファイル配置」を参考に、以下の設定ファイルの配置を実施してください。
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "C:\\Users\\Administrator\\Desktop\\CWMetricsLogs\\*",
"log_group_name": "CWMetricsLogs",
"log_stream_name": "{instance_id}",
"retention_in_days": -1
}
]
},
"windows_events": {
"collect_list": [
{
"event_format": "xml",
"event_levels": [
"VERBOSE",
"INFORMATION",
"WARNING",
"ERROR",
"CRITICAL"
],
"event_name": "CloudWatchAgent",
"log_group_name": "CloudWatchAgent",
"log_stream_name": "{instance_id}",
"retention_in_days": -1
},
{
"event_name": "System",
"event_format": "xml",
"log_group_name": "Win-ServiceFailure",
"log_stream_name": "{instance_id}",
"retention_in_days": 30,
"event_levels": [
"ERROR",
"CRITICAL"
],
"filters": [
{
"type": "include",
"expression": "(Service Control Manager|service.*failed|service.*terminated unexpectedly)"
},
{
"type": "exclude",
"expression": "(DNS Client|Time-Service|NtpClient)"
}
]
},
{
"event_name": "Application",
"event_format": "xml",
"log_group_name": "Win-AppErrors",
"log_stream_name": "{instance_id}",
"retention_in_days": 30,
"event_levels": [
"ERROR",
"CRITICAL"
],
"filters": [
{
"type": "include",
"expression": "(Exception|Error|failed|timeout|ORA-|SQLSTATE|SqlException)"
},
{
"type": "exclude",
"expression": "(health ?check|heartbeat|test message)"
}
]
}
]
}
}
},
"metrics": {
"aggregation_dimensions": [
["InstanceId"]
],
"append_dimensions": {
"AutoScalingGroupName": "${aws:AutoScalingGroupName}",
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}"
},
"metrics_collected": {
"LogicalDisk": {
"measurement": ["% Free Space"],
"metrics_collection_interval": 30,
"resources": ["*"]
},
"Memory": {
"measurement": ["% Committed Bytes In Use"],
"metrics_collection_interval": 30
},
"Paging File": {
"measurement": ["% Usage"],
"metrics_collection_interval": 30,
"resources": ["*"]
},
"PhysicalDisk": {
"measurement": [
"% Disk Time",
"Disk Write Bytes/sec",
"Disk Read Bytes/sec",
"Disk Writes/sec",
"Disk Reads/sec"
],
"metrics_collection_interval": 30,
"resources": ["*"]
},
"Processor": {
"measurement": [
"% User Time",
"% Idle Time",
"% Interrupt Time"
],
"metrics_collection_interval": 30,
"resources": ["*"]
},
"TCPv4": {
"measurement": ["Connections Established"],
"metrics_collection_interval": 30
},
"TCPv6": {
"measurement": ["Connections Established"],
"metrics_collection_interval": 30
},
"statsd": {
"metrics_aggregation_interval": 60,
"metrics_collection_interval": 30,
"service_address": ":8125"
}
}
}
}
設定ファイル配置は以上です。
■2. 動作確認
設定ファイルが配置出来ましたら、イベントを手動で作成し、フィルターが効いているか確認します。
AWS Systems ManagerのRun Commandから対象サーバーにコマンドを実行します。
↓マネジメントコンソールから[ Systems Manager ]のダッシュボードに遷移します。
↓左のナビゲーションペインから、[ Run Command ]を選択し、[Run command (コマンドの実行)] をクリックします。
↓[ コマンドドキュメント ]のフォームに[ AWS-RunPowerShellScript ]を入力し、選択します。
AWS-RunPowerShellScript
↓[ コマンドのパラメータ ]に以下のコマンドを入力します。
# ①includeにもexcludeにもマッチしない（CloudWatch に来ない想定）
eventcreate /L APPLICATION /T INFORMATION /ID 901 /SO "CWAgentAppTest" /D "User clicked button on UI"
# ②includeにはマッチし、excludeにはマッチしない（CloudWatch に来る想定）
eventcreate /L APPLICATION /T ERROR /ID 902 /SO "CWAgentAppTest" /D "SqlException: timeout occurred while executing query"
# ③includeとexcludeの両方にマッチ（最終的に除外される想定）
eventcreate /L APPLICATION /T ERROR /ID 903 /SO "CWAgentAppTest" /D "SqlException: timeout during health check query"
# ④excludeパターンそのもの（これも除外される想定）
eventcreate /L APPLICATION /T ERROR /ID 904 /SO "CWAgentAppTest" /D "Error: this is a test message for application log"
↓[ ターゲット ]では今回作成したEC2インスタンスのみ指定したいため、[ インスタンスを手動で選択する ]を選択し、任意のEC2インスタンスを選択してください。
↓その他はデフォルトのまま、ページ最下部の[ 実行 ]をクリックします。
↓すぐにステータスが変わると思いますので、更新マークをクリックして、ステータスが[ 成功 ]に変わることを確認します。
ステータスが"成功"と出ているので、イベントが作成されたと思いますが、念のため確認します。
セッションマネージャーなどを利用し、サーバーに接続します。
↓以下のコマンドを実行し、901,902,903,904のイベントログが出ていることを確認しましょう。
Get-WinEvent -LogName Application -MaxEvents 50
PS C:\Windows\system32> Get-WinEvent -LogName Application -MaxEvents 50
ProviderName: CWAgentAppTest
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
11/29/2025 9:35:14 AM 904 Error Error: this is a test message for application log
11/29/2025 9:35:14 AM 903 Error SqlException: timeout during health check query
11/29/2025 9:35:14 AM 902 Error SqlException: timeout occurred while executing query
11/29/2025 9:35:14 AM 901 Information User clicked button on UI
↓作成されていることが確認できたので、[ Amazon CloudWatch Logs ]から、今回設定ファイルで指定したロググループ"Win-AppErrors"をクリックしましょう。
対象サーバーのインスタンスIDをクリックし、イベントログを作成した時間と同時間のログが収集されているか確認しましょう。
見てみると、09:35に一つだけログが出ており、イベントIDを見ると、想定した"902"のみ存在していることがわかります。
今回の検証は以上です。
まとめ
今回は、CloudWatch Agentの新機能であるWindows Event Logフィルターを使ってみました。Windowsサーバのイベントログは、そのまま全量を送ると「監視がつらい」・「コストもつらい」状態になるかもしれません。
今回のようにCloudWatch Agentのフィルター機能をうまく活用することで、いくつかメリットがありそうです。ぜひ試してみてください。
参考リンク:リリースノート
↓ほかの協栄情報メンバーのAWS Systems Managerについての記事を公開しています。ぜひ参考にしてみてください。
■AWS Systems Manager（SSM）を利用して、運用管理を楽にする インベントリ編(齊藤弘樹)
■AWS System ManagerのリモートデスクトップでPowerShellのキーボード入力が反映されない(ishihara.m)