AWS環境で「誰が、いつ、何をしたか」を後から追えない状態は、監査やインシデント調査で大きなリスクになります。CloudTrailを有効にしていても、保存期間や確認方法が曖昧なままという方も多いのではないでしょうか。
本記事では、AWS CloudTrailのイベント履歴・証跡・CloudTrail Lakeの違いと、監査に使えるログ設計の要点を具体的にご紹介します。あわせて、CloudTrail Lakeの提供状況の変更にも触れます。

まず結論｜AWS CloudTrailは保存期間・範囲・権限を決めて運用する

AWS CloudTrailは、AWS環境の操作を記録する、監査・調査のためのサービスです。「とりあえず有効化」ではなく、設計して運用します。

CloudTrailイベント履歴では、過去90日間の操作を確認できます。90日より長く残す場合は、CloudTrail証跡（イベントを指定のS3バケットに継続的に配信する設定）でS3に保存します。判断の軸は、次の3点です。

• 保存期間：90日で足りるかを確認します
• 対象範囲：全アカウント・全リージョンを含めるかを決めます
• 権限：誰がログを見て、消せるかを決めます

AWS CloudTrailとは？監査ログとしての役割

AWS CloudTrail は、AWS 環境で「誰が・いつ・どこで・何をしたか」を把握するための監査ログサービスです。

主な目的は以下の通りです：

• ガバナンス：アカウント操作の可視化
• コンプライアンス：SOC、PCI、HIPAA などの規制対応
• セキュリティ監査：不正アクセスや異常な API コールの検出
• 運用監査：設定変更やリソース操作の追跡

CloudTrailは、ユーザーやAWSサービスが行ったアクションを、イベントとして記録します。

CloudTrailで記録できることとできないこと

CloudTrailが記録するのは、主にAWSのAPI呼び出しです。コンソールの操作も、API呼び出しとして記録されます。

• 記録できること：コンソール、CLI、SDKからの操作と、AWSサービスが代わりに行った操作
• 記録できないこと：サーバーのOS内の操作や、アプリケーションの内部ログなど、AWSのAPI呼び出し以外の動き

つまり、CloudTrailは「AWSアカウント内で誰が何を操作したか」の証跡です。サーバー内部の動きは、別のログで補います。CloudTrail監査では、この記録を根拠に操作を確認します。

CloudWatch LogsやAWS Configとの役割分担

CloudTrailと似たログとして、CloudWatch LogsとAWS Configがあります。

サービス	記録する内容	主な用途
CloudTrail	AWSへの操作（API呼び出し）	誰が何をしたかの証跡
CloudWatch Logs	アプリやサービスのログ。CloudTrailのイベントの送信先にもなる	監視、検索、アラーム
AWS Config	リソースの設定の変更と、ルールへの適合状況	設定の状態の確認

早期検知を担うGuardDutyやSecurity Hub CSPM（従来のAWS Security Hub）との関係は、「CloudTrailのログを検知と調査に生かす方法」で整理します。

CloudTrailで記録できるイベントの種類

CloudTrailのイベントは、種類によって記録の条件が違います。違いを知らないと、必要なログが残っていなかった、という事態になりかねません。

種類	内容	証跡での既定	主な用途
管理イベント	リソースの作成や変更などの管理操作	記録される	誰が設定を変えたかの追跡
データイベント	S3のオブジェクトなど、リソース内のデータ操作	記録されない	重要データへのアクセスの追跡
Insightsイベント	API呼び出し量やエラー率の異常	記録されない（追加料金）	異常な操作の把握

管理イベントの対象と典型例

管理イベントは、AWSリソースに対する管理操作の記録です。典型例は、IAMユーザーの作成、Security Groupの変更、EC2インスタンスの起動などです。

証跡は管理イベントを既定で記録し、読み取り専用、書き込み専用、すべてから選べます。イベント履歴で見られるのも、この管理イベントです。

データイベントの対象と注意点

データイベントは、リソースの中身に対する操作の記録です。たとえば、S3のオブジェクトの取得や、Lambda関数の実行です。

証跡では、データイベントは既定で記録されません。必要なものを選んで有効にします。

