CloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説

AWSアカウントで誰がどのAPIを呼んだかを記録するのがCloudTrailです。コンソールから有効にするだけなら数分で終わりますが、実務で問われるのは「どこに何年ぶん貯めるか」「料金がどこから跳ねるか」の2点です。3種類のイベントの記録範囲、イベント履歴90日と証跡の違い、公式料金表の実額、2026年5月31日に始まるCloudTrail Lakeの新規受付終了とその後の構成判断までを、CLIの実行例つきで整理します。

まとめ：証跡1本目の無料枠とLake新規受付終了を前提にした設計の結論

先に結論を置きます。新規に監査ログ基盤を設計するなら、管理イベントの証跡を1本だけ全リージョン対象で作り、S3へ配信して分析はAthenaで行う構成が基本線。管理イベントの1コピー目はS3への配信が無料で、整合性検証も追加料金なしで有効にできるためです。

2026年に分岐がひとつ増えました。AWSはCloudTrail Lakeを2026年5月31日から新規顧客に提供しないと公式ドキュメントに明記しています。これから作る環境ではLakeを前提にできません。代替として案内されているのはAmazon CloudWatchです。

料金で事故が起きるのはデータイベントのほう。管理イベントは2本目の証跡から10万イベントあたり2.00ドル、データイベントは1本目から10万イベントあたり0.10ドルの課金対象になります。単価は小さく見えても、S3のオブジェクト操作やLambdaの実行はイベント数の桁が違います。全バケットを対象に有効化する前に、対象をリソース単位で絞る設計を先に決めてください。

CloudTrailが記録する3種のイベントとイベント履歴90日の範囲

何が記録され何が記録されないかを曖昧にしたまま有効化すると、調査のときに「ログがあるはずなのに無い」状態に行き当たります。

管理イベント・データイベント・ネットワークアクティビティイベントの3分類と既定の記録範囲

CloudTrailが扱うイベントは3種類。管理イベントは、リソースに対する制御操作の記録です。IAMロールの作成、EC2インスタンスの起動、セキュリティグループの変更などが該当し、コンソールへのサインイン（AwsConsoleSignIn）のようなAPI以外の操作も含みます。証跡を作れば既定で記録対象になります。

データイベントは、リソース内部のデータ操作です。S3オブジェクトのGetObject・PutObject、Lambda関数のInvokeが代表例で、既定では記録されません。明示的に有効化する設計判断が要ります。3つ目のネットワークアクティビティイベントはVPCエンドポイント経由のAPI呼び出しの記録で、これも既定オフ。

「誰がバケットを作ったか」は管理イベントで追え、「誰がそのバケットのファイルを読んだか」はデータイベントを事前に有効化していない限り追えません。インシデント対応で詰まるのは後者のほうです。

無料のイベント履歴90日と証跡のS3保存で変わる検索範囲と保持期限

イベント履歴は、証跡を作らなくてもコンソールから参照できる機能です。直近90日ぶんの管理イベントを無料で閲覧・検索・ダウンロードでき、90日を超えた分は消えます。

証跡（トレイル）はイベントをS3バケットへ継続配信する仕組みで、保持期限はCloudTrail側ではなくS3のライフサイクル設定で決まります。7年保持が求められる業界要件なら、Glacier Instant RetrievalやGlacier Deep Archiveへ移す設計になるでしょう。S3の料金をストレージクラス別に積算すると長期保管のコスト構造が見えます。

「CloudTrailは90日で消える」という理解のまま証跡を作っていないと、90日より前の調査ができません。逆に証跡だけ作ってライフサイクルを未設定にすると、標準ストレージのまま数年ぶんが積み上がります。

CloudTrailに記録されない操作と証跡だけでは追えない事象の範囲

CloudTrailはAWS APIの呼び出しと関連イベントを記録するサービスです。裏を返すと、AWS APIを経由しない操作は残りません。EC2インスタンスにSSHで入って実行したコマンド、RDS内部で発行されたSQL、コンテナ内のプロセス起動は対象外。加えてイベント配信には時間差があるため、リアルタイム検知の唯一の入力として設計すると期待どおりに動きません。

