2026-09-14（月）CloudWatch, CloudFormation
1. 【この範囲の全体像】
本範囲（第12章12-1・12-2前半、p.262-268）は、AWSにおけるシステム運用のガバナンス、監視、およびインフラの自動化（Infrastructure as Code：IaC）の基礎を学びます [p.262, p.264]。
特に、テンプレートという「設計図」から実際のインフラ環境である「スタック」を一括自動構築する AWS CloudFormation の基本仕様と [p.264, p.265]、不要になったインフラを安全に破棄・更新する際のデータ保護設計（DeletionPolicy など）が試験における最大のターゲットです [p.245, p.248]。
手動操作を排除し、コードによる再現可能で安全なインフラ運用（運用の優秀性）をいかに確立するかという、クラウド設計の根幹思想を理解することが求められます [p.245]。
2. 【重要キーワード・サービス一覧】
| キーワード | 説明 |
|---|---|
| 運用支援サービス (Management & Governance) [p.262] | システムの監視、プロビジョニング、変更管理、コンプライアンス監査などを一元的にサポートし、システムの安定運用とガバナンス統制を両立させるためのAWSサービス群 [p.262]。 |
| AWS CloudFormation [p.264] | JSONやYAML形式のテキストファイルで定義されたインフラ設計図を読み込み、VPC、EC2、RDSなどのAWSリソース群を完全自動で一括デプロイ・管理するIaC（Infrastructure as Code）サービス [p.264, p.265]。 |
| テンプレート (Template) [p.265] | インフラの「あるべき構成」をテキスト（YAML/JSON）で記述したコードファイル [p.265]。どのリソースを、どのような設定値や依存関係で作成するかを宣言します [p.265]。 |
| スタック (Stack) [p.264] | CloudFormationのテンプレートに基づいて作成される、関連するAWSリソース群の「1つのグループ（論理的な集まり）」 [p.264]。リソースの作成、更新、削除はすべてこのスタック単位で一元管理されます [p.264]。 |
| DeletionPolicy (削除ポリシー) [p.245, p.248] | CloudFormationテンプレート内で定義される重要なリソース保護属性 [p.245]。スタックが削除される際、データベース（RDS）やストレージ（S3）などのデータ実体を「一緒に消す（デフォルト）」か、「消さずに残す（Retain）」か、「削除直前にバックアップをとる（Snapshot）」かを制御します [p.245, p.248]。 |
| Change Sets (変更セット) [p.245, p.248] | 稼働中のスタックに対してテンプレートの変更を適用する前に、どのようなリソースが新規追加・変更・または「再作成（物理的な一度の削除：Replacement）」されるかを事前にプレビュー確認できる安全確認機能 [p.245, p.248]。 |
3. 【試験で問われる比較ポイント】
① CloudFormation インフラ管理の単位：テンプレート vs スタック [p.264-265]
「設計図（論理コード）」と「デプロイされた実体（物理リソース）」の関係性を厳密に区別します [p.264, p.265]。
| 比較項目 | テンプレート (Template) [p.265] | スタック (Stack) [p.264] |
|---|---|---|
| 実態定義 | YAMLまたはJSON形式のテキストファイル [p.265]。 | 実際にAWS上にプロビジョニングされたアクティブなリソースの集合体 [p.264]。 |
| 役割と特徴 | インフラの「構成仕様」を静的に記述する設計図。Git等のバージョン管理が可能。 | テンプレートを実行して起動された、本番や開発などの「稼働環境」そのもの [p.264]。 |
| ライフサイクル操作 | 記述を書き換えることで、変更履歴（コード差分）を管理する。 | 作成（Create）、更新（Update）、削除（Delete）などの物理的なアクションが適用される [p.264]。 |
| データ永続性への配慮 | DeletionPolicy などのライフサイクル属性をリソースごとにあらかじめ記述する [p.245, p.248]。 |
スタックを丸ごと削除すると、デフォルトでは配下のリソースおよび内部データも連動して一斉に消滅する [p.245, p.248]。 |
| 試験での出題意図 | 「同一構成のマルチアカウント/マルチリージョン環境をコードで標準化して配布したい（StackSetsの活用）」 [p.245]。 | 「 一時的な開発検証スタックを、検証終了後に一括して自動破棄（削除）して、無駄な課金を1クリックで止めたい 」 [p.264]。 |
4. 【ひっかけ注意ポイント】
ひっかけ①：「開発環境をCloudFormationで作成した。この中にはデータベース（RDS）や画像保管用のS3バケットが含まれている。検証が終わったため、不要なコストの発生を防ぐ目的でCloudFormationからスタックの削除（Delete Stack）を実行した。特別な追加設定を行っていなかったが、スタックが消えてもRDSのデータベースボリュームやS3バケット内のデータ実体はAWS上に安全に自動保管され続ける。」
- 真実: データ実体は連動して即時かつ完全に自動消去（物理削除）され、復旧不能になります [p.245, p.248]。
- 理由: CloudFormationのデフォルト仕様として、スタックを削除すると、その中に含まれるすべてのAWSリソースは連動して一括物理削除されるためです [p.245, p.248]。
- 対策: 本番データベースやストレージなどの「絶対に道連れで消したくない永続リソース」を保護するためには、テンプレート内に明示的に DeletionPolicy: Retain（スタック削除時もリソースを残す）または DeletionPolicy: Snapshot（削除直前にスナップショットを取得する）を記述しておくことが、高可用性・運用の優秀性を高めるための絶対的な鉄則です [p.245, p.248]。
ひっかけ②：「稼働中の本番Webシステム環境のCloudFormationスタックに対し、EC2インスタンスのスペック変更や新規リソースの追加デプロイを行うため、書き換えたテンプレートファイルをそのまま直接本番スタックに『適用（Update Stack）』した。何が起こるか事前予測できないが、エラーがあれば自動でロールバックされるため、適用前の影響分析（リソースの再作成に伴う一時的な物理削除・データ消失の有無）は行う必要がない。」
- 真実: 非常に危険な運用アンチパターンです。特定のプロパティ変更は 「 リソースの再作成（Replacement：古いインスタンスが一度物理的に削除され、新しいものが新設される） 」 を引き起こし、深刻なサービス中断やデータ消失を招きます [p.245, p.248]。
- 理由: データベースや静的ストレージなどのプロパティ変更の中には、稼働状態のまま「インプレース更新」できず、一度リソースを物理削除して再生成しなければ設定を反映できないものが多数存在する仕様があるためです [p.245, p.248]。
- 対策: インフラの更新を行う際は、直接デプロイを走らせる前に、必ず 「 変更セット（Change Sets） 」 を作成・実行し、どのリソースが追加、修正、あるいは「Replacement（再作成に伴う消失）」されるかをプレビュー画面で事前に完璧に確認・検証するプロセスを敷きます [p.245, p.248]。
5. 【一問一答セルフテスト】
選択肢を選ぶと、その場で正誤と解説が表示されます。