2026-09-18（金）CloudWatch, CloudFormation
1. 【この範囲の全体像】
本範囲（第12章、p.12, p.261-262）は、AWS環境の「高可用性・耐障害性」および「運用の優秀性（ガバナンスと自動化）」を担保するための監視、構成コード化、そして監査サービス群を統合して扱います [p.12, p.245, p.261]。
システムのパフォーマンス変化を監視しエラーを検知・自動復旧させる 「 Amazon CloudWatch 」 [p.245]、インフラ全体を設計図（テンプレート）から安全かつ再現可能なコードとして自動管理する 「 AWS CloudFormation 」 [p.245]、そして運用操作と設定変更を漏れなく追跡する 「 CloudTrail 」 と 「 AWS Config 」 の機能境界を完全に理解し、ベストプラクティス設計を身につけることが本試験攻略の鍵です [p.245, p.247]。
2. 【重要キーワード・サービス一覧】
| キーワード | 説明 |
|---|---|
| Amazon CloudWatch [p.12, p.245] | システムの「パフォーマンスデータ（メトリクス）」や「生ログ」を収集・可視化・監視し、しきい値超過をトリガーに自動復旧（SNS通知やAuto Scaling）を行うサービス [p.245, p.247]。 |
| CloudWatch Agent [p.245] | ゲストOS内部のメモリ使用率、ディスク空き容量、システム生ログといった「ハイパーバイザー（マシンの外側）からは見えないプライベートな内部データ」を取得するためにEC2内部にインストールする専用プログラム [p.245, p.247]。 |
| AWS CloudFormation [p.12, p.245] | YAMLやJSON形式のテキストファイル（テンプレート）を読み込んで、関連する複数のAWSリソース群（スタック）を完全自動で一括構築・更新管理できるIaC（Infrastructure as Code）サービス [p.245, p.248]。 |
| DeletionPolicy (削除ポリシー) [p.245, p.248] | スタックが削除される際、RDSデータベースやS3バケット内の「データ実体」を道連れで自動消去させず、「残す（Retain）」か「削除直前にバックアップをとる（Snapshot）」かをリソースごとに明示指定して保護する属性 [p.245, p.248]。 |
| Change Sets (変更セット) [p.245, p.248] | 稼働中のスタックに対してテンプレートの更新を適用する前に、どのようなリソース変更や再作成（Replacement：一度削除されて新設されるリスク）が発生するかを事前にプレビュー確認できる安全確認機能 [p.245, p.248]。 |
| Drift Detection (ドリフト検出) [p.245] | CloudFormationのテンプレート（コード）を通さず、手動でAWSコンソールなどから直接実行されてしまった「期待する構成状態と物理リソースの設定乖離（ズレ）」を自動スキャンして可視化する機能 [p.245]。 |
| AWS CloudFormation StackSets [p.12, p.245] | AWS Organizations配下のマルチアカウントやマルチリージョンに対して、親アカウントから単一のテンプレートを用いて同一のインフラ構成を並列で一元自動配布・デプロイできるエンタープライズ機能 [p.179, p.245]。 |
| AWS CloudTrail [p.12, p.245] | AWSアカウント内で行われたすべての「操作（APIアクション）履歴」を記録する活動監査サービス [p.245, p.247]。誰が、いつ、どこから、何のAPIを叩いたかという「責任追跡」に利用される [p.247]。 |
| AWS Config [p.12, p.245] | AWS上の各種リソースの設定情報を時系列でレコーディングし、設定変更履歴のタイムライン追跡や、セキュリティグループ変更などの「安全ルール適合性」を自動監査・追跡する構成管理サービス [p.245, p.247]。 |
3. 【試験で問われる比較ポイント】
① 監視レイヤーの境界線：標準メトリクス vs CloudWatch Agent [p.245, p.247]
「責任共有モデル」に基づき、ハイパーバイザー側から直接覗き見ることができる物理的なデータと、OS内部のプライベート空間のデータの違いを厳密にマッピングします [p.245, p.247]。
| 比較項目 | 標準メトリクス（外側の監視） [p.245, p.247] | CloudWatch Agent（OS内部のカスタム監視） [p.245, p.247] |
|---|---|---|
| 監視対象領域 | マシンの外側（ハイパーバイザー層） [p.245, p.247]。 | マシンの内側（ゲストOS内部） [p.245, p.247]。 |
| 主な取得項目 | ・CPU使用率 （CPUUtilization） ・ネットワークI/O （通信パケット量） ・物理ディスクI/O （ディスクの物理読み書き） ・ステータスチェック （物理ハードウェア/仮想インスタンスの死活） [p.245, p.247]。 |
・メモリ使用率 （MemoryUtilization） ・ファイルシステムごとのディスク空き容量 ・ゲストOS内・アプリ内の詳細生ログ [p.245, p.247]。 |
| エージェントの導入 | 不要（リソース作成時からAWSにより完全自動で収集） [p.245]。 | 必須（対象のEC2内部へ明示的にインストールとパラメータの起動設定が必要） [p.245, p.247]。 |
| 試験での選定シグナル | 「特別なインフラ管理工数をかけることなく、WebサーバーのCPU負荷上昇をトリガーにAuto Scalingをキックしたい」 [p.245]。 | 「 OS内部のメモリ消費量が激しくなってエラーが起きるのを防ぐため、メモリ使用率を常に監視して通知するアラームを設計したい 」 [p.245, p.247]。 |
② 運用管理3大サービスの使い分け：CloudWatch vs CloudTrail vs AWS Config [p.245]
トラブルや法的監査のシーンが発生した際、「 何を知りたいか（問い） 」 によって、マッピングすべきサービスは完全に1対1で決まります [p.245, p.247]。
| 比較項目 | Amazon CloudWatch [p.245] | AWS CloudTrail [p.245] | AWS Config [p.245] |
|---|---|---|---|
| 監視のコア目的 | リソースの「動作性能・健康状態（パフォーマンス）」やシステム生ログの監視 [p.245, p.247]。 | ユーザーやシステムが実行した「API呼び出し（操作）履歴」の記録監査 [p.245, p.247]。 | AWSリソースの「設定情報パラメータの記録」および「構成の整合性監査」 [p.245, p.247]。 |
| 解決したい問いの例 | 「 現在、Webアプリケーションが高負荷により応答遅延を起こしていないか？ 」 [p.245] | 「 昨日の深夜2時、稼働中だった本番EC2インスタンスをシャットダウンした犯人は誰か？ 」 [p.247] | 「 現在のセキュリティグループのSSH解放ポート状況が、昨日から勝手に書き換えられていないか？ 」 [p.247] |
| 主なターゲット | CPU、メモリ、ログデータ内の特定の「エラーキーワード」検出など [p.245, p.247]。 | 操作の実行者（IAMユーザー/ロール）、実行日時、接続元IP、実行API名 [p.245, p.247]。 | セキュリティグループ、VPC、S3のパブリック設定など「リソース自体の設定値のズレ」 [p.247]。 |
4. 【ひっかけ注意ポイント】
ひっかけ①：「一時的な開発環境をCloudFormationからスタック削除（Delete Stack）した。スタックが削除されても、その中で動いていたRDSデータベースのデータ実体やS3バケットの画像ログデータは、AWS側が気を利かせてAWSアカウント上に安全に自動残存・保存してくれる。」
- 真実: データ実体は問答無用で即時かつ完全に自動消去（物理削除）され、絶対に復旧不可能になります [p.245, p.248]。
- 解決理由: CloudFormationの標準（デフォルト）のライフサイクル仕様として、スタック全体を削除すると、その論理グループ配下にあるすべての物理リソースもろとも連動削除されるためです [p.245, p.248]。
- 対策: 本番データベースなどの「絶対に道連れで消されては困る重要な永続データリソース」に対しては、テンプレート内に必ず DeletionPolicy: Retain（データを消さずにリソースとして残す） または DeletionPolicy: Snapshot（削除直前にバックアップを取得する） を明示的に指定しておく設計が絶対基準となります [p.245, p.248]。
ひっかけ②：「稼働中の本番システム環境を管理するCloudFormationテンプレートのパラメータ変更を行うため、更新されたテンプレートファイルをそのまま『スタックの更新（Update Stack）』にアタッチして適用した。変更エラーがあれば自動で以前の状態に安全にロールバック（巻き戻し）されるため、デプロイ前に事前の影響度をプレビュー検証する必要はない。」
- 真実: 更新によって物理的な 「リソースの再作成（Replacement：リソースを一度物理削除してから新しい設定で再構築する仕様）」が走り、重大なシステム停止や永続データの不意な消失を招く深刻なアンチパターンです [p.245, p.248]。
- 解決理由: データベースや静的ストレージなどのパラメータ設定の中には、稼働中のインプレース（無停止）更新が仕様上できず、リソースを完全に一度消してからではないと再デプロイできない属性が多数存在するからです [p.245, p.248]。
- 対策: 本番スタックの更新を走らせる前に、何が追加・変更されるか、あるいは Replacement のリスクが伴うリソースがあるかを、視覚的に事前に安全確認できる 「 変更セット（Change Sets） 」 を必ず作成し、プレビューをクリアしてからデプロイの実行判断を行うプロセスが必須です [p.245, p.248]。
5. 【一問一答セルフテスト】
選択肢を選ぶと、その場で正誤と解説が表示されます。