この境界を踏まえると、監査ログの構成は二層になります。AWSコントロールプレーンの操作はCloudTrail、OS・ミドルウェア・アプリケーションの動作はCloudWatch AgentやFluent Bitで収集する層です。両者をまとめて考える場合は、ログ集約の収集・転送・保存・可視化の各段を先に整理しておくと、どこをCloudTrailに任せるかの線引きが決まります。

証跡の作成手順とCLIでのマルチリージョン化・ログ整合性検証の設定例

IaCへ寄せやすいCLIの形で、実務で指定する項目を挙げます。

create-trailで最初に決める5オプションとマルチリージョン化の実行例

create-trailで必須なのは--nameと--s3-bucket-nameだけですが、実務では次の5つを最初に決めます。証跡名、配信先S3バケット、全リージョン対象にするか、整合性検証を有効にするか、KMSで暗号化するか。

aws cloudtrail create-trail \
  --name org-audit-trail \
  --s3-bucket-name my-audit-log-bucket \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id alias/cloudtrail-key

aws cloudtrail start-logging --name org-audit-trail

見落としやすいのが2行目のstart-loggingです。create-trailは証跡の器を作るだけで、これを実行しないとログ配信が始まりません。--is-multi-region-trailを付ければ、新しく有効化されたリージョンも自動で対象に入ります。リージョン単位で個別に証跡を作る運用は、追加漏れが起きるため避けてください。

ログファイル整合性検証とダイジェストファイルで改ざんを検出する手順

--enable-log-file-validationを付けると、CloudTrailは1時間ごとにダイジェストファイルをS3へ配信します。ダイジェストは直前のログファイル群のハッシュと、前のダイジェストへの参照を持つ連鎖構造。ログを1本差し替えればハッシュが合わなくなり、ダイジェストごと消せば連鎖が切れて検出されます。

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:ap-northeast-1:111111111111:trail/org-audit-trail \
  --start-time 2026-09-01T00:00:00Z \
  --region ap-northeast-1 \
  --verbose

validate-logsは--trail-arnと--start-timeが必須で、リージョン指定も要ります。検証できるのはダイジェストから参照されているログだけで、ローカルへダウンロードしたファイルは対象外。改ざんされていないことを監査で示す必要があるなら、証跡の作成時に有効化しておく前提で設計してください。後から付けても、それ以前の期間は検証できません。

組織証跡で全メンバーアカウント分を1本に集約するときの前提条件

アカウントが複数ある環境では、アカウントごとに証跡を作らず組織証跡を1本で回します。--is-organization-trailを付けて管理アカウント、または委任された管理者アカウントで作成すると、組織に属する全メンバーアカウントのイベントが1つのS3バケットへ集まり、後からメンバーアカウントが増えても自動で対象になります。

前提はAWS Organizationsで全機能が有効になっていること。一括請求のみの構成では組織証跡を作れません。Organizationsのアカウント構成とSCPの設計が固まらないうちに証跡だけ先に作ると、アカウント追加のたびに手作業が発生します。順序としては、組織構造を決め、組織証跡を1本作り、メンバー側の個別証跡は原則作らない、が実務的でしょう。なお組織証跡のログをvalidate-logsで検証するときは--account-idの指定が追加で要ります。

管理イベント2つ目以降とデータイベント課金が増える条件と公式料金表の実額

請求額が想定を超えるパターンは2つに絞られます。証跡を複数本作った場合と、データイベントを広く有効化した場合です。

管理イベント1本目無料・2本目以降10万件2.00ドルの積み上がり方

AWS公式の料金ページでは、管理イベントの最初のコピーをS3バケットへ配信する分が無料と示されています。課金が始まるのは2本目以降。単価は次のとおりで、いずれも10万イベントあたりの金額です。

2本目の証跡が生まれる典型は、セキュリティチームと開発チームが別々に証跡を作るケース。同じ管理イベントを2回配信すれば、2本目は全量が2.00ドル単価の対象になります。集約先を1本に決め、参照権限をIAMで分ければ避けられる重複です。

