CloudWatch Logs の新機能「自動インデックス」を試してみた
はじめに
2026年9月29日、Amazon CloudWatch Logs の自動インデックスが発表されました。
この記事では CloudTrail のログを CloudWatch Logs に出力し、クエリから自動インデックスが作成されるまでにかかる時間と、スキャン件数がどう変わるかを確認しました。
自動インデックスの対象と確認方法
Logs Insights の filter で = か IN を使ったフィールドに、自動インデックスが作成されます。追加コストなしで使えます。ロググループあたり20件というインデックスポリシーの上限とは別枠です。
自動インデックスは、最近のクエリに応じて入れ替わり、30日間保持されます。常にインデックスしておきたいフィールドは、フィールドインデックスのポリシーに追加します。
作成された自動インデックスは、DescribeFieldIndexes API で確認できます。CLI では、--index-categories に AUTO を指定します。
aws logs describe-field-indexes \
--log-group-identifiers "/cloudtrail/members-20261002" \
--index-categories AUTO
応答のうち、indexCategory が AUTO のものが自動インデックスです。
{
"fieldIndexes": [
{
"fieldIndexName": "sourceIPAddress",
"firstEventTime": 1791139845913,
"type": "FIELD_INDEX",
"indexCategory": "AUTO"
}
]
}
検証環境
CloudTrail の証跡を CloudWatch Logs のロググループに出力し、過去3日分（約16万件）のログが溜まった状態でクエリを実行しました。インデックスポリシーは設定していません。
クエリから自動インデックスが作成されるまで
CloudTrail では、= と IN の両方の書き方を試しました。例として、eventName で絞り込んだ2本を示します。
fields @timestamp, eventName, eventSource | filter eventName = "DescribeLogGroups" | limit 20
fields @timestamp, eventName, eventSource | filter eventName IN ["GetCallerIdentity","DescribeLogStreams","DescribeFlowLogs"] | limit 20
クエリの実行直後と、約25分後に、自動インデックスのフィールド一覧を取得しました。VPC フローログ（default VPC）でも、同様にクエリを実行しています。
| ロググループ | クエリで使ったフィールド | 実行直後 | 約25分後 |
|---|---|---|---|
| CloudTrail | eventName、eventSource、errorCode、readOnly | なし | 4件（すべて） |
| VPC フローログ | action、logStatus、flowDirection | なし | 3件（すべて） |
自動インデックスのフィールドは入れ替わる
awsRegion、eventType、sourceIPAddress、recipientAccountId を = で使ってから、これらの自動インデックスが作成されるまで、約15分かかりました。以下は、60秒間隔で記録した一覧のうち、フィールドが入れ替わった前後の4回分です。
2026-10-05 03:50:19 +0900 AUTO=[eventSource readOnly errorCode eventName]
2026-10-05 03:51:19 +0900 AUTO=[awsRegion eventName readOnly eventSource eventType]
2026-10-05 03:52:19 +0900 AUTO=[eventSource eventName eventType readOnly awsRegion]
2026-10-05 03:53:20 +0900 AUTO=[readOnly eventSource eventName recipientAccountId sourceIPAddress]
自動インデックスのフィールドは、今回の観測では最大5件でした。
スキャン件数はどう変わるか
sourceIPAddress は、自動インデックスの作成後に取り込まれたログだけがインデックスされています。インデックスされているログと、されていないログについて、recordsScanned を比べました。
インデックスされているログ（作成後に取り込まれた873件）
| フィールド | クエリ | recordsMatched | recordsScanned |
|---|---|---|---|
| sourceIPAddress（自動インデックスあり） | filter sourceIPAddress = "203.0.113.10" |
1 | 2 |
| eventID（計測時点で自動インデックスなし） | filter eventID = "<eventID>" |
1 | 873 |
自動インデックスがあるフィールドでは、スキャンは該当の1件を含む2件だけでした。ないフィールドでは、873件すべてがスキャンされました。
インデックスされていないログ（作成前に取り込まれた160,762件）
| クエリ | recordsMatched | recordsScanned |
|---|---|---|
filter sourceIPAddress = "203.0.113.10" |
1 | 160,762 |
filterIndex sourceIPAddress = "203.0.113.10" |
0 | 0 |
filter はインデックスされていないログを全件スキャンして該当の1件を見つけましたが、filterIndex はインデックスされたログだけを検索するため、該当は0件でした。このため、自動インデックスのフィールドには filterIndex ではなく filter を使うことが推奨されています。
まとめ
CloudWatch Logs Insights で = や IN を使って絞り込んだフィールドには、ポリシーを設定しなくても自動インデックス（AUTO）が作成され、クエリが効率化されることを確認できました。
特定条件を満たすログを、CloudWatch Logs Insights でフィルタ、集計するような場合、従来よりスキャン費用や所要時間を抑えられる効果が期待できます。
ただし自動インデックス（AUTO）の作成は非同期で、作成前のログは対象外です。また、作成後も置き換えで消える場合があります。置き換えによる取りこぼしを回避する必要がある場合、インデックスポリシーを利用することをおすすめします。
