CloudTrailログ検索の現在地：CloudTrail Lake後に見直す、目的別の検索導線

CloudTrailログ検索の現在地：CloudTrail Lake後に見直す、目的別の検索導線

CloudTrailログを検索する方法は、以前から複数存在します。直近の操作確認であれば Event History、CloudWatchに取り込んだログなら CloudWatch Logs Insights、S3の長期ログなら Athena、そしてマネージドな分析基盤としての CloudTrail Lakeなど、要件に合わせて使い分けるのが一般的でした。

しかし、このログ検索を取り巻く前提は、大きく変わりつつあります。
2026年5月31日をもって、AWS CloudTrail Lakeの新規提供が終了しました。公式ドキュメントでは代替機能としてCloudWatchが案内されていますが、実はCloudWatchは完全な互換品にはなりません。

そこで本記事では、単に代替サービスを1つ探すのではなく、現在の最新仕様を踏まえた上で、CloudTrailログの検索導線そのものを「目的別」にどう再設計すべきかを整理します。

1. 関連する近年のアップデート

以前からCloudTrailのログ検索の手段を検討したことがある方も多いと思いますが、ここ数年でAWSのログ収集や統合分析の選択肢は大きく変化しています。
過去の検討時の知識と、現在の最新仕様との間にあるギャップを把握した上で、最適な検索導線を考えられるよう、近年の主要なアップデートを振り返ります。

CloudTrail aggregated eventsは、データイベントを5分単位のサマリーに集約し、アクセス頻度・エラー率・よく使われるアクションを俯瞰できる機能です。S3バケットやLambda関数のように高頻度アクセスされるリソースが主なユースケースです。

2025年12月には、CloudWatch側からCloudTrailイベントを有効化し、VPC Flow LogsやEKS Control Plane Logsなどと並べて収集できる導線が追加されました。service-linked channelsを使ってCloudTrailからイベントを受け取るため、個別に証跡（Trail）を作成・管理しなくてよい構成も可能です。

Amazon CloudWatchはOCSF（Open Cybersecurity Schema Framework：セキュリティログの共通標準規格）やOpenTelemetryへの対応、S3 Tables経由でのAthena・Redshiftからの分析も提供するようになっています。

このように、近年の継続的なアップデートによって、CloudTrailログの収集および分析における柔軟性は格段に向上しました。しかし、選択肢や分析導線が多様化したからこそ、「自社の要件や運用体制において、どの方式を主軸に据えるべきか」という新たなサービス選定上の判断が求められています。
特に、公式が移行先として推奨するCloudWatchへの単純な置き換えだけでは、一部のイベント（Network Activity等）が取得できない、あるいはネストされたSQLが使えないといった技術的ギャップが存在する点です。

そこで次章では、これら最新の仕様変更と制約事項を踏まえた上で、2026年現在のクラウド運用において取るべき最適な検索導線を、目的別に整理・解説します。

2. 目的別のサービス選定ポイント

本章ではまず、目的別にどのサービス構成が最適なのか、選定の結論からまとめます。なお、各サービスの具体的な利用イメージや詳細な注意点については、次章（3章）にて詳しく解説します。

直近90日の管理イベントだけ見ればよいとき

→ Event History
設定不要で即使える入口として最適です。IAMの変更、EC2の起動・停止、S3バケット設定の変更など、管理イベント範囲での当たりをつけるのに向いています。

ただし、管理イベントのみ・単一アカウント・単一リージョン・属性フィルタ1つという制約があります。複雑な条件で絞り込みたい場合や、他ログと突き合わせたい場合は次の方法を選択する必要があります。

障害調査・運用調査で他ログと突き合わせるとき

→ CloudWatch Logs Insights
CloudWatch Logsにアプリケーションログ・VPC Flow Logs・EKSログがすでに入っているなら、CloudTrailイベントも同じ場所で検索できるとログの突き合わせがかなり楽になります。特定のAPI呼び出し前後で何が起きたかを時刻を合わせて追う、といった調査が容易です。