データイベント0.10ドルが跳ねるS3・Lambdaの記録条件と抑え方

データイベントの単価は管理イベントの20分の1ですが、件数が2桁3桁違います。アクセスの多いS3バケットで全オブジェクト操作を記録すると、1日で数千万イベントに達する構成も珍しくありません。10万件0.10ドルなら、月10億イベントで1,000ドルです。

抑え方は2段階。まず対象を全バケットではなく機密データを置くバケットへ限定し、次に高度なイベントセレクタでreadOnlyがfalseの操作（書き込み・削除）だけに絞ります。読み取りの記録が監査要件で求められていないなら、これだけで件数は大きく落ちます。有効化してから請求を見るのではなく、CloudWatchメトリクスのAllRequestsで対象バケットの月間リクエスト数を先に読んでから決めてください。

CloudTrail Lake新規受付終了2026年5月31日と移行先の判断

CloudTrail周辺で最も設計に影響する2026年の変更がこれです。既存の解説記事の多くは変更前に書かれている点を先に確認してください。

新規受付終了の対象範囲と組織EDS・アカウントEDSで異なる継続条件

AWSは公式ドキュメントで、CloudTrail Lakeを2026年5月31日から新規顧客に開放しないと明記しました。対象はLakeだけで、CloudTrail本体（証跡・Insights・集約イベント）は影響を受けず引き続き完全にサポートされると同じページに書かれています。「CloudTrailが終わる」と読まないでください。既存利用者がLakeで受けられるのは、重大なバグ修正とセキュリティ更新に限られます。

継続条件はイベントデータストア（EDS）の種類で分かれます。組織レベルのEDSがあれば、組織に追加される新規メンバーアカウントの取り込みもリージョン拡張も従来どおり。アカウントレベルのEDSしか持たない場合、既存アカウントとリージョン拡張は継続されるものの、組織に新しく追加されたアカウントのイベントは取り込まれません。この差は運用開始後に気づきにくく、新規アカウントのログだけが欠落する形で表面化します。

CloudWatchへの移行手順と2023年以前のデータが移らない制約

AWSが案内する移行先はAmazon CloudWatchです。LakeのEDSから履歴データを取り込むインポート機能があり、コンソールの「Export to CloudWatch」またはCLIから実行します。

aws logs create-import-task \
  --import-source-arn "arn:aws:cloudtrail:ap-northeast-1:111111111111:eventdatastore/EXAMPLE-eds-id" \
  --import-role-arn "arn:aws:iam::111111111111:role/CloudTrailLakeExportRole" \
  --import-filter '{"startEventTime": 1767225600, "endEventTime": 1767312000}'

制約が2つあります。ひとつは2023年より前のデータが移行対象外である点。それ以前のイベントが監査上必要なら、Lake側で照会し続けるかS3へ出しておく判断が要ります。もうひとつはコストで、インポートにはCloudWatchの取り込み課金が発生します。AWS自身がパイロット移行を推奨しており、まず24時間ぶんで取り込み量を測ってから全期間を流す順序が現実的でしょう。機能面では、CloudWatch側にOpenSearchベースの分析とApache Iceberg API経由のアクセスが加わる一方、Lakeが持っていた入れ子SQLには対応しません。既存クエリの移植可否も移行計画に織り込みます。

S3＋AthenaとCloudWatch Logsのどちらに証跡を流すかの判断軸

証跡の配信先はS3が必須で、CloudWatch Logsが任意です。両方に流せば課金経路も増えるため、用途から逆算して決めます。

Athenaのパーティション射影でスキャン量と料金を抑えるテーブル定義

S3に貯めたログを調べる標準的な手段がAthenaです。ここで効くのがパーティション射影で、日付パーティションを事前定義しておけば、新しい日付が増えてもALTER TABLE ADD PARTITIONを実行せずに済みます。テーブル定義の要点はTBLPROPERTIESの部分です。

