障害の連絡が来た。何かが変わったらしい。けれど、CloudTrail を開けばいいのか、CloudWatch Logs を開けばいいのか、フローログはどこにあるのか、AWS Config は有効だったか、が分からない。AWS のログは1か所にまとまっていないので、仕組みを知らないと「どこから見るか」で時間を使ってしまいます。この記事は、AWS の代表的な4つのログを「どの問いに答えるか」で分け、それぞれで分かること・分からないこと、保存先と保持、調べる順番までを一続きで整理します。
この記事の結論
- AWS CloudTrail は、AWS の API がいつ、どの呼び出し元から、どう呼ばれたかを記録し、「誰が何をしたか」に答えます。
- Amazon CloudWatch Logs は、アプリ・OS・AWS のサービスが出すログを集めて保存し、検索する置き場です。
- VPC フローログは、ネットワークインターフェイスを通った通信の送信元・宛先・許可か拒否かを残しますが、通信の中身は残しません。
- AWS Config は、リソースの設定の履歴を残し、ルールに合っているかを評価して「設定がどう変わったか」に答えます。
- 長く残すログは S3 に集め、保持期間を決め、調べるときは症状 → 設定の変化 → 操作した人 → 通信の順に絞り込みます。
AWS のログとは（4つの記録が答える問い）
たとえるなら、AWS のログは1冊の日誌ではなく、建物の「入館記録」「各部屋の業務日誌」「廊下の人の流れ」「設備台帳」の4冊に分かれています。入館記録を見ても部屋の中で何があったかは分からず、業務日誌を見ても誰が設備の設定を変えたかは分かりません。
正確な言葉に戻すと、4冊はそれぞれ次のサービスです。
FOUR QUESTIONS4冊の記録
AWS のログは、答える問いごとに4冊に分かれている
-
誰が
AWS CloudTrail — API を誰がいつ呼んだか
管理イベントの過去 90 日は最初から見られる
-
中で
CloudWatch Logs — アプリと OS の中で何が起きたか
保持期間はロググループごとに自分で決める
-
通信
VPC フローログ — どこと通信し、許可か拒否か
中身とドメイン名は残らない。作成が要る
-
設定
AWS Config — 設定がいつどう変わったか
ルールで準拠を評価。有効化が要る
| ログ | 答える問い | 分からないこと | 何もしないとどうなるか | 長く残す先 |
|---|---|---|---|---|
| AWS CloudTrail | 誰が・いつ・どの API を呼んだか | OS やアプリの中で何が起きたか | 管理イベントの過去 90 日はイベント履歴で見られる | 証跡を作って S3 へ |
| CloudWatch Logs | アプリ・OS・サービスの中で何が起きたか | AWS のリソースを誰が変えたか | 送る設定をしたログだけが集まる | ロググループの保持期間、または S3 へ |
| VPC フローログ | どこと通信し、許可されたか拒否されたか | 通信の中身・ドメイン名 | 記録されない（作成が要る） | CloudWatch Logs、S3、Firehose |
| AWS Config | リソースの設定がいつどう変わったか、ルールに合っているか | 変更を起こした操作の詳細（CloudTrail を見る） | 記録されない（有効化が要る） | 配信チャネルの S3 バケットへ |
表の「何もしないとどうなるか」の列が大事です。4つのうち、設定しなくても最初から手元にあるのは CloudTrail のイベント履歴だけです。事故が起きてからフローログや Config を有効にしても、過去の分は戻ってきません。
CloudTrail は何を記録し、何を記録しないのか
AWS CloudTrail は、AWS の API の呼び出しをイベントとして記録します。コンソールでの操作も、AWS CLI や SDK からの操作も、裏では API の呼び出しなので同じように残ります。1件のイベントには、呼び出し元の ID（IAM ユーザーやロール）、時刻、送信元の IP アドレス、呼ばれた API の名前、リクエストの中身と結果が入ります。
管理イベントとデータイベント
CloudTrail のイベントには大きく2種類あります。
- 管理イベント — リソースの作成・変更・削除のような、リソースそのものに対する操作。
CreateBucketやAuthorizeSecurityGroupIngressなど。 - データイベント — リソースの中のデータに対する操作。S3 のオブジェクトの読み書きや Lambda 関数の呼び出しなど。量が多いので、既定では記録されません。
CloudTrail は既定で有効になっていて、リージョンごとに過去 90 日の管理イベントを「イベント履歴」で見られます。ただし、イベント履歴にはデータイベントは入らず、90 日より前は消えます。長く残したい、データイベントも残したい、というときは証跡（トレイル）を作り、S3 バケットに配信します。管理イベントの1つ目のコピーを S3 に配信する分には CloudTrail の料金はかからず、S3 の保存料金がかかる、と公式は説明しています。
証跡を守る仕組み
ログは、消されたり書き換えられたりすると証拠になりません。CloudTrail にはそのための仕組みがあります。
- 組織の証跡 — AWS Organizations の管理アカウント（または委任管理者）から、組織の全アカウントの記録を1つのバケットに集めます。メンバーアカウントの側からは止めたり消したりできません。
- ログファイルの整合性の検証 — 配信したログファイルが後から変更・削除されていないかを確かめられるようにします。
- CloudWatch Logs への送信 — 証跡を CloudWatch Logs にも送ると、「ルートユーザーでサインインした」のような特定のイベントを数えて、アラームで通知できます。
CloudTrail が答えないのは、EC2 の中で誰がどのコマンドを打ったか、アプリがどんなエラーを出したか、といった「AWS の API の外側」です。そこは次の CloudWatch Logs の担当です。
READ ALSO — 学習中向け・段2 構成
AWS アカウントを作ったら最初にやるセキュリティとは｜ルートユーザー・MFA・CloudTrail・予算アラート
CHECK 1ここまでの確認
何もしていない AWS アカウントでも、CloudTrail で後から確かめられるのはどれですか?
答えと解説
答え: 1. 過去 90 日の管理イベント（リソースの作成・変更・削除などの操作）
何も設定しなくても見られるのは、イベント履歴にある過去 90 日の管理イベントだけです。データイベントは明示的に有効にしないと記録されず、OS の中の操作は CloudTrail の範囲外です。「CloudTrail は何を記録し、何を記録しないのか」の章を読み直してください。
CloudWatch Logs は何を集めるのか
Amazon CloudWatch Logs は、ログを集めて保存し、検索するための置き場です。CloudWatch はメトリクス（数値）とアラームの印象が強いサービスですが、ログの置き場も同じ CloudWatch の一部です。
ロググループとログストリーム
ログはロググループにまとめられ、その中に送り元ごとのログストリームが並びます。たとえば「アプリ A の本番のログ」を1つのロググループにし、EC2 のインスタンスごとにストリームが分かれる、という形です。保持期間やアクセス権はロググループの単位で決めます。
送り方は送り元で変わります。Lambda の関数は実行ログを CloudWatch Logs に書き出します。EC2 の中の OS やアプリのログは、CloudWatch エージェントを入れて送ります。VPC フローログや CloudTrail のように、AWS のサービス側から CloudWatch Logs を送り先に選べるものもあります。
保持期間は自分で決める
CloudWatch Logs のログは、既定では期限なしで保存され続けます。保持期間はロググループごとに、1日から10年のあいだか「期限なし」から選べます。何も決めずにいると、調査に使わない古いログの保存料金がかかり続けます。反対に短くしすぎると、あとで遡りたいときに残っていません。規程で決まった期間があるならそれに合わせ、長く残すものは S3 に送る、という分け方が扱いやすくなります。
集めたログをどう使うか
| 使い方 | 何をするか | よくある場面 |
|---|---|---|
| Logs Insights | ロググループに対して、その場でクエリを実行して絞り込み・集計する | 障害対応中に、エラーの件数を関数ごとに数える |
| メトリクスフィルター | ログの中の特定の文字列やパターンを数えてメトリクスにする | 「ERROR」の件数や特定の API の呼び出しにアラームをかける |
| サブスクリプションフィルター | ログをほぼリアルタイムで別のサービスに流す | Firehose 経由で S3 に送り、長期保存や分析に回す |
CloudWatch Logs が答えないのは「AWS のリソースを誰が変えたか」です。アプリが急にエラーを出し始めたとき、その原因がセキュリティグループの変更なら、その変更は CloudWatch Logs ではなく CloudTrail と Config に残っています。
READ ALSO — 学習中向け・段2 構成
Amazon CloudWatch とは何か｜メトリクス・ログ・アラーム・ダッシュボードで「何を見れば何が分かるか」
VPC フローログで分かること・分からないこと
VPC フローログは、VPC の中のネットワークインターフェイスを出入りした IP の通信の情報を記録します。VPC 全体、サブネット、ネットワークインターフェイスのどの単位でも作れます。送り先は CloudWatch Logs、S3、Amazon Data Firehose から選びます。
1件の記録（フローログレコード）には、送信元と宛先の IP アドレスとポート、プロトコル、パケット数とバイト数、そしてACCEPT（許可された）か REJECT（拒否された）かが入ります。「つながらない」ときに、通信がそもそも届いているのか、セキュリティグループやネットワーク ACL で拒否されているのかを切り分けるのに使います。
READ ALSO — 未経験向け・段1 入口
セキュリティグループとネットワーク ACL の違い｜2つの門の仕組み
一方で、フローログには分からないことがはっきりあります。
- 通信の中身は残らない。 記録されるのは通信のメタデータで、パケットの中身（ペイロード）は入りません。HTTP のリクエストの本文を見たいなら、アプリやロードバランサーのログを見ます。
- ドメイン名は残らない。 DNS のホスト名のようなアプリケーション層の情報は含みません。記録は IP アドレスです。
- すべての通信が載るわけではない。 Amazon が用意する DNS サーバーへの通信、インスタンスメタデータ（169.254.169.254）との通信、DHCP の通信などは記録の対象外だと公式に書かれています。
CHECK 2ここまでの確認
VPC フローログで確かめられることはどれですか?
答えと解説
答え: 1. 送信元と宛先の IP アドレス・ポートと、通信が ACCEPT か REJECT か
フローログが残すのは通信のメタデータで、中身（ペイロード）や DNS のホスト名のようなアプリの層の情報は含みません。「VPC フローログで分かること・分からないこと」の章を見てください。
AWS Config は「設定の変化」をどう残すのか
AWS Config は、AWS のリソースの設定を記録し続けるサービスです。記録対象のリソースの設定が変わるたびに、その時点の設定を設定項目（Configuration Item）として残します。設定項目には、リソースの属性、ほかのリソースとの関係、そして関連するイベントの情報が入ります。これを時系列に並べたものが設定の履歴です。
Config が答えるのは「このリソースの設定は、いつ、どこが、どう変わったか」です。たとえば「昨夜 23 時の時点で、このセキュリティグループは 22 番を 0.0.0.0/0 に開けていたか」に答えられます。
CloudTrail との分担
CloudTrail と Config は、同じ変更を別の側から見ています。
ACTION OR STATE同じ変更を2つの側から
CloudTrail は操作を、Config は状態を残す
AWS CloudTrail
主語は人やロール
- 誰が・いつ・どの API を呼んだか
- 送信元の IP アドレスと結果
- 証跡で S3 に長く残す
AWS Config
主語はリソース
- 設定の前後がどう変わったか
- ルールに合っているか（準拠・非準拠）
- 配信チャネルで S3 に残す
CloudTrail は「操作」の記録で、主語は人やロールです。Config は「状態」の記録で、主語はリソースです。Config のリソースのタイムラインでは設定の変化と CloudTrail のイベントを並べて見られるので、「どう変わったか」から「誰が変えたか」へ、1つの画面の中でたどれます。
ルールで評価し、S3 に残す
Config には、設定がルールに合っているかを評価する Config ルールがあります。「S3 バケットが公開されていないか」「SSH が全開放されていないか」のようなルールを置くと、合っていないリソースを「非準拠」として出します。ルールと修復のアクションをまとめた適合パックで、組織に一括で展開することもできます。
Config を使うには、記録を有効にし、配信チャネルとして S3 バケットを指定します。設定の履歴とスナップショットのファイルはそのバケットに配信されます。有効にする前の設定は記録されないので、事故が起きてからでは遅い、という点は CloudTrail の証跡やフローログと同じです。
CHECK 3ここまでの確認
本番のセキュリティグループが昨夜から変わっていたとき、「どこがどう変わったか」と「その操作をしたのは誰か」を組み合わせて調べるなら、どれとどれを見ますか?
答えと解説
答え: 1. AWS Config の設定の履歴と、CloudTrail のイベント
Config は設定の前後を、CloudTrail はその変更を起こした API 呼び出しと呼び出し元を記録します。Config の設定項目には関連する CloudTrail のイベントへの手がかりも残ります。「AWS Config は設定の変化をどう残すのか」の章を読み直してください。
ログはどこに残し、どの順番で調べるか
保存先と保持を決める
4つのログの長期保存の行き先は、どれも S3 に集められます。CloudTrail の証跡、Config の配信チャネル、フローログは直接 S3 に送れますし、CloudWatch Logs もサブスクリプションフィルターや書き出しで S3 に移せます。S3 に集めたあとは、ライフサイクルで古いものを安い保存クラスに移し、期限が来たら消す、という運用にできます。
アカウントを分けている組織では、ログをログ保管専用のアカウントの S3 バケットに集める形がよく使われます。ワークロードのアカウントの管理者であっても、保管先のログを書き換えたり消したりできないようにするためです。アカウントの分け方は、マルチアカウントの設計の記事で扱っています。
READ ALSO — プロフェッショナル向け・段4 設計
マルチアカウント設計｜アカウントを「境界」として使い、Organizations と SCP で組織のガードレールを引く
ログでやってはいけない3つ
- フローログや Config を「何か起きてから」有効にしようとする（過去の分は戻らない）
- CloudWatch Logs の保持期間を決めずに放置する（期限なしで溜まり続ける）
- ログを出したアカウントと同じ権限で消せる場所にだけ置く（証拠として弱くなる）
調べるときの順番
障害や事故を調べるときは、4冊を順に開いて範囲を絞っていきます。どの順でも答えにはたどり着けますが、「いつ、何が起きたか」を先に決めないと、どのログも広すぎて読めません。
NARROW IT DOWN調べる順番の一例
調べるときは症状 → 設定 → 人 → 通信の順に絞る
-
CloudWatch
症状と時刻を決める
-
AWS Config
前後の設定の変化を探す
-
CloudTrail
変えた呼び出し元を特定
-
フローログ
通信が届き、許可されたか
- 症状と時刻を決める（CloudWatch） — メトリクスで悪くなった時刻をつかみ、CloudWatch Logs のアプリのログでエラーの中身を見る。
- 設定の変化を探す（AWS Config） — その時刻の前後に、関係するリソースの設定が変わっていないかを見る。
- 誰が変えたかを特定する（CloudTrail） — 変化に対応する API の呼び出しを探し、呼び出し元と送信元を確かめる。
- 通信が届いているかを確かめる（VPC フローログ） — つながらない系の症状なら、REJECT が出ていないか、そもそも通信が来ているかを見る。
この順番は「広い範囲から狭い範囲へ」の一例です。セキュリティの事故で「このアクセスキーが何に使われたか」から始まるなら、CloudTrail から開くのが近道です。問いに合わせて最初の1冊を選べるようになることが、この記事のゴールです。次は、何に気づきたいかから逆算してメトリクス・アラーム・ログを組む監視の設計に進んでください。
READ ALSO — 実務向け・段3 基盤
監視設計｜何を見るかは SLO から逆算する。4つのシグナルと、アラームを鳴らす基準の決め方
参照ソース
- What Is AWS CloudTrail?（AWS CloudTrail ユーザーガイド） — CloudTrail が記録するもの、管理イベントとデータイベント（2026年9月時点）
- Working with CloudTrail event history（AWS CloudTrail ユーザーガイド） — 既定で有効なこと、過去 90 日の管理イベント、データイベントは入らないこと、証跡の1つ目のコピーの料金の扱い（2026年9月時点）
- Validating CloudTrail log file integrity（AWS CloudTrail ユーザーガイド） — ログファイルの整合性の検証（2026年9月時点）
- What is Amazon CloudWatch Logs?（Amazon CloudWatch Logs ユーザーガイド） — ログの収集・保存・検索の概要（2026年9月時点）
- Working with log groups and log streams（Amazon CloudWatch Logs ユーザーガイド） — ロググループとログストリーム、保持期間の既定（期限なし）と選べる範囲（2026年9月時点）
- Real-time processing of log data with subscriptions（Amazon CloudWatch Logs ユーザーガイド） — サブスクリプションフィルターでの転送（2026年9月時点）
- Logging IP traffic using VPC Flow Logs（Amazon VPC ユーザーガイド） — フローログの単位と送り先、レコードの内容（2026年9月時点）
- Flow log limitations（Amazon VPC ユーザーガイド） — 記録されない通信の一覧（2026年9月時点）
- What Is AWS Config?（AWS Config 開発者ガイド） — 設定の記録とルールによる評価（2026年9月時点）
- AWS Config terminology and concepts（AWS Config 開発者ガイド） — 設定項目の中身、配信チャネルと S3 への配信（2026年9月時点）