ただし、CloudWatchテレメトリ設定経由では、Network Activity EventsとInsights Eventsが対象外になる点には注意が必要です。

長期監査・低頻度の監査検索が主目的のとき

→ S3 + Athena
期間・アカウント・リージョン・API名・ユーザー・送信元IP・エラーコードを組み合わせた監査検索がSQL形式でできます。S3への長期保存・ライフサイクル管理との親和性も高いです。

Athenaはスキャン量課金のため、パーティション設計と検索範囲の絞り込みが費用を左右します。即時の障害調査はCloudWatch Logs Insightsに任せ、長期保存・低頻度の監査検索をS3 + Athenaで担う役割分担が現実的です。

CloudWatchに集約したログをAthena等でも分析したいとき

→ CloudWatch Logs + S3 Tables + Athena
Trail → S3 → Athenaとは別の導線です。CloudWatch Logsに取り込まれたログをS3 Tablesとして利用し、AthenaやRedshiftから参照できる構成です。

重要な注意点があります。S3 Tables側の保持期間はロググループの保持ポリシーと連動しており、ロググループやログストリームを削除するとS3 Tables側のデータも消えます。長期監査用のデータを独立して保存したいなら、Trail → S3 → Athenaを引き続き残す判断が必要です。

異常検知の仕組みが欲しいとき

→ CloudTrail Insights
API call rateやAPI error rateの通常パターンからの逸脱を検知する機能です。「普段よりAPI呼び出しが急増している」「エラー率が上がっている」といった変化に気づく入口になります。

検索機能ではないため、異常を検知した後の詳細調査はCloudWatch Logs InsightsやAthenaで別途行います。CloudTrail Lakeを使わない構成では、管理イベントInsightsはTrailで有効化します。なお、データイベントInsightsはTrailでのみサポートされます。

大量データイベントをいきなり個別検索する前に傾向を把握したいとき

→ CloudTrail aggregated events
高頻度なデータイベントを5分単位のサマリーで見られるため、アクセス頻度・エラー率・よく使われるアクションの傾向を把握してから詳細調査に入れます。

個別イベント検索の代替ではありません。詳細調査では元のCloudTrailイベントやCloudWatch Logs Insights・Athenaへのドリルダウンが必要になります。

既にCloudTrail Lakeを使っているとき

→ EDS（Event Data Store：CloudTrail Lakeのデータ保存場所）の構成を確認してから判断
下記を整理した上で、継続・移行を検討します。

• Organization EDSがあるか、Account EDSのみか
• 新規メンバーアカウントを追加する予定があるか
• 複雑なNested SQLを使っているか
• 2023年以前のデータを参照する必要があるか

Organization EDSがある場合、新規メンバーアカウントの追加やリージョン拡張も含めて継続利用できます。Account EDSのみの場合は、新規メンバーアカウントへの取り込みがサポートされないため、Organization EDSへの移行かCloudWatchへの移行を検討することになります。

3. 各方式の特徴と注意点

各方式の詳細な解説に入る前に、まずそれぞれの強みや前提条件を一覧表としてまとめました。

方式ごとのサマリ

3.1. Event History（イベント履歴）

概要

CloudTrailでデフォルト有効な機能で、過去90日間の管理イベントを表示・検索・ダウンロードできます。IAM変更・EC2操作・S3バケット設定変更など、管理イベント全般の当たりをつけるのに使いやすい入口です。

注意点

• 管理イベントのみが対象。データイベント・Insightsイベント・ネットワークアクティビティイベントは表示されない
• 単一アカウント・単一リージョンに限られる
• 属性フィルタは1つ＋時間範囲の組み合わせまで

コスト

直近90日の管理イベント閲覧は追加料金なし。

利用イメージ

AWSコンソールの「CloudTrail > イベント履歴」から、ルックアップ属性（例：イベント名 = DeleteBucket）と時間範囲を指定するだけで即座に検索できます。複雑な条件は使えませんが、例えば「誰がいつそのバケットを消したか」の第一報確認程度にはこれで十分です。複数フィルタを掛け合わせたいとき、あるいはデータイベントも含めて調査したいときはCloudWatch Logs InsightsかAthenaを選択するのが良いと思います。