TBLPROPERTIES (
  'projection.enabled'='true',
  'projection.timestamp.format'='yyyy/MM/dd',
  'projection.timestamp.interval'='1',
  'projection.timestamp.interval.unit'='DAYS',
  'projection.timestamp.range'='2026/01/01,NOW',
  'projection.timestamp.type'='date',
  'storage.location.template'='s3://my-audit-log-bucket/AWSLogs/111111111111/CloudTrail/ap-northeast-1/${timestamp}')

Athenaはスキャンしたデータ量で課金されるため、WHERE句にtimestampの範囲条件を入れるかどうかで請求額が変わります。数年ぶんのログを全走査するクエリを毎回投げる運用は、そのままコストになるということ。Athenaのスキャン量課金とパーティション設計による削減幅を把握したうえで、調査用クエリの型を決めておくと安定します。CloudTrailコンソールからテーブルを自動作成する導線もありますが、その場合は射影ではなく手動パーティションの定義になります。

CloudWatch Logsへ同時配信するときの二重課金と使い分けの基準

CloudWatch Logsへの配信は、メトリクスフィルタでアラームを鳴らしたいときに選びます。ルートアカウントのサインイン、IAMポリシーの変更、証跡そのものの停止といった「起きたらすぐ知りたい」操作の検知向けです。

判断軸は保持期間と用途。長期保管と網羅的な調査はS3とAthena、短期の検知とアラートはCloudWatch Logsという分担にして、後者の保持期間は30日から90日に切ります。両方へ全量を長期保存すると、S3の保管料とCloudWatch Logsの取り込み・保存料の二重払いになり、請求で膨らむのは取り込み課金のほうです。

証跡を有効にしただけで終わる失敗と検知・通知まで届かせる連携の設計判断

有効にしただけの状態は、誰も見ていない記録と同じ。見るきっかけを作る仕組みまで含めて設計します。

GuardDutyが管理イベントを入力にする関係と証跡との役割分担

Amazon GuardDutyは、CloudTrailの管理イベント、VPCフローログ、DNSクエリログを入力として脅威を検出します。押さえるべきは、GuardDutyが独自にCloudTrailのログを読むため証跡を作っていなくても検知は動く点。証跡は自分たちが調査・保管するために作るものです。

役割分担は明確です。GuardDutyは怪しい兆候を自動で挙げる側、CloudTrailの証跡は挙がった兆候の前後を人が追う側で、片方だけでは成立しません。併用するならGuardDutyの料金がイベント量とMalware Protectionでどう増えるかを先に確認しておくと、データイベントと合わせた監査コストの全体像が見えます。検出結果を一箇所に集めたい段階では、Security Hubで複数サービスの検出結果を統合する構成が次の手になります。

AWS Configとの守備範囲の違いと併用で埋まる調査の空白

CloudTrailとAWS Configは混同されがちですが、記録対象が違います。CloudTrailは「誰がいつ何のAPIを呼んだか」という操作の記録、AWS Configは「設定が時点ごとにどうなっていたか」という状態の記録です。

セキュリティグループが全開放されていた事故を例にすると、Configは「いつからいつまで0.0.0.0/0が開いていたか」に答え、CloudTrailは「それを開けたのは誰のどのAPI呼び出しか」に答えます。原因追及にはどちらも要ります。AWS Configの設定変更記録とルール評価の料金構造を踏まえると、Configは記録項目数での課金のため対象リソースタイプを絞るのが併用の前提。実務では、Configを本番アカウントの重要リソースに限定し、CloudTrailの管理イベントは全アカウント・全リージョンで1本、という非対称な形に落ち着きます。

受託開発の現場でCloudTrailを設計するときの採用条件と見送る場面

監査要件とマルチアカウント前提で証跡設計を先に固めるべき条件

次の条件に1つでも当てはまるなら、環境構築の初期段階で証跡設計を確定させてください。後から付け足す形では過去分が取り返せないためです。

• ISMSやPCI DSSなど、操作ログの保持期間が明文化された要件がある
• AWSアカウントが3つ以上あり、今後も増える見込みがある
• 本番環境に個人情報や決済情報を置く
• 運用を外部ベンダーと分担し、誰の操作かを後から区別する必要がある

