SAA 補足 監視と監査(CloudTrail・CloudWatch・Config)

更新日:

← AWS SAA / 関連 → SAA_補足_Systems Manager(Session Manager・Parameter Store・Patch Manager)

まず一言で

CloudTrail = 「誰が・いつ・何をしたか」(操作の記録)
CloudWatch = 「今どんな状態か」(性能・ログの監視)
Config = 「設定がどう変わったか、ルール違反はないか」(設定の記録)

試験ではこの3つを取り違えさせる選択肢がよく出る。問題文の言葉で見分ける。

問題文のキーワード答え
「誰がこのインスタンスを削除したか」「API 呼び出しを記録」「監査証跡」CloudTrail
「CPU 使用率が 80% を超えたら通知」「アプリのログを集める」CloudWatch
「セキュリティグループの設定の変更履歴」「暗号化されていない EBS を検出」Config
「不審な API 呼び出し・攻撃を自動で検知」GuardDuty(CloudTrail などのログを分析する)

CloudTrail

AWS への API 呼び出し(コンソール操作・CLI・SDK・他の AWS サービスからの呼び出し)を イベント として記録するサービス。1件ごとに「誰が(IAM ユーザー・ロール)」「いつ」「どこから(IP)」「何を(API 名・対象リソース)」「成功したか」が残る。

記録の残し方は3つ

方法内容料金
イベント履歴何も設定しなくても 直近 90 日分の管理イベント を見られる。リージョンごと無料
証跡(トレイル)イベントを S3 に保存し続ける。CloudWatch Logs・EventBridge にも送れる管理イベントの1コピー目は無料(S3 の保管料はかかる)
CloudTrail Lakeイベントを SQL で検索できるデータレイク。最長 約10年保存取り込み・保存・検索で課金
  • 90 日より長く残したい → 証跡を作って S3 に保存する ← 試験の定番
  • CloudTrail Lake は 2026年5月31日から新規利用の受付を終了(既存の利用者はそのまま使える)。新しく長期分析したいなら、S3 に保存した証跡を Athena で検索するのが基本

イベントの種類

種類何が記録されるか既定で記録
管理イベントリソースの作成・変更・削除など(EC2 の起動、IAM ポリシーの変更、ログイン)される
データイベントリソースの中身への操作(S3 のオブジェクトの GetObject / PutObject、Lambda の実行、DynamoDB の項目操作)されない(追加料金)
ネットワークアクティビティイベントVPC エンドポイント経由の API 呼び出しされない(追加料金)
Insights イベントAPI 呼び出しやエラーの数が 普段と違う ときに記録されない(追加料金)

→ 「S3 のどのファイルを誰が読んだか」を知りたいなら、データイベント を有効にした証跡が必要。

証跡の設定で覚えること

  • マルチリージョン証跡:有効な全リージョンのイベントを1つの S3 バケットに集める。普段使わないリージョンでの不正操作も見逃さない
  • 組織の証跡:Organizations の管理アカウントで作ると、全メンバーアカウント のイベントを1か所に集められる。メンバーアカウント側からは消せない
  • ログファイルの整合性検証:1時間ごとにダイジェストファイル(各ログのハッシュ値に署名したもの)を作る。ログが改ざん・削除されていないか を後から確かめられる
  • ログの保護:S3 側で暗号化(KMS キーも指定できる)、MFA Delete、S3 Object Lock、保存先バケットは別のログ専用アカウントに置く
  • すぐ反応したい:CloudTrail → CloudWatch Logs(メトリクスフィルターでアラーム)または EventBridge(ルールで Lambda や SNS を起動)
  • イベントが届くまでは 平均 約5分。リアルタイムではない
  • IAM・STS・CloudFront などのグローバルサービスのイベントは、主に バージニア北部(us-east-1) のイベントとして記録される
API 呼び出し ─▶ CloudTrail ─┬─▶ S3(長期保存、Athena で検索、Object Lock で改ざん防止)
                            ├─▶ CloudWatch Logs ─▶ メトリクスフィルター ─▶ アラーム ─▶ SNS
                            └─▶ EventBridge ─▶ Lambda(例: ルートユーザーのログインを検知して通知)

CloudWatch

AWS のリソースやアプリが 今どうなっているか を見るサービス。

機能内容試験でのキーワード
メトリクスCPU 使用率、リクエスト数などの数値。EC2 の標準は5分間隔(詳細モニタリングで1分)「性能を監視」
アラームしきい値を超えたら SNS 通知・Auto Scaling・EC2 の停止や復旧「〜を超えたら自動で」
Logsアプリや OS のログを集めて保存・検索(Logs Insights)「ログを一か所に集める」
CloudWatch エージェントEC2 の メモリ使用率・ディスク使用率 や OS のログを送る「メモリ を監視」← 標準では取れない
ダッシュボードグラフをまとめて表示—

→ EC2 のメモリやディスクの使用率は、標準のメトリクスには無い。CloudWatch エージェントを入れる(Systems Manager の Run Command や State Manager で配ると楽)。

Config

AWS リソースの 設定がいつ、どう変わったか を記録し、ルールに合っているか をチェックするサービス。

  • 設定の履歴:「先週の時点で、このセキュリティグループはどんなルールだったか」がわかる
  • Config ルール:例「S3 バケットが公開されていない」「EBS が暗号化されている」「EC2 が Systems Manager で管理されている」。違反したリソースを一覧できる
  • 自動修復:違反を見つけたら Systems Manager Automation のランブックで直す
  • コンフォーマンスパック:ルールをまとめて組織全体に配る

3つの違いをまとめて

CloudTrailCloudWatchConfig
記録するものAPI 呼び出し(操作)メトリクス・ログ(状態)リソースの設定(構成)
答えられる問い誰が何をした?今どうなっている?設定はどう変わった? ルール違反は?
例「誰が SG を変えたか」「CPU が高い」「SG で 22番が全開放になっている」

同じ「セキュリティグループの変更」でも、誰が変えたか → CloudTrail、変更前後の設定とルール違反 → Config と分かれる。

確認ポイント

  • CloudTrail・CloudWatch・Config の違いを一言ずつで言える
  • イベント履歴は 90 日、それより長く残すには証跡を作って S3 に保存、と言える
  • S3 のオブジェクト操作を記録するにはデータイベントが必要と言える
  • 全アカウント・全リージョンのログを集めるなら組織の証跡(マルチリージョン)と言える
  • ログの改ざんを確かめる方法(整合性検証)を説明できる
  • EC2 のメモリ使用率を見るには CloudWatch エージェントが必要と言える

関連ノート

このノートを参照しているノート