先に結論
CloudTrail は、AWSで 誰が いつ どこから 何をしたか を後から追うための仕組みです。
コンソール操作、CLI、SDK、API経由の操作履歴を記録できるので、誰がEC2を止めたのか どのIAMユーザーが権限を変えたのか どのロールでS3へアクセスしたのか を調べる入口になります。
ただし、ここでよくある誤解が1つあります。
CloudTrailは最初から全部を長期保存してくれる わけではありません。
AWS公式では、CloudTrail Event history で過去90日分の管理イベントを見られますが、継続的な記録や長期保管、S3保存、より広いイベント取得には Trail や event data store の設定が必要です。
この記事では、2026年4月23日時点で AWS公式の
How CloudTrail works、Working with CloudTrail event history、Understanding CloudTrail events、Logging management eventsを確認しながら整理しています。
CloudTrailとは何か
CloudTrailは、AWSアカウント内の操作履歴を記録して確認するためのサービスです。
ざっくり言うと、AWS版の監査ログの中心です。
たとえば、こんなときに使います。
- 誰がIAMポリシーを変更したか知りたい
- どのアカウントやロールでEC2を削除したか調べたい
- 不審な操作や想定外のAPIコールがないか見たい
- 障害や設定変更の原因を後から追いたい
- 監査対応で操作履歴を残したい
AWSを複数人で触るなら、CloudTrailはかなり重要です。
操作した人は分かるはず と感覚で運用すると、あとで事実確認にかなり苦労します。
まず押さえたい2つ
1. Event history は最初から使える
AWS公式では、AWSアカウント作成時点から CloudTrail Event history を使えます。
ここでは過去90日分の管理イベントを、リージョン単位で検索できます。
つまり、とりあえず最近の管理操作を見たい だけなら、いきなり重い設定をしなくても入口はあります。
2. でも長期保存や広い取得には追加設定がいる
一方で、Event history だけでは足りません。
AWS公式でも、Event history は 過去90日 管理イベント中心 という制約があります。
そのため、次のような用途では Trail や event data store を考えます。
- 90日を超えて残したい
- S3へ継続保存したい
- データイベントも取りたい
- 組織全体で集約したい
- 後から分析や調査をしやすくしたい
CloudTrailで見られるイベント
AWS公式では、CloudTrailイベントには主に次の種類があります。
| 種類 | ざっくりした意味 |
|---|---|
| 管理イベント | AWSリソースの作成、変更、削除などの管理操作 |
| データイベント | S3オブジェクトやLambda実行など、より細かいデータ面の操作 |
| ネットワークアクティビティイベント | 対象サービスへのネットワーク系の記録 |
| Insightsイベント | 異常なAPI呼び出し傾向を検知した記録 |
初心者が最初に触るのは、だいたい管理イベントです。
たとえば RunInstances TerminateInstances CreateUser AttachRolePolicy のような、AWS構成を変える操作がここへ入ります。
管理イベントとデータイベントの違い
ここはかなり大事です。
CloudTrailを入れたつもりでも、見たいものが出てこない と感じる原因の多くがこの違いです。
管理イベント
管理イベントは、AWSリソース自体への設定変更や制御操作です。
IAM、EC2、VPC、RDSの設定変更や作成削除のような操作が中心です。
誰が環境を変えたのかを追うなら、まずここを見ます。
データイベント
データイベントは、より大量かつ細かい操作です。
代表例は、S3オブジェクトへのアクセスや Lambda 関数の実行などです。
このため、S3の中の特定ファイルが誰に読まれたか のような粒度を見たい場合、管理イベントだけでは足りません。
必要な対象を選んでデータイベントも取る設計が必要です。
Trailとは何か
Trail は、CloudTrailの記録を継続的に配信・保存する設定です。
Event history が 最近の記録を見る入口 だとすると、Trail は ちゃんと残し続ける仕組み に近いです。
Trailを使うと、たとえば次のような構成が取りやすくなります。
- CloudTrailログをS3へ保存する
- 複数リージョンの操作をまとめて記録する
- 組織単位で記録を集約する
- 監査や障害調査で後から証跡を確認する
実務では、Event historyがあるから十分 と考えず、まず最低限どこまで残すべきかを決める方が安全です。
CloudTrailで何を見るのか
CloudTrailのログは、ただ保存するだけではあまり役に立ちません。
実際には、次の観点で見ることが多いです。
- 誰が実行したか
- どのロール、どのIAM主体だったか
- いつ発生したか
- どのリージョンで起きたか
- どのイベント名だったか
- 成功か失敗か
- 問題の前後で関連操作がないか
たとえば、本番EC2が止まった ときに、CloudTrailで StopInstances を引けば、誰の主体で、どこから、いつ実行されたかをかなり追いやすくなります。
CloudTrailが向いている場面
CloudTrailは、次のような場面で特に重要です。
- 複数人でAWSを触る
- IAM や権限変更が多い
- 本番障害の原因を後追いしたい
- セキュリティインシデント時の初動を速くしたい
- 監査対応や説明責任がある
小規模でも、管理者が1人を超えたあたりから価値がかなり上がります。
自分しか触らないから不要 と思っていても、時間がたつと自分の過去操作すら曖昧になります。
よくある誤解
1. CloudTrailがあればAWSのすべてが自動で完璧に追える
そこまではいきません。
どのイベントをどこまで取るか、何日残すか、どのアカウントやリージョンを含めるかは設計が必要です。
2. Event historyだけで十分
最近の管理イベントを見るだけなら便利ですが、90日制限や対象範囲の限界があります。
長期保存や詳しい分析を考えるなら、Trailやevent data storeの設計が必要です。
3. CloudTrailはセキュリティ部門だけのもの
実際には、障害調査、変更確認、権限整理、誤操作の追跡でもかなり役立ちます。
運用チームや開発チームにも普通に効く基盤です。
注意点
1. 取りたいイベントを決めないと抜ける
特にデータイベントは、何でも無条件で全部見る前提ではありません。
S3、Lambdaなど、何を取りたいのかを先に決めた方が運用しやすいです。
2. 保存先と保管期間も考える
監査や調査で使うなら、どこへ保存するか 何日残すか 改ざんや削除をどう防ぐか まで含めて考える必要があります。
3. 他ログと組み合わせると強い
CloudTrailはAWS操作の事実確認には強いですが、アプリ内部の動きまでは分かりません。
そのため、CloudWatch Logs、OSログ、アプリログ、セキュリティ製品の検知と組み合わせると調査しやすくなります。
まとめ
CloudTrail は、AWSで 誰が何をしたか を後から追うための基本サービスです。
まずは Event history で最近90日分の管理イベントを見られますが、長期保存や広い取得には Trail や event data store の設計が必要です。
CloudTrailをちゃんと使うと、権限変更、EC2操作、設定変更、障害の前後関係を追いやすくなります。
AWS運用で あとから事実確認できる状態 を作る土台として、早めに押さえておく価値があります。
参考リンク
- AWS Docs: How CloudTrail works
- AWS Docs: Working with CloudTrail event history
- AWS Docs: Understanding CloudTrail events
- AWS Docs: Logging management events