3.2. CloudWatch Logs Insights

概要

CloudWatch Logsに取り込まれたCloudTrailイベントを、専用クエリ言語（Logs Insights QL）・SQL・OpenSearch PPLで検索・分析できます。他のCloudWatch Logsと同じ場所でCloudTrailイベントを扱えるため、アプリケーションログ・VPC Flow Logs・EKSログとの突き合わせが容易です。

注意点

• CloudWatchはCloudTrail Lakeの完全互換ではない

移行候補として案内されていますが、以下の差分があります。（参照元：CloudTrail Lake の可用性の変更 – AWS CloudTrail）

ただし、Insights Events（異常検知）に関しては、Trail構成であってもCloudWatch Logsへの転送は仕様上サポートされない（S3への出力のみ）点に留意してください。

※CloudWatch テレメトリ設定について

「1. 関連する近年のアップデート」の2025/12/05のアップデート『CloudTrailイベントをCloudWatchで有効化』が当該機能になります。（AWS が Amazon CloudWatch における AWS CloudTrail イベントの簡素化されたイネーブルメントをリリース – AWS）

“Amazon VPC フローログや Amazon EKS コントロールプレーンログなどの他の一般的な AWS ログソースとともに、CloudWatch の CloudTrail イベントの収集を一元的に設定できるように”なりました。

• クエリ結果は最大10,000件のため、大量監査では件数やページングを意識する必要があります。

コスト

CloudWatch Logsへの取り込み・保存・クエリスキャン量がコスト要因です。ログ取り込み・アーカイブ保存・Logs Insightsスキャン合計5GB/月の無料枠があります。

利用イメージ

/aws/cloudtrail ロググループを対象に、以下のようなクエリで調査できます。

• 特定ユーザーのAPI呼び出しを時系列で追う
  

  fields @timestamp, eventName, userIdentity.userName, sourceIPAddress, errorCode
  | filter userIdentity.userName = "alice"
  | sort @timestamp desc
  | limit 200
  

• eventName別の呼び出し回数を集計する
  

  fields eventName
  | stats count(*) as callCount by eventName
  | sort callCount desc
  | limit 30
  

• エラー発生APIを絞り込む
  

  fields @timestamp, eventName, errorCode, errorMessage, userIdentity.userName
  | filter ispresent(errorCode)
  | sort @timestamp desc
  | limit 100
  

VPC Flow Logsと突き合わせる場合は、@timestampを軸にしてログの時刻を合わせると調査が追いやすくなります。

3.3. S3 + Athena

概要

TrailでS3に書き出されたCloudTrailログファイルを、Athenaからパーティションテーブル経由でSQLクエリする構成です。期間・アカウント・リージョン・API名・ユーザー・送信元IP・エラーコードを組み合わせた監査検索が得意で、S3への長期保存・ライフサイクル管理との親和性も高いです。

注意点

• AthenaにはS3経由とS3 Tables経由の2つの導線があります。
  「Athenaで検索する」と一括りにすると、どこのログを検索しているかが曖昧になります。

コスト

スキャン量課金（1TBあたり5ドル）です。S3保存料金・リクエスト料金・Athenaクエリ結果保存も考慮が必要です。パーティションを適切に設計することでスキャン量を大幅に減らせます。

利用イメージ

• 特定期間・特定リージョンのS3削除操作を検索する
  sql
  

  SELECT
    eventtime,
    eventname,
    useridentity.userName AS user_name,
    requestparameters,
    sourceipaddress,
    errorcode
  FROM cloudtrail_logs
  WHERE
    year = '2026'
    AND month = '05'
    AND region = 'ap-northeast-1'
    AND eventname IN ('DeleteBucket', 'DeleteObject', 'DeleteObjects')
  ORDER BY eventtime DESC
  LIMIT 100;
  

