S3アクセスログ / CloudTrail / CloudWatchの違いを「監査の目的別」に整理する

ログや監査の話は、サービス名を暗記しようとすると一気に苦しくなります。SAA-C03でも大事なのは「何を確認したいのか（目的）」から逆算して、適切な記録・監視の手段を選べることです。

この記事では、混同しやすい S3アクセスログ（Server access logs） / AWS CloudTrail / Amazon CloudWatch を、監査・運用の目的別に整理し、よくある設計パターンまでつなげて解説します。

SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇

SAA-C03対策｜Udemyのおすすめ講座を見る

3つは「見ている対象」が違う
S3アクセスログとは何か
CloudTrailとは何か
CloudWatchとは何か
1. CloudWatchでできることの整理
2. CloudTrailとの違いを押さえる
目的別の選び分けパターン
まとめ：監査はCloudTrail、運用はCloudWatch、S3のアクセス分析はS3アクセスログ

3つは「見ている対象」が違う

最初に全体像だけ押さえると、迷いが減ります。

目的	いちばん合う選択肢	何が分かる？
「誰が・いつ・どのAWS APIを叩いたか」を追跡したい（監査の軸がAPI）	CloudTrail	AWS API呼び出しの履歴（管理イベント/データイベントなど）
「S3バケットへのリクエストを、アクセスの証跡として残したい」（監査/分析の軸がS3アクセス）	S3アクセスログ	バケットに対するリクエストの詳細レコード
「システムが今どういう状態か」「閾値超えを検知して通知したい」（運用監視）	CloudWatch	メトリクス・アラーム・ログ監視（運用の可視化と通知）

ここで重要なのは、CloudTrail＝監査ログ（API）、CloudWatch＝運用監視、S3アクセスログ＝S3リクエストの記録という役割分担です。SAA-C03の設計問題でも、この切り分けができると選択肢を落としやすくなります。

S3アクセスログとは何か

S3アクセスログ（Server access logging）は、S3バケットに対して発生したリクエストを、別のS3バケットへログとして保存する仕組みです。リクエストの記録を残すので、セキュリティ監査やアクセス分析に使えます。

どういうときに役に立つか

S3アクセスログがハマるのは、たとえば次のようなケースです。

「特定のオブジェクトが大量にダウンロードされている気がする。アクセス元やリクエスト内容を後から追いたい」
「アクセスが増えた日のS3課金が跳ねた。どんなリクエストが多かったかを把握したい」
「アプリからのアクセス経路（CloudFront経由/直S3など）を整理したい」

注意点：リアルタイム検知の用途には向きにくい

S3アクセスログは“監査・分析向け”です。つまり、今この瞬間に異常を検知して止めるという用途では、CloudWatchアラームのような「即時反応」を期待しすぎない方が安全です（ログはS3にオブジェクトとして出力され、運用監視の中心はCloudWatch側に寄せるのが一般的です）。

設計の落とし穴：ログ保存先バケットの権限

地味にハマりやすいのが「ログの出力先（ターゲットバケット）」の設定です。ログ出力先が存在しない／所有者が違う／適切な許可がない場合、エラーになります。
試験でも「ログを有効化したのに出ない」系のトラブルシュートは、権限や出力先の不備が絡みやすいので、まず疑うポイントとして覚えておくと実務でも役に立ちます。

具体例：アクセスログを“分析できる形”にする

S3アクセスログをただ溜めるだけだと、後で読むのが大変です。実務では、

ログ専用バケットに集約
ライフサイクルで保管コストを調整
Athenaなどで検索できる形にして調査を早くする

のように「後から調べやすい形」に寄せます。SAA-C03でも、ログを取る→保管する→活用するまでの流れで設計できると強いです。

CloudTrailとは何か

CloudTrailは、AWSアカウント内で起きたAPI呼び出しを記録する監査サービスです。S3の操作も含め、だれが何をしたかの追跡に向いています。

管理イベントとデータイベントの違いが分岐点

CloudTrailを理解する上で、試験でも混乱しやすいのがイベント種別です。

管理イベント（Management events）：AWSリソースの作成/変更/削除など、いわゆる“管理系”のAPI
データイベント（Data events）：データプレーンの操作、例：S3のオブジェクトレベルAPI（GetObject/PutObject/DeleteObjectなど）

S3の「オブジェクトを誰が読んだか/消したか」を追いたいなら、CloudTrailのデータイベントが本命になります。

コスト観点：データイベントは追加料金に注意

CloudTrailのデータイベントは便利ですが、追加料金が発生する点は押さえておきたいところです。
試験対策としては「監査要件が厳しい→データイベント」「コストも大事→必要なバケットに絞る」のように、要件とトレードオフで説明できるようにしておくと整理しやすいです。

S3アクセスログとの違いを一言で

CloudTrail：AWS APIとして「誰が何のAPIを呼んだか」を追う（監査の王道）
S3アクセスログ：S3バケットに来た「リクエストの記録」を残す（アクセス分析にも寄る）

SAA-C03の選択肢で迷うときは、「API監査なのか、S3アクセスの分析なのか」を一段言語化すると、答えが見えやすくなります。

CloudWatchとは何か

CloudWatchは、ざっくり言うと 運用監視の土台です。メトリクス（CPUやリクエスト数など）を見て、閾値を超えたらアラームで通知する、といった“今起きていること”に強いです。

CloudWatchでできることの整理

SAA-C03で問われやすいのは、以下の組み合わせです。

メトリクス：状態の数値化（例：EC2 CPU、ALB RequestCount など）
アラーム：閾値判定と通知/アクション
Logs：アプリ/OS/各サービスのログを集約して検索・アラーム化（メトリクスフィルター等）

そしてCloudWatchのアラームは、イベントとして Amazon EventBridge に送ることもできます。
「検知→自動対応」の設計で、EventBridgeと組み合わせる流れは現場でもよくあります。

CloudTrailとの違いを押さえる

CloudWatchは「運用監視」、CloudTrailは「監査（誰が何をしたか）」です。
たとえば「不正アクセスっぽい操作があったら通知したい」という要件なら、

記録の正本：CloudTrail（APIの事実を残す）
すぐ気づく：CloudWatch（ログやメトリクスから検知して通知）

という“二段構え”が自然です。目的が違うので、片方で全部をやろうとすると設計が歪みます。

目的別の選び分けパターン

ここからは、実務でも試験でも使える「要件→選択」の形でまとめます。

内部統制や監査対応を意識する

要件：誰がいつ何をしたかを説明できる状態にしたい
選択：CloudTrail中心（必要に応じてS3データイベント）
補足：S3アクセスログは、アクセス分析や補助的な証跡として併用があり得ます

S3のオブジェクト参照を追跡したい

要件：「この機密ファイル、誰が読んだ？」を追えるようにしたい
選択：CloudTrailのS3データイベント（GetObject/PutObject/DeleteObjectなど）
注意：データイベントは追加料金があるため、対象バケットを絞る判断が現実的です

障害や性能劣化を早く検知して通知したい

要件：CPUやエラー率が悪化したらすぐ気づきたい
選択：CloudWatchメトリクス＋アラーム
発展：アラームイベントをEventBridgeへ流して自動復旧フローへ

ありがちな勘違いを潰す

「CloudTrailを有効化したから、運用監視もできる」は違う
→ CloudTrailは監査の記録。リアルタイム監視はCloudWatchに寄せるのが基本です。
「S3アクセスログがあるから、S3のAPI監査も完璧」は危ない
→ “何を証跡として必要とするか”でCloudTrailデータイベントが必要になることがあります。