![[アップデート] CloudWatch でログの統合管理機能を利用できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-d6a3bc85cad6419960fbda152152cd8c/ba5841cea06b96f4933878762028b090/amazon-cloudwatch?w=3840&fm=webp)
[アップデート] CloudWatch でログの統合管理機能を利用できるようになりました
概要
CloudWatch のログ管理機能全般に大きくアップデートが入っていて簡潔にまとめ辛いのですが、下記複数の機能が追加されました。
- AWS マネージドな形での 3rd パーティーアプリケーションログの取り込み
- ログ種別の自動検出・分類
- CloudWatch マネージドでログスキーマ変換などのデータ処理を実現可能なパイプライン機能
- ファセットを利用した Logs Insights のクエリレスな分析
- AWS マネージドな S3 テーブル統合
- 組み込みのログ管理用ダッシュボード
ログを収集する所から、変換処理、分析まで全てのフェーズでアップデートが入っており、別サービスを触っているような使用感になっています。
以降、個別の機能を深堀りしながら紹介します。
What's New
AWS 公式ブログ
ログ種別の自動分類とデータソースの種別
今回、CloudWatch ログをデータソースとタイプ別に自動的に検出および分類することが可能になりました。
大きく分けると下記 3 種類のログが存在し、各分類の中で AWS サービスごとやサードパーティアプリケーションごとにさらに細かく分かれます。
- CloudWatch Logs に出力された AWS サービスのログ
- AWS マネージド統合を利用して連携した、サードパーティアプリケーションのログ
- CloudWatch Logs または S3 バケットに出力したカスタムログ
マネジメントコンソールの Ingestion から「Enable resource discovery」をクリックすることで、ログデータをデータソースとタイプ別に自動的に検出および分類することが可能になります。
この状態で対応している AWS サービスから CloudWatch にログを出力すると、データソースとして自動で検出されます。
VPC フローログと CloudTrail を CloudWatch ログ出力すると、自動で検出されて Data sources から確認できるようになりました。
パイプライン機能やファセットに依る分析はどうしてもログのスキーマを意識する必要があるため、ログの種類を識別した上で行うということですね。
パイプライン機能
パイプライン機能を利用することで、ログフォーマットの標準化や不要な情報のフィルタリング、追加のコンテキストによるデータの拡充などを行うことができます。
データソースの種類に依って適用できるプロセッサが決まっており、AWS のサービスやサードパーティアプリケーションなどから収集したログを Open Cybersecurity Schema Framework (OCSF) などの標準形式に変換するケースが主な使い方として紹介されています。
The pipeline processes and transforms data using a rich set of processors, converts data into standard formats like Open Cybersecurity Schema Framework (OCSF), and routes processed data to CloudWatch Logs.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-pipelines.html?trk=769a1a2b-8c19-4976-9c45-b6b1226c7d20&sc_channel=el
AWS サービスログの場合、CloudWatch パイプラインは CloudWatch Logs に取り込まれたログをインターセプトして処理します。
そのため、元々変換後のログ形式として出力されているような見え方をします。
When an AWS service source is selected, CloudWatch pipelines intercepts logs ingested into CloudWatch Logs for processing.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/data-sources.html
サードパーティアプリケーションログは統合先固有のセットアップを行うことで、ユーザー側で変換処理をすること無く、自動で OCSF 形式等にマッピング可能です。
対応しているサードパーティアプリケーションについては下記をご確認下さい。
例えば、Okta のシステムログを Security Lake に連携する際は変換用リソース (Data Firehose、Lambda) が必要でしたが、そういったリソースは不要で OCSF 形式に変換可能です。
その他、カスタムログに対して Grok プロセッサでパースするようなことも可能です。
今回は下記形式で出力した VPC フローログについて、パイプライン設定を行って OCSF 形式に変換してみます。
${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}
パイプライン設定はデータソースごとに行えば良く、ロググループごとに設定する必要はありません。
まず、Ingestion から「Create pipeline」をクリックします。
パイプライン名を入力します。
IAM ロールが必要なので新規作成します。
AWS サービスログの場合は送信先が元のロググループになるようなので、特に設定せず「次へ」をクリックします。
OCSF プロセッサを追加します。
バージョン (OCSF スキーマのバージョン) とマッピングバージョンをそれぞれ選択します。
現時点ではどちらも固定値です。
「パイプラインを作成」をクリックします。
上記設定を終えると、VPC フローログが、OCSF の Network Activity に準じたスキーマに変換されました。
{
"time": 1764705734000,
"time_dt": "2025-12-02 20:02:14.000000",
"start_time_dt": "2025-12-02 20:02:14.000000",
"end_time_dt": "2025-12-02 20:02:23.000000",
"metadata": {
"product": {
"version": "2",
"name": "Amazon VPC",
"feature": {
"name": "Flowlogs"
},
"vendor_name": "AWS"
},
"profiles": ["cloud", "security_control", "datetime"],
"version": "1.5.0"
},
"cloud": {
"account": {
"uid": "xxxxxxxxxxxx"
},
"provider": "AWS"
},
"src_endpoint": {
"port": 443,
"intermediate_ips": ["44.216.184.189"],
"ip": "44.216.184.189",
"interface_uid": "eni-01310f1519ac15c51",
"instance_uid": null,
"subnet_uid": null,
"vpc_uid": null,
"svc_name": "-"
},
"dst_endpoint": {
"port": 34070,
"intermediate_ips": ["10.0.130.240"],
"instance_uid": null,
"interface_uid": null,
"subnet_uid": null,
"vpc_uid": null,
"svc_name": "-"
},
"connection_info": {
"protocol_num": 6,
"boundary_id": 99,
"boundary": "-"
},
"traffic": {
"packets": 3,
"bytes": 180
},
"status_code": "OK",
"activity_name": "Traffic",
"activity_id": 6,
"action_id": 1,
"disposition": "Allowed",
"type_uid": 400106,
"type_name": "Network Activity: Traffic",
"action": "Allowed",
"category_name": "Network Activity",
"class_uid": 4001,
"class_name": "Network Activity",
"category_uid": 4,
"severity_id": 1,
"severity": "Informational",
"observables": [
{
"name": "dst_endpoint.intermediate_ips[]",
"type": "IP Address",
"type_id": 2,
"value": "10.0.130.240"
},
{
"name": "src_endpoint.ip",
"type": "IP Address",
"type_id": 2,
"value": "44.216.184.189"
}
],
"unmapped": null
}
このように変換しておくことで VPC フローログと Palo Alto Networks Next-Generation Firewalls などから連携してきたトラフィックログを同じように分析することが可能です。
AWS を中心に利用しつつ、他のログも集めてくるようなケースでは OCSF 形式に変換しておくと大きなメリットがあると思います。
ファセットを利用した Logs Insights のクエリレスな分析
Log Insights でクエリを構成しなくてもインタラクティブな分析が可能になりました。
チェックボックスをつけたり外したりすることで簡単にログを絞り込める機能であり、 Datadog などの SaaS でログを扱う際に利用したことがある方も多いのではないでしょうか。
こちらもデータの自動分類がベースにある機能で、ログの構造から自動的にファセットして利用できる属性が抽出されます。
Each facet shows available values and counts automatically extracted from fields in your logs based on the selected time range and query scope, and retained for 30 days.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs-Facets.html?trk=769a1a2b-8c19-4976-9c45-b6b1226c7d20&sc_channel=el
画面右側にファセットを表示できるようになっており、各属性の値にチェックを入れて「クエリの実行」をクリックすることで Logs Insights のクエリは変更せずにログを絞り込めます。
AWS マネージドな S3 テーブル統合
設定を完了することで、マネージドな S3 テーブルにログを連携することが可能です。
基本的には Logs Insights やファセット機能で簡単に分析しつつ、SQL を利用した高度な分析が必要になったら Athena で連携するような使い方になると思います。
S3 テーブルなので、もちろん Athena に限らず Apache Iceberg 互換のツールであれば分析可能です。
公式ドキュメントに記載されているユースケースとしては、複雑な SQL を実行したい際、既存の分析手法が存在する時、複数のデータソースを組み合わせた分析を行う時が挙げられていました。
・You need to run complex SQL-like queries across large volumes of log data
・You want to integrate log analysis with existing analytics workflows and tools
・You require comprehensive log analysis capabilities that span multiple data sources
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/s3-tables-integration.html?trk=769a1a2b-8c19-4976-9c45-b6b1226c7d20&sc_channel=el#3-tables-integration-when-to-use
アプリケーションログやセキュリティログなど多くのログを一元管理して横串で分析できるとこれまで以上に高度なインサイトを得られそうですね。
インテグレーション設定は Data sources 一覧に移動して、「S3 Table Integration > Manage Integration」から行うことが可能です。
「Create Integration」をクリックします。
権限設定を行う必要があるので、「Auto-create a new role with default permissions」を選択します。
「Create S3 Tables Integration」をクリックします。
続いて「Associate data source(s)」をクリックします。
VPC フローログを選択します。
AWS 管理のテーブルが作成され、確認できるようになりました。
ちなみに、S3 に連携した際のストレージ料金は無料です。
Customers can make their data available in managed Amazon S3 Tables at no additional storage charge
https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-cloudwatch-unified-management-analytics/
組み込みのログ管理用ダッシュボード
セキュリティログやアプリケーションログ、他 SaaS のログなどを広く取り込んで、一元的にログの取り込み量を管理するためのダッシュボードが追加されました。
パイプラインや S3 テーブル統合、ファセットの利用に料金はかからないので、コストを考える際はログの取り込み量や保存料金が支配的になるはずです。
組み込みダッシュボードを利用することで、ロググループごとのログ取り込み量を可視化したり、時系列変化を見ることが可能です。
CloudWatch ログの増加に依る課金増は調査が面倒なので、一元管理できるダッシュボードを用意してくれるとコスト管理が捗りますね！
最後に
CloudWatch ログに大量のアップデートが入りました。
特にファセットを利用した分析やパイプライン機能、S3 Table 統合は CloudWatch の可能性を大きく広げてくれるアップデートだと思います。
ログの取り込み料金や保存料金があるとはいえ、各機能が追加課金なしで利用できるというのも最高ですね。
CloudWatch をログ分析基盤として考えた際、Organizations 連携によるログの取得しやすさは大きなメリットです。
VPC Flow Logs の Organizations 連携
CloudTrail の組織ログ
また、下記アップデートでログの集中管理も圧倒的に行いやすくなりました。
そもそも AWS 周りのログを集めやすい特徴はあるので、CloudWatch を利用したログの一元管理は今後もっと広まってくるように感じました。
セキュリティログが中心の時に Security Lake とどう棲み分ければ良いかに関しては今後もう少し整理して比較ブログを書こうと思います。