量が多くなりやすく、費用にも直結するため、詳しくは「データイベントによるコスト増を防ぐ」をご覧ください。対象は、機密性の高いデータを保管するバケットから優先して決めます。

Insightsイベントとグローバルサービスのイベント

Insightsイベント（CloudTrail Insights）は、API呼び出し量やエラー率の異常を検出して記録する機能です。通常のパターンから外れた動きを知らせます。既定では記録されず、追加料金がかかります。

グローバルサービスのイベントは、IAMのように、特定のリージョンに限らないサービスの操作です。複数リージョンの証跡を作ると、有効なすべてのリージョンの活動を取りこぼしにくくなります。

イベント履歴・証跡・CloudTrail Lakeの違い

CloudTrailには、記録を確認・保存する方法が3つあります。違いは、次のとおりです。

項目	イベント履歴	証跡	CloudTrail Lake
保存期間	過去90日	S3に任意の期間	設定した保持期間
対象イベント	管理イベントのみ	管理、データ、Insightsなど	管理、データ、Insights、Configなど
検索	1つの属性で絞り込み。アカウントとリージョンごと	S3のログをAthenaなどで検索	SQLで検索
費用	閲覧は無料	管理イベントの最初のコピーは無料。S3の保存料金は別	取り込み、保持、クエリで課金
新規の利用	可能	可能	2026年5月31日から不可

イベント履歴は過去90日間の確認に使う

イベント履歴は、アカウントを作成すると自動で使えます。コンソールから、過去90日間の管理イベントを、表示、検索、ダウンロードできます。

ただし、制約があります。1つの属性でしか絞り込めず、検索できるのは1つのアカウント、1つのリージョンの範囲です。また、データイベントは含まれません。

このため、90日を超える監査や、リージョンをまたぐ調査には向きません。イベント履歴は、直近の確認用と位置づけましょう。

証跡はS3へ継続保存する基本構成

証跡は、イベントを指定したS3バケットに配信する設定です。基本の構成は、次のとおりです。

• 複数リージョンの証跡（マルチリージョン証跡）を1つ作る
• 管理イベントを記録する
• 保存先は、専用のS3バケットにする
• 暗号化とログファイル整合性検証を有効にする

コンソールで作成した証跡は、すべて複数リージョンの証跡になります。管理イベントの最初のコピーは、無料でS3に配信できます。ただし、S3の保存料金は別にかかります。

証跡のログは、CloudWatch LogsやEventBridgeにも配信できます。

CloudTrail Lakeの位置づけと提供状況

CloudTrail Lakeは、イベントをまとめて保存し、SQLで検索・分析できる機能です。ただし、2026年5月31日から、新規のお客様には提供されていません。

公式情報によると、既存のお客様は、通常どおり利用できます。一方で、重大なバグ修正とセキュリティ更新のみが提供されます。AWSは、似た機能を持つサービスとして、Amazon CloudWatchを案内しています。

証跡、Insights、集計イベントは、この変更の影響を受けません。CloudTrail自体は、引き続き全面的にサポートされます。新規に検索・分析の環境を作る場合の主な選択肢は、次の2つです。

• 証跡とAmazon Athena：S3に保存した証跡のログを、SQLで検索する
• Amazon CloudWatch：CloudTrailのログを取り込み、検索・分析する

どれを選ぶか判断する比較軸

選び方は、保存期間、検索のしやすさ、費用の3つで考えます。ニーズ別の目安は、次のとおりです。

ニーズ	向く方法	備考
直近の操作を手早く確認したい	イベント履歴	90日、管理イベントのみ
監査のために長期間の記録を残したい	証跡（S3）	期間はS3のルールで決める
複数アカウントの記録をSQLで調べたい	証跡とAthena、またはCloudWatch	新規はLakeを使えない
すでにLakeを使っている	継続利用、または移行	新しいアカウントの扱いに注意

迷った場合は、まず証跡をS3に保存することから始めます。アカウント数が少なく調査の頻度も低ければ証跡とAthena、アカウントが多く日常的に分析するならCloudWatchなどの分析基盤も候補です。いずれも、PoCで検索のしやすさと費用を確認してから決めましょう。

