概要
「誰が・いつ・どのAPIを呼んだか」を残しておきたい、という要件はほぼすべての監査で出てきます。AWSではCloudTrailがそれを記録しますが、コンソールで見られるイベント履歴は過去90日ぶんだけです。「1年前の操作を調べたい」「6か月を過ぎたログはアーカイブしたい」という要件には、これだけでは足りません。
長期保存の答えは証跡（Trail）をS3バケットに出力し、S3のライフサイクルルールでアーカイブする構成です。CloudTrailは記録に徹し、保存期間とコストの管理はS3側の仕組みに任せます。
この記事では、イベント履歴と証跡の違いを整理したうえで、ログファイル検証を有効にした証跡を作り、一定期間を過ぎたログをGlacier Deep Archiveへ移すライフサイクルルールを設定します。
クラウドおさるログファイル検証付きの証跡を作り、S3に出たログを180日でGlacier Deep Archiveへ寝かせる設定まで、一緒に確かめるでござる。記録はCloudTrail、保存期間とコストはS3に任せる、という役割分担が今日の軸でござるな。
この記事のメリット
- イベント履歴と証跡の違いを、保存期間・対象イベント・料金の観点で区別できるようになる
- 長期保存に「CloudWatch Logsだけ」「直接Glacier」を選ばない理由を説明できるようになる
- S3ライフサイクルによる移行と、ストレージクラスごとの最低保存期間を把握できる
- ログファイル検証で改ざんを検出できる仕組みを理解できる
- SCS試験で監査ログの保存・アーカイブ設計を問う設問に答えられるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
イベント履歴と証跡
CloudTrailのコンソールで見える「イベント履歴」と、自分で作る「証跡」は別物です。
| 観点 | イベント履歴 | 証跡（Trail） |
|---|---|---|
| 保存期間 | 過去90日 | S3に置き続ける限り無期限 |
| 対象イベント | 管理イベントのみ（データイベント・Insightsイベントは含まない） | 管理イベント・データイベント・Insightsイベントを選べる |
| 範囲 | 単一リージョン・単一アカウント | 全リージョン・組織全体をまとめられる |
| 検索 | 属性フィルター1つと時間範囲のみ | S3に出力したログをAthena等で自由に検索できる |
| 料金 | 閲覧は無料 | 管理イベントの最初のコピーは無料。2つ目以降は配信10万件あたり 2.00 USD |
イベント履歴は証跡とは独立していて、証跡を消してもイベント履歴には影響しません。逆に言うと、証跡を作っていなければ90日を過ぎた操作は追えなくなります。
「すべてのアカウントでAPIコールを記録して長期保存する」という要件では、まず全アカウントで証跡を有効にし、S3バケットに集約するのが基本形です。
クラウドおさるイベント履歴で見えるのは過去90日ぶん、しかも管理イベントだけでござる。証跡を作っていなければ、90日を過ぎた操作はもう追えないのでござるぞ。
なぜS3に出すのか
長期保存の選択肢として、次の3つが設問によく並びます。
| 選択肢 | 評価 |
|---|---|
| 証跡をS3に出し、ライフサイクルでアーカイブする | これが基本形。保存コストが低く、段階的なアーカイブができる |
| CloudWatch Logsに送って保持期間を設定する | リアルタイムのアラートには向くが、保存単価が高く長期保存には向かない |
| 直接S3 Glacierに保存する | CloudTrailの配信先はS3の標準的なバケット。段階的な移行ができず柔軟性に欠ける |
CloudWatch Logsへの送信は「特定のAPIコールを検知して通知する」目的なら有効です。ただし料金体系が保存量に対して高いため、監査のための長期保存はS3、検知はCloudWatch Logsと役割を分けます。両方を同時に使うこともできます。
S3ライフサイクルによるアーカイブ
ライフサイクルルールは「オブジェクトの作成から N 日経ったらストレージクラスを移す」「M 日経ったら削除する」というルールです。監査ログは「直近は検索したい、古いものは置いておくだけ」という性質なので、段階的に移すのが向いています。
ストレージクラスには最低保存期間があり、その前に移動・削除すると残り期間ぶんが課金されます。
| ストレージクラス | 最低保存期間 | 取り出し |
|---|---|---|
| S3 Glacier Instant Retrieval | 90日 | ミリ秒 |
| S3 Glacier Flexible Retrieval | 90日 | 数分〜数時間 |
| S3 Glacier Deep Archive | 180日 | 12時間程度 |
移行できる方向にも制約があります。
- S3 Glacier Deep Archiveから他のストレージクラスへは、ライフサイクルルールで戻せません
- S3 Glacier Flexible Retrievalから移行できるのは、S3 Glacier Deep Archiveだけです
- 128KB未満のオブジェクトは、既定ではどのストレージクラスにも移行されません
「6か月を過ぎたらアーカイブする」という要件なら、180日でGlacier Deep Archiveへ移すルールが素直な実装になります。
ログファイル検証
証跡にはログファイル検証というオプションがあります。有効にすると、CloudTrailはログファイルのハッシュを含むダイジェストファイルを1時間ごとにS3へ出力し、そのダイジェストに署名します。
| 仕組み | 内容 |
|---|---|
| ダイジェストファイル | 直前の1時間に配信したログファイルのハッシュを含む。CloudTrail-Digest プレフィックスに出力される |
| 署名 | ダイジェストファイルは秘密鍵で署名され、公開鍵で検証できる |
| 検証コマンド | aws cloudtrail validate-logs --trail-arn <ARN> --start-time <日時> |
これにより、ログファイルが配信後に変更・削除されていないことを証明できます。監査要件がある環境では、証跡の作成時に必ず有効にします。あわせて、出力先バケットにバージョニングやObject Lockを掛けると、削除そのものを防げます。
クラウドおさるログファイル検証が証明するのは、配信後にログが変更・削除されていないことでござる。猿山の帳簿に長老会の判を押しておけば書き換えはばれるでござるが、帳簿ごと持ち去る猿を止めるのは別の錠前、つまりバージョニングやObject Lockの役目でござるな。
保存先バケットの守り方
| 対策 | 目的 |
|---|---|
バケットポリシーで s3:DeleteObject を絞る | ログの削除を防ぐ |
| S3 Object Lock（コンプライアンスモード） | 保持期間中は誰も消せない状態にする |
| SSE-KMSで暗号化 | 保管時の暗号化。キーポリシーで復号できる人を絞れる |
| ログファイル検証 | 改ざんの検出 |
「記録する」「消させない」「改ざんを検出する」は別々の仕組みです。設問ではこの3つが混ぜて問われるので、対応関係で覚えます。
実践
ログファイル検証を有効にした証跡を作成し、S3に出力されたログを確認したうえで、180日でGlacier Deep Archiveへ移行するライフサイクルルールを設定します。
前提条件
- リージョン:
ap-northeast-1（東京） - CloudTrail・S3の操作権限を持つIAMユーザーまたはロールでコンソールにログイン済みであること
このハンズオンで作成するリソースは以下のとおりです。
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| CloudTrailの証跡 | audit-trail-lab | API操作ログの記録用 |
| S3バケット | audit-trail-lab-<アカウントID> | ログの出力先 |
| ライフサイクルルール | archive-after-180-days | 180日でGlacier Deep Archiveへ移行 |
管理イベントの最初のコピーは無料ですが、同じアカウントで2つ目以降の証跡を作ると、管理イベントの配信が10万件あたり 2.00 USD の課金対象になります。既に証跡が有効なアカウントで試す場合は、検証後に作成した証跡を削除します。
手順1: 証跡を作成する
AWSマネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに CloudTrail と入力し、表示された「CloudTrail」を選択します。
左側ナビゲーションの「証跡」を選択し、「証跡の作成」をクリックします。
以下を設定します。
- 証跡名:
audit-trail-lab - ストレージの場所:
新しい S3 バケットを作成します - 証跡ログバケット名:
audit-trail-lab-<アカウントID> - ログファイルの SSE-KMS 暗号化: チェックを外す（この検証では既定の暗号化のまま進めます）
- ログファイルの検証:
有効
画面に「コンソールで作成された証跡は、マルチリージョンの証跡です」と表示されます。コンソールから作る証跡は常に全リージョンが対象で、単一リージョンの証跡にしたい場合はCLIまたはAPIで作成します。
「次へ」をクリックします。
手順2: 記録するイベントを選ぶ
「イベントタイプ」で「管理イベント」にチェックが入っていることを確認します。API アクティビティは「読み取り」「書き込み」の両方を選択します。
データイベント・Insightsイベント・ネットワークアクティビティイベントはチェックを入れません（いずれも課金対象のため）。
すでに管理イベントを記録する証跡があるアカウントでは、「複数の管理イベント証跡が検出されました。ログに記録された管理イベントが重複している場合は料金が発生します」という案内がこの画面に表示されます。
「次へ」→「証跡の作成」をクリックします。
手順3: ログが出力されることを確認する
証跡が作成されると、CloudTrailはおよそ5分ごとにログファイルをS3へ配信します。配信までしばらく時間がかかります。
S3コンソールで audit-trail-lab-<アカウントID> バケットを開きます。AWSLogs/<アカウントID>/CloudTrail/ap-northeast-1/<年>/<月>/<日>/ の階層にログファイル（.json.gz）が出力されていることを確認します。
マルチリージョンの証跡なので、CloudTrail/ の下にはリージョンごとのフォルダが並びます。グローバルサービスのイベントは us-east-1 の下に出力されるため、東京リージョンで操作していなくてもファイルが増えていきます。
同じ階層構造で CloudTrail-Digest の下にダイジェストファイルが出力されます。これがログファイル検証で使われるファイルです。
手順4: ライフサイクルルールを作成する
S3コンソールでバケットの「管理」タブを開き、「ライフサイクルルールを作成する」をクリックします。
以下を設定します。
- ライフサイクルルール名:
archive-after-180-days - ルールスコープ:
バケット内のすべてのオブジェクトに適用 - ライフサイクルルールのアクション:
ストレージクラス間でオブジェクトの現行バージョンを移行するにチェック
チェックを入れると確認のチェックボックスが現れるので、「このルールがバケット内のすべてのオブジェクトに適用されることを了承します」にチェックを入れます。
移行の設定で以下を指定します。
- ストレージクラスの移行を選択:
Glacier Deep Archive - オブジェクト作成後の日数:
180
「移行についてはリクエストごとに課金されます」の下にある「私は、このライフサイクルルールでは、リクエストごとに移行コストが発生することを了承します。」にもチェックを入れます。この2つにチェックを入れないと「ルールの作成」で先に進めません。
「ルールの作成」をクリックします。
手順5: ルールが有効になったことを確認する
「管理」タブのライフサイクルルール一覧で、archive-after-180-days のステータスが Enabled になっていることを確認します（この列だけ英語のまま表示されます）。「最新バージョンのアクション」に Glacier Deep Archive と出ていれば、移行先が正しく設定されています。ルールを開くと、移行のタイミングも確認できます。
ライフサイクルによる移行は日次で評価され、指定日数を過ぎたオブジェクトが順次移行されます。作成直後に結果を確認することはできません。Glacier Deep Archiveは最低保存期間が180日のため、移行後すぐに削除すると残り期間ぶんが課金されます。
クラウドおさるライフサイクルの移行は日次で評価されるので、作成直後に結果は見えぬでござる。Glacier Deep Archiveは最低保存期間が180日、移してすぐ消すと残り期間ぶんのバナナが飛ぶのでござる。
手順6: ログファイル検証を実行する
AWS CloudShellを開き、証跡のARNを指定して検証を実行します。開始時刻には証跡を作成した時刻より後を指定します。
TRAIL_ARN=$(aws cloudtrail describe-trails \
--query "trailList[?Name=='audit-trail-lab'].TrailARN" --output text)
aws cloudtrail validate-logs \
--trail-arn "$TRAIL_ARN" \
--start-time "$(date -u -d '2 hours ago' +%Y-%m-%dT%H:%M:%SZ)"検証の対象になった期間と、検証できたファイル数が表示されます。
Validating log files for trail arn:aws:cloudtrail:ap-northeast-1:<アカウントID>:trail/audit-trail-lab between ... and ...
Results requested for 2026-09-12T05:33:59Z to 2026-09-12T07:34:00Z
Results found for 2026-09-12T06:06:49Z to 2026-09-12T07:06:49Z:
1/1 digest files validResults requested が指定した期間、Results found が実際にダイジェストが存在した期間です。digest files valid の分母と分子が一致していれば、その期間のダイジェストは署名どおりで改ざんされていません。ダイジェストが参照するログファイルも検証対象になった場合は、N/N log files valid の行が続けて表示されます。改ざんが検出された場合のみエラーが報告されます。
ダイジェストファイルは1時間ごとに出力されるため、証跡の作成直後は検証できるファイルがありません。「ダイジェストファイルが見つからない」と表示された場合は、1時間ほど待ってから実行します。
クラウドおさる「90日を超えて保存したい」「一定期間後に安くしたい」「改ざんを検出したい」「消させたくない」、要件ごとに使う仕組みを対応させられるかが試験の観点でござるな。長期保存にCloudWatch Logsや直接Glacierを選ばない理由まで言えれば、取り違えは防げるでござる。
まとめ
| 要件 | 使うもの |
|---|---|
| 直近90日の操作を調べたい | CloudTrailのイベント履歴（無料） |
| 90日を超えて保存したい | 証跡を作成し、S3バケットへ出力する |
| 一定期間を過ぎたら安く寝かせたい | S3ライフサイクルでGlacier Deep Archiveへ移行する |
| ログの改ざんを検出したい | 証跡のログファイル検証 + validate-logs |
| ログを消させたくない | バケットポリシー・S3 Object Lock |
- イベント履歴は90日・管理イベントのみ・単一リージョン。長期保存には証跡が要る
- 長期保存はS3、リアルタイムの検知はCloudWatch Logs、と役割を分ける
- Glacier Deep Archiveは最低保存期間180日で、ライフサイクルで他のクラスへは戻せない
- 管理イベントの最初のコピーは無料。2つ目以降の証跡は配信10万件あたり 2.00 USD
参照先
- CloudTrail イベント履歴でのイベントの表示 – AWS CloudTrail
- CloudTrail 証跡の作成 – AWS CloudTrail
- CloudTrail ログファイルの整合性の検証 – AWS CloudTrail
- オブジェクトの移行 – Amazon Simple Storage Service
- ストレージのライフサイクルの管理 – Amazon Simple Storage Service
