週7CloudWatch / CloudFormation

2026-09-16（水）CloudWatch, CloudFormation

この記事の目次
  1. この範囲の全体像
  2. 重要キーワード・サービス一覧
  3. 試験で問われる比較ポイント
  4. ひっかけ注意ポイント
  5. 一問一答セルフテスト

1. 【この範囲の全体像】

本範囲（第12章12-4、p.279-283）は、AWSにおけるガバナンス、コンプライアンス監査、および構成追跡の中核をなす 「 AWS CloudTrail 」 と 「 AWS Config 」 を扱います [p.279, p.281, passage 245]。

システムを安全に運用するためには、「誰がいつ何をしたか（API操作監査）」 [p.279, passage 245]、および「リソースが今どう設定されているか（構成状態監査）」を継続的に記録することが必須です [p.281, passage 245]。

試験では、トラブル時の原因究明や法的監査要件を満たすために、CloudWatch（パフォーマンス）、CloudTrail（API）、AWS Config（リソース構成）をいかに正しく設計・使い分けるかが問われます [passage 245, passage 247]。

2. 【重要キーワード・サービス一覧】

キーワード 説明
AWS CloudTrail [p.279, passage 245] AWSアカウント内で実行されたすべてのユーザー、ロール、またはAWSサービスによる「API操作（アクション）履歴」を証跡として継続レコーディングする監査サービス [p.279, passage 245]。
管理イベント (Management Events) [p.279] AWSアカウント内のリソースに対して実行される管理操作（例：EC2インスタンスの作成・終了、VPCの設定変更など）を記録するイベント。デフォルトで有効化されています。
データイベント (Data Events) [p.279] リソース内またはリソース間で実行される高頻度なデータ操作（例：Amazon S3バケットへのオブジェクトアップロード、AWS Lambda関数の実行など）を記録するイベント。デフォルトではオフになっており、ログ収集を有効にするには明示的な追加設定が必要です。
AWS Config [p.281, passage 245] AWSアカウント内のリソースが「過去から現在にわたってどのように構成・接続されていたか」を時系列でレコーディングし、設定履歴を追跡・監査する構成管理サービス [p.281, passage 245]。
AWS Config ルール (Config Rules) [p.282] AWSリソースの設定状態があるべき「安全なルール」に合致しているかどうかを自律的に自動評価する機能 [p.281, p.282]（例：「S3バケットのパブリック読み取りアクセスが禁止されているか」など） [p.282]。
自動是正 (Automatic Remediation) [p.282, passage 245] AWS Config ルールによってリソースの設定違反（準拠していない状態）を検知した際、AWS Systems Managerの自動化ドキュメント（SSMランブック）などをフックして、自動的に安全な設定へ強制修正（セルフヒーリング）するアクション [passage 245]。

3. 【試験で問われる比較ポイント】

運用ガバナンス3大サービスの使い分け：CloudWatch vs CloudTrail vs AWS Config [passage 245]

「トラブルが発生した際、何を知りたいか（シグナルキーワード）」によって、マッピングすべきサービスが完全に1対1で決まります [passage 245, passage 247]。

比較項目 Amazon CloudWatch [passage 245] AWS CloudTrail [passage 245] AWS Config [passage 245]
主な監視対象 リソースの 「 パフォーマンスデータ 」 やアプリケーションの 「 生ログ 」 [passage 245]。 ユーザーやシステムが実行した 「 APIの実行履歴（活動証跡） 」 [passage 245]。 各リソースの 「 構成情報（パラメータ設定） 」 および関連性 [passage 245]。
主目的 パフォーマンス低下やエラー、システム死活の監視とアラート [passage 245]。 「誰が、いつ、どこから、どのような操作」を行ったかの監査（責任追跡） [passage 245, passage 247]。 設定変更履歴の追跡（タイムライン監査） と、安全ルールの自動適合性評価 [passage 245, passage 247]。
トラブル時の解決の問い 「 現在、何が（高負荷、エラーなどで）起きているか？ 」 「 このEC2を物理的にシャットダウン（削除）した犯人は誰か？ 」 [passage 247] 「 セキュリティグループの設定が、昨日と比べてどう変わって（乖離して）しまったか？ 」 [passage 247]
主な連携アクション SNSによるアラーム通知、EC2自動復旧、Auto Scaling [passage 228, passage 245]。 S3バケットへの証跡ログの安全な保管、CloudWatch Logsへの転送。 非準拠リソースに対する Systems Manager を介した「自動是正（修復）」 [passage 245]。

4. 【ひっかけ注意ポイント】

  • ひっかけ①：「『S3バケット内の特定の機微データが、昨日外部に不正ダウンロードされたのではないか』という漏洩疑いが発生した。直ちに監査チームを稼働させ、標準のCloudTrailを有効化していた監査ログの履歴を検索したが、対象オブジェクトに対するGET操作ログが1行も見つからなかったため、安全であると結論づけた。」

    • 真実: 標準のCloudTrail設定（管理イベントのみ）では、S3バケット内部のオブジェクト操作履歴は一切記録（レコーディング）されません。
    • 理由: S3オブジェクトに対する読み書きやLambdaのキック操作などは「データイベント（Data Events）」に分類されるためです。これらはデータ転送量が非常に膨大になるため、デフォルトのCloudTrailでは意図的にオフ（未収集）となっています。
    • 対策: 「特定のS3バケットに対するダウンロード監査履歴を完全に記録・証明したい」という要件（セキュリティ・監査コンプライアンス）が出た場合は、必ずCloudTrailの設定画面で 「 データイベント（S3データアクセス） 」 を明示的にオンにするマッピングを選択してください。

  • ひっかけ②：「社内の開発者が誤って本番セキュリティグループのSSHポート（22）を世界中（0.0.0.0/0）に全解放してしまった。この重大なセキュリティルール違反を即座にシステム的に自動検知し、かつ手動操作を一切挟まずに元の安全なポート閉鎖状態へ即座に強制修正（セルフヒーリング）したい。これを実現するため、CloudTrailでAPIイベントを検知するCloudWatchアラームを設計した。」

    • 真実: API実行の検知（CloudTrail）だけでは、元の状態に戻す「自動設定是正」の仕組みを最小限のオーバーヘッドで構築することはできません [passage 245]。
    • 理由: CloudTrailはあくまで「APIが実行された」というイベントを記録する監査サービスであり、設定そのものの是非を評価したり、設定状態を元に巻き戻す自律機能は持っていないためです [passage 245]。
    • 対策: 「現在のリソース設定をポリシーと比較し、違反があったリソースを自動で安全な状態に是正（Automatic Remediation） させたい」という要件に対しては、必ず 「 AWS Config（AWS Configルール ＋ Systems Manager 自動是正アクション） 」 のアーキテクチャを選定してください [p.282, passage 245]。

5. 【一問一答セルフテスト】

選択肢を選ぶと、その場で正誤と解説が表示されます。