監査・セキュリティ調査に使えるログ設計

監査に使えるログは、残すだけでは不十分です。取得範囲、保存方法、改ざん対策、権限の4点を、あらかじめ設計します。

複数アカウントと複数リージョンの取得範囲を決める

複数のリージョンを記録するには、複数リージョンの証跡を作ります。公式のベストプラクティスでも、有効なすべてのリージョンの活動を記録するために、推奨されています。これは、リージョンを限定すると、使っていないリージョンでの不正な操作を見逃すおそれがあるためです。

複数のアカウントがある場合は、AWS Organizationsの組織の証跡（Organization trail）が使えます。管理アカウントなどで作成すると、組織内のすべてのメンバーアカウントに自動で適用されます。メンバーアカウントは、この証跡を変更も削除もできません。

さらに、ログ保管専用のアカウントを作る構成が示されています。

取得するイベントの範囲は、アカウントの重要度で変える方法もあります。たとえば、本番は重要なデータへのデータイベントも記録し、開発は管理イベントを中心にして費用を抑えます。

S3への保存・暗号化・保管期間の設計

保存先は、専用のS3バケットにします。専用で集中管理するバケットに保存すると、アクセスの制御と職務の分離を厳格にできます。

暗号化には、SSE-KMS（AWS KMSの鍵によるサーバー側の暗号化）の利用が推奨されています。鍵を管理する人と、ログを読む人を分けると、安全性が高まります。

保管期間は、証跡の既定では無期限です。S3のライフサイクルルール（一定期間後にアーカイブや削除を行う設定）で、自社の要件に合わせます。具体的な年数は、社内規程や監査の要件から逆算してください。

ログの改ざん対策

ログは、改ざんされていないと示せて初めて、証跡として使えます。ログ保全の対策は、次の3つを組み合わせます。

• ログファイル整合性検証：配信後にログが変更・削除されていないかを確認できる
• MFA削除：S3のバージョン設定の変更や、オブジェクトの削除に追加の認証を求める
• S3 Object Lock：一定期間、オブジェクトの削除や上書きを防ぐ

ログファイル整合性検証は、標準的なアルゴリズムを使い、ログの変更や削除を検知できます。検証の結果を残しておくと、監査で改ざんがないことを問われた際の説明の根拠になります。

注意点として、MFA削除は、ライフサイクルの設定と併用できません。保管期間をライフサイクルで管理する場合は、他の方法も含めて検討します。

閲覧・削除・管理の権限を分ける

権限設計では、設定、閲覧、削除の3つに分け、保存先のS3バケットには最小権限の原則を適用します。設計の例は、次のとおりです。

• 設定する人：証跡の作成・変更だけを行います（管理者など少数に限ります）
• 閲覧する人：ログの読み取りだけを行います（監査担当者など）
• 削除：原則許可せず、必要な場合は承認を経て行います

とくに、AWSCloudTrail_FullAccessのポリシーは、監査機能を無効にしたり、再設定したりできます。適用は、管理者などごく少数に限りましょう。権限は、担当者の異動や退職のタイミングでも見直しましょう。

CloudTrailのログを検知と調査に生かす方法

CloudTrailは、事後に「何が起きたか」を正確に追うための記録です。異常に気づく「検知」は、別の仕組みと組み合わせ、役割を分けて設計します。両方がそろうと、気づきから原因の特定まで、つなげて対応できます。

重要な操作に気づくための通知の仕組み

CloudTrailのログは、CloudWatch LogsやEventBridgeに配信できます。CloudWatch Logsを使うと、証跡のイベントを監視し、アラートを受け取れます。たとえば、コンソールへのサインイン失敗です。

サービス	役割	活用の例
CloudWatch Logs	ログを監視し、条件に合うとアラームを出す	サインイン失敗の通知
Amazon EventBridge	イベントをきっかけに、通知や処理を起動する	重要な操作の通知
Amazon GuardDuty	不正な活動や異常を検知する	認証情報の不正利用の検知
AWS Security Hub CSPM	セキュリティ設定の評価と、検出結果の集約	CloudTrailの設定の評価

