▪️目的
AWSを利用していると、「CloudTrail」というサービスを目にすることがあります。
AWSでは、EC2やS3、RDS、IAMなど、さまざまなサービスを利用します。
しかし、AWSの環境を運用していると、
- 誰がAWSの設定を変更したの？
- いつEC2が作成されたの？
- 誰がS3の設定を変更したの？
- IAMの権限は誰が変更したの？
- AWS上で何が起きたのか確認したい
- セキュリティインシデントが発生したとき、どう調査するの？
といった場面が出てきます。
そこで重要になるのがAWS CloudTrailです。
この記事では、AWS初心者の方向けに、CloudTrailの基本的な仕組みからイベント、ログの保存、CloudWatch LogsやS3との連携まで分かりやすく解説します。
▪️CloudTrailとは？
CloudTrailとは、
AWSアカウント内で行われたAPI操作などのアクティビティを記録するサービス
です。
例えばAWSコンソールからEC2を作成した場合、
ユーザー
│
▼
AWSコンソール
│
▼
EC2を作成
という操作が行われます。
CloudTrailでは、このようなAWS上の操作をイベントとして記録できます。
ユーザー
│
▼
AWS操作
│
▼
CloudTrail
│
└─ 操作履歴を記録
つまりCloudTrailは、
「AWS上で何が起きたのかを後から確認するための記録」
と考えると分かりやすいでしょう。
▪️CloudTrailで何が分かる？
CloudTrailに記録されたイベントを見ることで、例えば、
- 誰が操作したのか
- いつ操作したのか
- どのAWSサービスを操作したのか
- どのAPIを呼び出したのか
- どのリソースに対して操作したのか
- どこから操作されたのか
などを確認できます。
例えば、
EC2のインスタンスが作成された
という出来事があったとします。
CloudTrailの記録から、
誰が？
↓
いつ？
↓
どのAPIを？
↓
どのリソースに対して？
という情報を確認できます。
▪️CloudTrailのイベントとは？
CloudTrailでは、AWS上で発生した操作などをイベントとして記録します。
例えばEC2を作成した場合、
RunInstances
というAPI呼び出しが行われます。
CloudTrailでは、このようなAPIアクティビティをイベントとして記録します。
イメージとしては、
EC2を作成
↓
RunInstances
↓
CloudTrailに記録
です。
同じように、AWSのさまざまなサービスでAPI操作が発生すると、それらがCloudTrailのイベントとして記録されます。
▪️CloudTrailのログを見ると何が分かる？
CloudTrailのイベントには、さまざまな情報が含まれます。
例えば、
イベント名
↓
RunInstances
イベント時刻
↓
2026-10-08 10:00:00
ユーザー
↓
example-user
AWSサービス
↓
EC2
送信元IP
↓
xxx.xxx.xxx.xxx
といった情報です。
実際には、イベントにはさらに多くの情報が含まれます。
このため、
「誰が、いつ、何をしたのか」
を調査するときにCloudTrailが役立ちます。
▪️CloudTrailとIAMの関係
前回の記事で紹介したIAMとCloudTrailは、非常に相性の良いサービスです。
IAMは、
誰が何をしてよいのかを管理する
ための仕組みです。
一方、CloudTrailは、
実際にどのような操作が行われたのかを記録する
ための仕組みです。
例えば、
IAM
↓
user-aにEC2操作を許可
という設定があった場合、
user-a
↓
EC2を作成
という実際の操作がCloudTrailに記録されます。
つまり、
IAM
↓
権限を管理
CloudTrail
↓
操作を記録
と考えると分かりやすいでしょう。
▪️CloudTrailとCloudWatchの違い
CloudTrailとCloudWatchも、AWS初心者の方が混乱しやすい組み合わせです。
どちらも「監視」に関係するように見えますが、役割が異なります。
| 項目 | CloudTrail | CloudWatch |
|---|---|---|
| 主な役割 | AWS操作・APIアクティビティの記録 | メトリクス・ログ・イベントなどの監視 |
| 代表例 | EC2を誰が作成したか | EC2のCPU使用率 |
| 目的 | 監査・調査 | 監視・運用 |
| 確認したいこと | 誰が何をしたか | システムがどう動いているか |
例えば、
EC2のCPU使用率が90%になった
という情報を見るならCloudWatch。
一方、
誰かがEC2の設定を変更した
という操作履歴を確認するならCloudTrailです。
簡単に考えると、
CloudWatch＝システムの状態を見る
CloudTrail＝AWS上の操作を見る
というイメージです。
▪️CloudTrailとS3の関係
CloudTrailでは、イベント履歴を確認するだけではなく、S3へログを保存する構成もよく利用されます。
例えば、
AWS環境
│
▼
CloudTrail
│
▼
S3
│
└─ CloudTrailログを保存
という構成です。
S3へ保存することで、CloudTrailのログを長期間保管しやすくなります。
▪️なぜS3に保存するの？
AWSの操作ログは、セキュリティや監査の観点から長期間保存したい場合があります。
例えば、
過去のAWS操作を調査したい
↓
CloudTrailログを確認
↓
S3に保存されたログを利用
という形です。
また、S3のライフサイクル機能などと組み合わせることで、
CloudTrail
↓
S3 Standard
↓
一定期間経過
↓
低コストなストレージクラス
のように、保存期間に応じたデータ管理を設計することもできます。
▪️CloudTrailのログを長期間保存する
例えば企業のAWS環境では、
AWS操作
↓
CloudTrail
↓
S3
↓
長期間保存
という構成が考えられます。
CloudTrailのログをS3へ集約して保存することで、AWS環境で発生した操作を後から調査できるようにします。
特に、
- セキュリティ監査
- 不正アクセス調査
- 設定変更の追跡
- インシデント調査
- コンプライアンス対応
などで重要になります。
▪️CloudTrailの代表的な利用例
CloudTrailは、さまざまな場面で利用できます。
① 誰がEC2を作成したのか確認する
例えば、
「知らないEC2インスタンスが作られている」
という状況になったとします。
CloudTrailを確認することで、
誰が？
↓
いつ？
↓
RunInstances APIを実行した
といった情報を調査できます。
② IAMの設定変更を確認する
例えば、
「いつの間にかIAMポリシーが変更されている」
という場合です。
CloudTrailを確認することで、
IAMポリシー変更
↓
CloudTrail
↓
実行したユーザーや時刻を確認
という調査ができます。
IAMはAWS環境の権限を管理する重要なサービスなので、その変更履歴を追跡できることは非常に重要です。
③ S3の設定変更を調査する
例えば、
「S3バケットの設定が変更されている」
という場合にもCloudTrailが役立ちます。
CloudTrailから関連するAPIイベントを確認することで、設定変更の経緯を調査できます。
▪️CloudTrailのイベントには種類がある
CloudTrailのイベントは、大きく分けていくつかの種類があります。
代表的なのが、
- Management events
- Data events
- Insights events
です。
♦︎Management events
Management eventsは、AWSリソースの作成・変更・削除など、管理操作に関するイベントです。
例えば、
EC2を作成
EC2を停止
IAMポリシーを変更
VPCを変更
などです。
AWS環境の構成変更を追跡するうえで重要になります。
♦︎Data events
Data eventsは、S3オブジェクトへのアクセスなど、よりデータレベルの操作を記録するために利用されます。
例えば、
S3
↓
オブジェクトを取得
といった操作です。
Management eventsと比べて大量に発生する可能性があるため、どのデータ操作を記録するかを考えて設計することが重要です。
♦︎Insights events
CloudTrail Insightsは、通常とは異なるAPIアクティビティなどを検出するための機能です。
例えば、
普段
↓
EC2作成 1〜2回
突然
↓
短時間に大量のEC2作成
といった通常とは異なる操作傾向を検出するために利用できます。
▪️CloudTrailを利用するときのポイント
CloudTrailを利用するときには、単純に「ログを取ればOK」ではありません。
例えば、
- どのAWSアカウントを対象にするか
- どのリージョンを対象にするか
- どのイベントを記録するか
- ログをどこへ保存するか
- どのくらいの期間保存するか
- ログへのアクセス権限をどうするか
- ログ自体を改ざん・削除されにくくするにはどうするか
などを考える必要があります。
特に監査用のログは、
「ログを記録する環境」と「ログを保管する場所」を適切に分離する
といった考え方も重要になります。
▪️CloudTrailとCloudWatch Logs
CloudTrailはS3だけではなく、CloudWatch Logsと連携することもできます。
例えば、
CloudTrail
│
▼
CloudWatch Logs
│
▼
監視・分析
という構成です。
CloudWatch Logsへ送ることで、CloudWatch側の機能と組み合わせてログを分析・監視できます。
例えば、
CloudTrail
↓
特定のAPI操作
↓
CloudWatch Logs
↓
メトリクスフィルターなど
↓
アラーム
のような運用も考えられます。
▪️CloudTrailを利用したセキュリティ対策
AWSでは、
「何か問題が起きてから調べる」
だけではなく、
「後から調査できるように、あらかじめ記録を残しておく」
ことが重要です。
例えば、
IAM
↓
誰が何をできるか制御
CloudTrail
↓
実際に何をしたか記録
S3
↓
ログを長期間保存
CloudWatch
↓
ログや状態を監視
というように、それぞれのサービスを組み合わせることができます。
これがAWSのセキュリティ・運用設計の基本的な考え方の一つです。
▪️CloudTrailを理解するとAWSの運用が見えてくる
ここまでの記事で紹介してきたAWSサービスを組み合わせると、かなり実際のシステムに近い構成が見えてきます。
例えば、
AWS
│
┌────────────┼────────────┐
▼ ▼ ▼
IAM CloudTrail CloudWatch
│ │ │
│ ▼ │
│ S3 │
│ │
└──────── AWS環境 ────────┘
というように、
- IAMでアクセス権限を管理する
- CloudTrailでAWS操作を記録する
- S3へログを保存する
- CloudWatchで監視する
という役割分担ができます。
AWSでは、単に「サーバーを構築する」だけではなく、
誰が操作できるのか
何が起きたのか
問題が起きたときにどう調査するのか
まで考えてシステムを運用します。
▪️まとめ
今回は、AWSのCloudTrailについて解説しました。
CloudTrailは、AWSアカウント内で行われたAPI操作などのアクティビティを記録するサービスです。
ポイントを整理すると、
- CloudTrailはAWSの操作履歴を記録する
- AWS上のAPIアクティビティなどをイベントとして記録する
- 誰が、いつ、どのような操作をしたのか調査できる
- IAMが「誰に何を許可するか」を管理するのに対し、CloudTrailは「実際に何が行われたか」を記録する
- CloudWatchは主にシステムの状態やログなどを監視するサービスで、CloudTrailとは役割が異なる
- CloudTrailのログをS3へ保存して長期間保管できる
- Management events、Data events、Insights eventsなどがある
- セキュリティ監査やインシデント調査、設定変更の追跡などに利用できる
- CloudWatch Logsなどと連携して監視・分析することもできる
特に、
IAM＝誰が何をしてよいのか
CloudTrail＝誰が何をしたのか
CloudWatch＝システムがどう動いているのか
という3つの違いを理解しておくと、AWSのセキュリティ・運用がかなり分かりやすくなります。
AWSでは、サービスを構築するだけでなく、**「その環境を安全に運用し、問題が起きたときに原因を追跡できるようにする」**ことも重要です。
CloudTrailは、そのための基本となるサービスの一つです。
次回は、AWS上のリソースやアプリケーションの状態を監視するCloudWatchについて解説します。
＊「CloudWatch」の記事はこちら
→「https://lovelabengineer.com/2026/10/08/awsのcloudwatchとは？awsのリソースやシステムを監視する仕/」
No responses yet