変更要約: SOA-C02 第1章を Associate 級に深掘り（比較表・シナリオ・FAQ・ひっかけ＋深掘り段落、図を日本語化）
1.2ログ集約と監査（CloudWatch Logs と CloudTrail）
CloudWatch Logs によるアプリ/OS ログの集約と Logs Insights、CloudTrail による API 操作の監査（誰が何をしたか）、両者の使い分けを理解します。
問題の調査や監査にはログが不可欠です。AWS では アプリ/OS のログ＝CloudWatch Logs、API 操作の記録＝CloudTrail と役割が分かれています。
1.2.1ログと監査証跡
- CloudWatch Logs：アプリ・OS・Lambda などのログを集約。Logs Insightsでクエリ・分析する。
- メトリクスフィルター：ログ内のパターン（ERROR 等）出現をメトリクス化し、アラームできる。
- CloudTrail：API 操作（誰が・いつ・何をしたか）を記録し、アカウント全体の監査に使う。
「誰がリソースを変更/削除したか＝CloudTrail」「アプリ/OS のログ調査＝CloudWatch Logs」「ログ内の語の出現監視＝メトリクスフィルター＋アラーム」 は SOA で頻出です。混同に注意。
2つを役割で切り分けます。CloudWatch Logs は「アプリや OS が何をしているか」を見るためのログ集約で、ロググループ／ログストリームに整理し、Logs Insightsのクエリ言語で横断分析します。ログ内に「ERROR」などのパターンが出た回数を メトリクスフィルター でメトリクス化すれば、前節のアラームで通知できます。一方 CloudTrail は「誰が・いつ・どの API を呼んだか」を記録する監査サービスで、リソースの作成/変更/削除を後追いできます。組織証跡（organization trail） で全アカウント・全リージョンを1か所に集約し、S3 に長期保存、改ざん検知に ログファイル検証 を有効化します。データイベント（S3 オブジェクト操作や Lambda 実行）は既定オフなので、必要なら明示的に有効化します。EC2/オンプレのログを Logs へ送るには CloudWatch エージェント（または統合エージェント）を使います。
| 知りたいこと | 使うもの |
|---|---|
| アプリ/OS が何をしているか | CloudWatch Logs（Logs Insights） |
| 誰がリソースを変更/削除したか | CloudTrail |
| ログ内の語の出現で通知 | メトリクスフィルター＋アラーム |
| 全アカウント/全リージョン監査 | CloudTrail 組織証跡→S3 |
シナリオ：本番のセキュリティグループを誰かが勝手に変更した。 「誰が・いつ・何を」は CloudTrail で特定（組織証跡なら全アカウント横断）。アプリ側の影響は CloudWatch Logs をLogs Insightsで時間帯指定して調査。再発防止に、該当 API を メトリクスフィルター＋アラームで監視し SNS 通知、さらに EventBridge で自動是正へつなげます。
Q. 削除した犯人を知りたい。 CloudTrail。Q. アプリのエラーログを分析。 CloudWatch Logs（Logs Insights）。Q. S3 オブジェクトの読み取りも記録したい。 CloudTrail のデータイベントを有効化。Q. ログの改ざん検知は？ ログファイル検証。
混同に注意：
①CloudTrail＝API 監査（誰が何を）／CloudWatch Logs＝アプリ・OS ログ（何が起きたか）——役割を取り違えない。
②データイベント（S3/Lambda）は既定オフ。
③CloudTrail は「管理イベント」を90日間はイベント履歴で見られるが、長期保存には S3 証跡が必要。
CloudTrail の証跡（trail）を S3 に長期保存し、複数リージョン/組織全体を1か所に集約すると監査・コンプライアンスに有効です。
1.2.2この節のまとめ
- CloudWatch Logs＝アプリ/OS ログ／CloudTrail＝API 操作の監査
- ログの語を監視＝メトリクスフィルター＋アラーム
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 「誰がいつそのリソースを削除したか」を後から調査したい。最も適したサービスはどれですか？
Q2. アプリのログを集約し、クエリ言語で分析したい。何を使いますか？
Q3. ログ内に "ERROR" が一定回数以上出たら通知したい。何を使いますか？