AWS Configの管理ルールで、証跡の設定そのものを点検する方法もあります。公式情報では、すべてのリージョンで記録しているか、CloudWatch Logsに送っているか、暗号化しているかを確認するルールが紹介されています。

通知する操作は、事前に決めておきます。たとえば、ルートユーザーの利用、証跡の停止や削除、権限の大きな変更です。宛先と、受けた後の動きもあわせて決めましょう。

誰が・いつ・何をしたかを調べる基本の流れ

インシデント対応では、確認する順番を決めておくと、迷いません。基本の流れは、次のとおりです。

1. 範囲を絞る：調査する期間、アカウント、リージョンを決める
2. 直近ならイベント履歴で確認する：90日以内の管理イベントは、手早く確認できる
3. 証跡のログを検索する：90日を超える場合やデータイベントは、S3のログをAthenaなどで検索する
4. 操作者を特定する：イベントのユーザー情報、時刻、送信元を確認する
5. 関連ログと突き合わせる：AWS Configの設定の履歴や、他のログと照らし合わせる

具体例で考えます。Security Groupが意図せず開放されていたことに気づいた場合、まず、変更が90日以内かを確認します。イベント履歴で、変更の操作者と時刻を特定し、その前後の操作を証跡のログで追います。

CloudTrail運用で注意すべき落とし穴

運用が始まってから気づく落とし穴を、3つ整理します。

記録されない場合と遅れる場合を確認する

「記録があるはずなのに、見つからない」という事態は、次のような設定が原因になりがちです。

• データイベントを有効にしていない：既定では記録されない
• 単一リージョンの証跡だけ：ほかのリージョンの操作が残らない
• イベント履歴だけを使っている：90日を超える記録や、管理イベント以外は確認できない
• 配信の遅れ：平均約5分で配信されるが、保証はない

証跡の設定が不適切だと、配信にも失敗します。S3バケットに到達できない場合、CloudTrailは30日間、再配信を試みます。この間の配信試行にも、標準の料金が適用されます。

SSE-KMSを使う場合は、KMSキーのポリシーでCloudTrailの利用を許可しておく必要があります。許可が足りないと、証跡の作成や配信に失敗します。また、キーを無効化・削除するとログを読めなくなるため、キーの管理担当と手順もあらかじめ決めておきます。KMSの利用料金も別にかかります。

データイベントによるコスト増を防ぐ

CloudTrail 料金は、使い方で大きく変わります。公式の料金ページでは、次のような課金の仕組みが示されています。

• イベント履歴：閲覧は無料
• 証跡：管理イベントの最初のコピーは無料。追加のコピーや、データイベントは課金される
• Insights：分析したイベントの数に応じて課金される
• CloudWatch Logsへの配信：CloudTrailの配信料金と、CloudWatch Logsの取り込み料金の両方がかかる

費用が増えやすいのは、データイベントです。アクセスの多いS3やLambdaを丸ごと対象にすると、イベント数が一気に増えます。対策は、記録する対象を絞ることです。これがコスト最適化の基本です。

高度なイベントセレクタを使うと、特定のAPI呼び出しだけを記録し、コストを制御できます。また、同じイベントを複数の証跡で記録すると、追加コピーとして課金されます。

証跡の重複も、定期的に確認しましょう。単価は更新されるため、AWS料金見積りツールで試算してください。

アカウントやリージョンの追加時のログ欠損を防ぐ

アカウントやリージョンが増えたときに、ログが欠けることがあります。原因は、新しい対象が、既存の証跡の範囲に入っていないことです。対策は、組織の証跡と、複数リージョンの証跡を使うことです。

CloudTrail Lakeの既存利用者は、とくに注意が必要です。公式情報によると、アカウント単位のイベントデータストアだけの場合、組織に追加した新しいアカウントのイベントは取り込まれません。新しいアカウントを取り込むには、組織のイベントデータストアを作成するか、CloudWatchへ移行する必要があります。

CloudWatchへの移行は、コンソールからのエクスポートで行えます。まず小さな範囲で試し、表示、クエリ、権限、費用を確認する進め方が推奨されています。