最小構成は、組織証跡1本・全リージョン対象・整合性検証あり・ログ専用アカウントのS3バケットへ集約。バケットを別アカウントに置く理由は、本番の権限を取られてもログを消させないためです。後から移すのは面倒なので最初に決めます。

データイベントの全面有効化を見送るべき規模と代替の絞り込み方

見送る判断も明確にします。小規模な社内システムでS3のリクエストが月数千万件を超え、かつ監査要件でオブジェクト単位のアクセス記録を求められていないなら、データイベントの全面有効化は過剰。年間のCloudTrail費用がシステムの月額インフラ費を上回ります。読み取りの追跡が要るときだけ期間を区切って有効化する運用でも、多くの要件は満たせるでしょう。「全部記録しておけば安心」という設計は、費用と検索性の両方を悪化させます。

集約先アカウントの分離、組織証跡への移行、データイベントの絞り込みは、既存環境へ後から入れると影響範囲の確認に手間がかかります。すでに動いているAWS環境の監査ログ構成を見直す段階なら、AWSのインフラ構築・移行支援として現行構成の棚卸しから相談を受けています。

よくある質問

設計や運用でよく挙がる質問を5つ取り上げます。

CloudTrailは無料で使えますか？

一部は無料です。イベント履歴は直近90日ぶんの管理イベントを無料で閲覧・検索・ダウンロードでき、証跡を作る場合も管理イベントの最初のコピーをS3へ配信する分は無料。課金が発生するのは、2本目以降の証跡（10万イベントあたり2.00ドル）、データイベント（同0.10ドル）、ネットワークアクティビティイベント、Insightsです。配信先S3バケットのストレージ料金は別途かかります。

CloudTrailとCloudWatchは何が違いますか？

CloudTrailはAWS APIの呼び出し履歴を記録する監査ログ、CloudWatchはメトリクスとログを収集して監視するサービスです。「誰がEC2を停止したか」はCloudTrail、「そのCPU使用率がいくつだったか」はCloudWatchが答えます。証跡をCloudWatch Logsへ配信すれば、特定の操作を条件にしたアラームの設定が可能です。2026年5月31日以降はCloudTrail Lakeの代替としてもCloudWatchが案内されています。

証跡は複数リージョンで作る必要がありますか？

必要ありません。証跡作成時に全リージョン対象（--is-multi-region-trail）を指定すれば、1本で全リージョンのイベントが記録されます。新しく有効化されたリージョンも自動で記録の対象です。リージョンごとに個別の証跡を作ると、2本目以降が課金対象になるうえ追加漏れのリスクも増えます。

CloudTrail Lakeは今から使えますか？

2026年5月31日より前に登録していなければ使えません。AWSは公式ドキュメントで、同日からCloudTrail Lakeを新規顧客に開放しないと明記しています。既存利用者は継続できるものの、提供されるのは重大なバグ修正とセキュリティ更新のみ。これから設計するなら、S3とAthenaの組み合わせか、移行先として案内されているAmazon CloudWatchを選びます。CloudTrail本体（証跡・Insights）は影響を受けません。

CloudTrailのログはどのくらい保存されますか？

証跡を作った場合の保存期間は、CloudTrail側ではなく配信先S3バケットのライフサイクル設定で決まります。設定しなければ削除されず標準ストレージに残り続けます。証跡を作っていない場合はイベント履歴の90日が上限。監査要件で3年や7年の保持が求められるなら、S3ライフサイクルでGlacier系のストレージクラスへ移行させる設計にします。

関連記事

• AWS Configとは？設定変更の記録・ルール評価・料金の実額と導入判断：併用時の守備範囲の切り分けに。
• Amazon GuardDutyの料金：東京リージョンの実額とMalware Protectionの追加課金：管理イベントを入力にする脅威検知の費用構造。
• Amazon Athenaの料金：スキャン量課金の実額とパーティション設計での削減：証跡を調べるクエリ費用の見積もりに。
• AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組み：組織証跡の前提となる構成設計。
• ログ集約とは？収集・転送・保存・可視化の仕組みとエージェント選定：CloudTrailで追えないOS・アプリ層の収集。