本記事は 夏休みクラウド自由研究2026 8/20付の記事です。 |
2026年、CloudWatch Logsにはログをエンリッチする2つの機能として、Logs InsightsのlookupコマンドとLookupプロセッサが追加されました。今回は、それぞれの違いを整理し、エンリッチするタイミングや用途に応じた使い分けをハンズオンを交えて解説します。
はじめに
ログのエンリッチメントとは
例えば、VPC Flow Logsでは次のような形式でログが記録されます。
2 123456789012 eni-0a1b2c3d4e5f67890 10.0.1.15 203.0.113.10 49152 443 6 12 840 1787145600 1787145660 ACCEPT OK
このログからは送信元のIPアドレスが「10.0.1.15」であることが分かっても、このIPアドレスがどのシステムに所属するものかまでは判断がつきません。
IPアドレスとシステム情報を対応付けたテーブルを用いて情報の付加（エンリッチメント）を行うと、例えば次のように本番環境の決済システムからの通信であるとログから読み解けるようになります。
{
"interfaceId": "eni-0a1b2c3d4e5f67890",
"srcAddr": "10.0.1.15",
"dstAddr": "203.0.113.10",
"srcPort": 49152,
"dstPort": 443,
"protocol": 6,
"action": "ACCEPT",
"team": "payment",
"environment": "production",
"criticality": "high"
}
ログのエンリッチメントの重要性
AWS Well-Architected Frameworkのセキュリティの柱では、
- アラートを受け取って調査を担当するメンバーの認知負荷とコストを軽減する
- 追加のコンテキスト情報によって事象の真の深刻度を評価できる
という観点から、ログのエンリッチメントをベストプラクティスとして挙げています。ログとあわせてその意味まで確認できるようにすることで、担当者が別の情報源を参照する手間を減らせます。
エンリッチメントに関するCloudWatch新機能の比較
Lookup プロセッサ
Lookup プロセッサはCloudWatch Pipelineで利用できるプロセッサの一つとして2026年7月14日に発表されました。
対応関係を記述したテーブル（ルックアップテーブル）をCSV形式でアップロードすると、ログ取り込み時のパイプライン処理の中でログの属性とCSVを突き合わせ、一致した行の値をログイベントに追加します。
エンリッチされた状態でログが保存されるため後段で処理をしなくともコンテキスト情報を使うことが可能となります。
Logs Insights lookupコマンド
CloudWatch Logs Insights の lookup コマンドは、2026年3月31日に発表されました。
ルックアップテーブルを参照する点は Lookup プロセッサと変わらないのですが、ログのエンリッチメントは Logs Insights のクエリ実行時に行われます。このため、元のログには情報が付加されていないという点が異なります。
使い分けの基準
前述の通り、両者の最も大きな違いはエンリッチメントのタイミングが保存時かクエリ時か、という点にあります。このため、ルックアップテーブルで定義される属性と付加情報の対応関係がログの記録からクエリまでに変更され得る場合はエンリッチの結果に違いが出てきます。
このため、エンリッチメントにより参照したい情報として、ログが保存された時点の情報を使うならLookup プロセッサ、分析時点の最新の情報を使いたいなら Logs Insights lookup を選択する必要があります。
また、この違いはコストにも関わってきます。
Lookup プロセッサではエンリッチされたデータについても保存コストが発生するため、コストを抑えるにはルックアップテーブルで参照する情報は軽量にする必要があります。また、例えばアラート条件として使うなど、エンリッチした属性を頻繁に利用するケースに向きます。
一方、人間が調査に使うための説明文参照など、データ量多め、かつアドホックにエンリッチされたログを用いる場合は Logs Insights の lookup コマンドが適します。
ハンズオン
今回のハンズオンでは、ルックアップテーブルの内容を途中で変更し、同じログに対して両者のエンリッチ結果がどのように異なるか確認します。
Lookupプロセッサの動作確認
ip_address,hostname,owner,location 10.0.1.12,web-server-01,team-alpha,us-east-1 10.0.2.45,db-server-03,team-beta,us-west-2 10.0.3.78,cache-node-07,team-alpha,eu-west-1
CloudWatchパイプラインをセットアップし、以下のような設定で「network_assets」を参照する Lookupプロセッサを追加します。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| ログ側の照合フィールド | src_ip |
ルックアップテーブルとの照合に使用するログのフィールド |
| Lookup Table 側の照合列 | ip_address |
src_ip と照合するルックアップテーブルの列 |
| 取得する列 | owner |
一致した行から取得する値 |
| 出力先フィールド | owner_at_ingest |
取得した owner の値を格納するログのフィールド |
次に一つ目のログとして、以下を送信します。
{
"timestamp": "2026-05-04T12:00:00Z",
"src_ip": "10.0.2.45",
"action": "connection_opened",
"bytes": 2048
}
ログ取り込み時のLookupプロセッサの処理により、src_ipの値「10.0.2.45」を ルックアップテーブルのip_address と照合したときにマッチする行の owner の値「team-beta」がowner_at_ingest属性の値としてログに付加されました。
続いて、ルックアップテーブル「network_assets」を差し替え、10.0.2.45 に対応する owner を team-beta から team-database に変更します。ルックアップテーブルの更新後、同じ src_ip を持つ二つ目のログを送信します。
{
"timestamp": "2026-05-04T12:10:00Z",
"src_ip": "10.0.2.45",
"action": "connection_opened",
"bytes": 4096
}
変更後のログでは owner_at_ingest として team-database が追加されていることが確認できました。
Logs Insights の lookup と比較する
続いて、Logs Insights の lookup を使い、クエリ実行時のルックアップ結果と比較します。
次のクエリを実行し、ip_addressの値をnetwork_assetsのsrc_ipの値の中から探し、owner属性として表示します。
fields timestamp, src_ip, action, bytes, owner_at_ingest | lookup network_assets ip_address as src_ip OUTPUT owner | fields timestamp, src_ip, action, bytes, owner_at_ingest, owner | sort timestamp asc
結果、いずれのログでもowner列は差し替え後のルックアップテーブルで定義された対応関係に基づき「team-database」となっていることが確認できました。特に、一件目のログではLookupプロセッサによって付与された owner_at_ingest が変更前の「team-beta」のままとなっているのがわかります。
まとめ
本記事では、CloudWatch Logs における2つのログエンリッチメント手段であるLookupプロセッサと Logs Insights の lookupコマンドを比較しました。
ログのエンリッチメントでは、単に情報を追加できるかどうかではなく、「どの時点の情報が必要なのか」「どの程度の頻度でその情報を利用するのか」を考えることが重要になってきます。それぞれの特性を理解し、監視や調査の目的に応じて使い分けることで、必要なコンテキストを効率よくログ分析に取り込めます。
ここまでお読みいただきありがとうございました。本記事が両機能の理解の助けになれば幸いです。