2023年より前のデータは移行されず、ネストしたSQLもCloudWatchでは使えません。クエリやダッシュボードが多い場合は、影響を整理したうえで、専門家へ相談する方法もあります。

導入前に確認したい設計チェックリスト

最低限有効化したい設定

• 複数リージョンの証跡を作り、管理イベントを記録している
• 専用のS3バケットに保存している（ログ保管用アカウントも検討する）
• SSE-KMSによる暗号化と、ログファイル整合性検証を有効にしている
• 重要なデータに、必要な範囲でデータイベントを有効にしている
• 複数アカウントの場合、組織の証跡を使っている

最初から完璧を目指す必要はありません。まず上記の5点を整え、通知と検索の仕組みを段階的に追加しましょう。

保存・検索・通知の確認項目と定期レビュー

観点	確認項目	レビューで見る点
保存	保管期間、ライフサイクル、バケットの権限	要件と一致しているか
検索	Athenaなどで、実際に検索できるか	調査時に使えるか
通知	重要な操作の通知、宛先、連絡経路	通知が届き、対応できているか
費用	データイベントの対象、証跡の重複	費用が想定内か
権限	閲覧、削除、管理の権限	不要な権限が増えていないか

AWS CloudTrailに関するよくある質問

Q1. イベント履歴だけで監査対応は十分ですか？

十分とは言えません。イベント履歴は、過去90日間の管理イベントのみです。永続的な記録ではありません。詳しくは「イベント履歴は過去90日間の確認に使う」をご覧ください。

Q2. CloudTrail Lakeは必ず必要ですか？

必須ではありません。2026年5月31日から、新規のお客様には提供されていません。検索・分析には、証跡とAthena、CloudWatchも選択肢です。詳しくは「CloudTrail Lakeの位置づけと提供状況」をご覧ください。

Q3. CloudTrailの料金が増える主な原因は何ですか？

主な原因は、データイベントの量です。ほかに、管理イベントの追加コピー、Insights、CloudWatch Logsへの配信も課金されます。詳しくは「データイベントによるコスト増を防ぐ」をご覧ください。

Q4. CloudTrailの設定で、最初に確認すべきことは何ですか？

複数リージョンの証跡が作られ、S3に保存されているかです。続いて、暗号化、ログファイル整合性検証、保存先の権限を確認します。詳しくは「最低限有効化したい設定」をご覧ください。

まとめ｜AWS CloudTrailは保存期間・範囲・権限を決めて運用する

AWS CloudTrailのイベント履歴は、過去90日間の確認用です。監査に使うには、複数リージョンの証跡をS3に保存し、暗号化、改ざん対策、権限の分離を設計する必要があります。CloudTrail Lakeは新規には提供されていないため、検索環境は、証跡とAthenaやCloudWatchも含めて検討します。

まずは、自社の証跡の設定、保管期間、データイベントの対象を確認してみてください。

テクノプロは、AWSアドバンストティアサービスパートナーとして、AWS認定資格3,000件以上の保有実績を持つ技術者集団です。ログの設計から運用の定着、CloudTrail Lakeからの移行判断まで、自社だけで進めにくい場合は、状況に合わせた3つの形でご支援します。

・請負・準委任：チーム体制で、現状のログ運用の診断から証跡と保存先の設計、検知・通知の整備、運用ルールの策定までを一括してお引き受けします。検索・分析基盤となるAthenaやCloudWatchの選定、CloudTrail Lakeからの移行についてもご相談いただけます。

・技術者派遣：AWSの監査ログ設計・運用の経験を持つ技術者がプロジェクトに参画し、自社チームの一員としてログ基盤の構築を推進します。マルチアカウント環境におけるログ集約など、必要な専門人材が不足している場面にも対応します。

・技術者教育：AWSトレーニングパートナーとして、ログの監査や調査の運用を自社で担うための人材育成を支援します（年間1,000人の育成実績）。

「どこまでログを残すべきか整理したい」「現状の証跡の設定が適切か診断してほしい」「監査に備えて保存期間と権限を見直したい」という段階でもご相談いただけます。
ぜひテクノプロまでお気軽にご相談ください。