• 特定IPアドレスからのAPI呼び出しを集計する
  sql
  

  SELECT
    eventname,
    COUNT(*) AS call_count,
    useridentity.userName AS user_name
  FROM cloudtrail_logs
  WHERE
    year = '2026'
    AND month = '05'
    AND sourceipaddress = '203.0.113.10'
  GROUP BY eventname, useridentity.userName
  ORDER BY call_count DESC;
  

  パーティション射影（Partition Projection）を有効にしておくと、MSCK REPAIR TABLE不要でパーティションを自動認識できます。長期運用ではユースケース次第で設定しておく価値があるかと思います。

3.4. CloudWatch Logs + S3 Tables + Athena

概要

CloudWatch Logsに取り込まれたログを、S3 Tables Integrationを通じてAthenaやRedshiftから参照できる構成です。CloudWatchをログ収集の入口にしつつ、SQLベースの高度な分析や他データとの相関分析にも展開できます。Trail → S3 → Athenaとは独立した別の導線です。

注意点

• S3 Tables Integrationは連携作成後に受信したログのみが対象です。既存ログはバックフィルされません。
• S3 Tables側の保持期間はロググループの保持ポリシーと連動します。ロググループやログストリームを削除するとS3 Tables側のデータも消えます。
• 長期監査用のデータを独立して保存したいなら、Trail → S3 → Athenaを引き続き残す判断が必要です。
• Trail → S3 → AthenaとCloudWatch Logs → S3 Tables → Athenaは目的と前提が異なる別構成です。「どちらでもAthenaで検索できる」という理解だけでは設計が混線します。

コスト

CloudWatch Logsへの取り込み・保存費用に加え、S3 Tablesの保存・リクエスト費用、Athenaのスキャン量課金がかかります。

利用イメージ

CloudWatchをログ収集の統合ハブにしている環境で、アプリケーションログ・EKSログ・CloudTrailイベントをまとめてCloudWatch Logsに収集し、Athenaでクロスサービスの相関クエリを実行する構成です。例えば、サービスのエラーログとCloudTrailのAPI呼び出しを時刻で結合し、障害発生前後のインフラ操作を一括調査するといったシナリオに向いています。

3.5. 既存のCloudTrail Lake利用者向け（補足）

Organization EDS / Account EDSの継続範囲

2026年5月31日以降の継続利用範囲は、EDSの構成によって異なります。

2023年以前のデータ移行制限

CloudTrail Lake → CloudWatch Importを使う場合、2023年以前のデータはCloudWatchへ移行されません。古いデータが必要な場合は、CloudTrail Lakeで直接クエリするか、S3へ移動する必要があります。

Nested SQLを使った複雑な監査クエリを組んでいる場合は、CloudWatchへの移行後にクエリが動かなくなる可能性があります。Nested SQLの利用有無を事前に棚卸しした上で移行判断を行うことを推奨します。

4. まとめ

CloudTrailログ検索の手段自体は新しくありません。整理の起点は2つです。CloudTrail Lakeが新規顧客向けに閉じたこと、そしてCloudWatch側でCloudTrailイベントの収集や統合分析が整備されてきたことです。

ただし、CloudWatchをCloudTrail Lakeの完全互換として扱うと選定基準や構成が歪む恐れがあります。Network Activity EventsとInsights EventsはCloudWatch Ingestion経由では取れず、Nested SQLも動きません。S3 Tables Integrationの保持期間はCloudWatch Logsのロググループ保持ポリシーと連動します。

今後のCloudTrailログ検索は、すべての目的を満たすフルセットを最初から一括で揃えるのではなく、運用の成熟度や必要性に応じて「まずは最小限から始めて段階的に拡張する」アプローチが現実的だと考えています。

例えば、「まずは過去90日間のイベント限定ですが追加コストがかからないEvent Historyのみで運用し、他ログとのクロス調査が必要になったらCloudWatch Logs Insightsを有効化する～」といったように、運用の変化に合わせて導線を後から足していく進め方が良いのではないでしょうか。