CloudTrail 証跡でイベントを CloudWatch Logs に送信するように設定すると、CloudTrail は証跡設定に一致するイベントを CloudWatch Logs に送信します。
この記事では、CloudWatch Logs に送信されたイベントをメトリクスフィルタで調査することの実用性を検証し、また、メトリクスフィルタでの調査がどのようなユースケースで適しているか考えてみます。
検証理由
メトリクスフィルタでの調査に実用性があれば、無料で利用できるからです。
CloudWatch Logs で目的のログを探すなら、料金がかかるものの CloudWatch Logs Insight の利用が適していると思います。
一方、ログを分析する必要がなく 90 日より前の特定イベントだけ探したいという要望であれば、メトリクスフィルタでの検索もアリだと思い、今回試してみました。
先に結論
メトリクスフィルタでの調査は、検索期間の絞り込みができていて、ピンポイントに特定のイベントを確認したい場合に実用性はあると思います。
検索期間が長かったり、検索期間に一致するイベントが多くある場合は、メトリクスフィルタでの調査は実用性が低いと考えました。
理由としては以下が挙げられます。
- ある程度広い期間を指定して検索すると、検索時間がかかる
- 複数のログが一致した場合、一度に全て表示されない
- 全てのログを表示するには、検索結果の下部に表示される「さらにロード」をクリックする必要があり、そのロード時間も長い。ロードが終わって一致するイベントが増えても、また下部の「さらにロード」が表示される場合もあり、表示されなくなるまで続ける必要がある
CloudWatch Logs から検索する際の注意点
- CloudTrail から CloudWatch Logs に送信されないイベントがあります。
CloudWatch Logs と CloudWatch Events ごとに最大 256 KB のイベントサイズを許可する。ほとんどのサービスイベントの最大サイズは 256 KB ですが、一部のサービスにはまだこれより大きなイベントがあります。CloudTrail は、これらのイベントを CloudWatch Logs や CloudWatch Events に送信しません。
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html#send-cloudtrail-events-to-cloudwatch-logs-limitations
- マルチリージョン証跡の場合、全てのリージョンのログが含まれるので、特定のリージョンのみ検索したい場合は指定する必要があります。
- CloudWatch Logs で時間を指定する場合、ログイベントのタイムスタンプを基準とします。
「タイムスタンプ = イベントが発生した日時」ではないため、イベントが発生した日時を想定して時間を指定すると、本来検索したい対象のイベントが存在しない時間の可能性があります。
例: 1/1 23:59 にイベント A があり、1/2 00:01 が CloudWatch Logs でのタイムスタンプ。CloudWatch Logs で 1/1 を時間指定した場合、イベント A は結果として表示されない。
メトリクスフィルタでCloudTrailログを検索してみた
CloudTrail の CloudWatch Logs ロググループにはいくつかログストリームがあり、いずれかのログストリームにログが送信されます。

おそらくクォータに引っかからないように、いずれかのログストリームに送信される仕組みだと思いますが、詳細はわかりません。
1 秒、1 ログストリームあたり 5 リクエスト。追加のリクエストは調整されます。このクォータは変更できません。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html
番号が若いログストリームに古いイベントログがあるというわけではありませんので、全てのログストリームを対象に検索する必要があります。
そのため、「Search all log streams」からメトリクスフィルタで検索します。

大量のログがあるので、時間指定は必須です。
1日の全リージョンのエラーログを確認
まず1日の全リージョンエラーログを対象にしました(全てのエラーが以下のメトリクスフィルタで検索できるかは未確認です)。
{ $.errorCode = "*" }

結果は 1 秒に満たず表示されましたが、上記画像はすべての結果が表示されていません。
画像の下部に「ロードする新しいイベントがあります。さらにロードします。」と記載があるように、さらにロードすると結果が表示されます。
1日の東京リージョンのエラーログを確認
{ $.errorCode = "*" && $.awsRegion = "ap-northeast-1" }
結果は、上記「1日の全リージョンのエラーログを確認」と同様です。
1日の東京リージョンの読み込み専用でないイベントのエラーログを確認
{ $.errorCode = "*" && $.awsRegion = "ap-northeast-1" && $.readOnly IS FALSE}
10 秒程度で結果が表示されました。
1か月の東京リージョンの読み込み専用でないイベントのエラーログを確認
{ $.errorCode = "*" && $.awsRegion = "ap-northeast-1" && $.readOnly IS FALSE}

8 分経っても全ての結果は表示されませんでした。
上記画像は、下部に「ロードする新しいイベントがあります。さらにロードします。」が表示されていたので、「ロードします」をクリックした後の状況です。
指定した期間の若い日時から、一致するログがないか検索しているように見えます。
8 分経った時点で 10 日目のイベントまで検索されているようなので、指定した期間が広いと検索に時間がかかりそうです。
メトリクスフィルタでCloudTrailログを調査する具体的なユースケースを考えてみた
以下がメトリクスフィルタで調査するユースケースだと考えました。
- 効率度外視で絶対に無料で調査したい
- 90日より前のイベントで、検索をしたい対象イベントの日時が、数日程度に絞り込めている
- 90日以内のイベントだが、複数の条件で検索したい、かつ検索をしたい対象イベントの日時が、数日程度に絞り込めている
まず、検索対象のイベントの時間が絞り込めていない場合は、メトリクスフィルタは向いていません。11/3 に該当のイベントがある状態で、以下の期間を指定して同一条件で検索したところ、検索に以下時間がかかりました。
11/1 – 11/3(3日間) 数十秒程度
10/28 – 11/3(7日間) 3分間
10/21 – 11/3(14日間)10分間
そのため、検索対象のイベントの時間が数日程度に絞り込めている場合、メトリクスフィルタで検索してもある程度効率よく調査できるはずです(全ての一致したイベントが表示されたことを確認するには「ロードする新しいイベントがあります。さらにロードします。」の表示がないことを確認する)。
ただし、90 日以内のイベントであれば、基本的に CloudTrail イベント履歴から確認した方が早いです。
90 日以内でも複数の条件のもと検索したい場合はイベント履歴からはできないので、メトリクスフィルタでの検索も活用できるかもしれません。
90 日より前のイベントの場合は、CloudTrail イベント履歴からは確認できません。
そのため、S3 や CloudWatch Logs のログから確認することとなります。
基本的に S3 のログを解析するための Athena や CloudTrail Lake が既に準備されているのであれば、それらを利用して調査した方がいいでしょう。
何らかの理由で上記を利用できない・しない場合に CloudWatch Logs から検索することになりますが、最初に掲げたユースケース以外は、 CloudWatch Logs Insight を利用した方が効率的だと思います(料金はかかりますが)。