2026-09-15（火）CloudWatch, CloudFormation

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

本範囲（第12章12-2後半、p.269-272）は、AWS CloudFormationを用いたインフラストラクチャの「詳細な設計・制御ロジック」および「高度なデプロイ運用機能」を扱います [p.264]。

特に、テンプレート内で異なるリソース間の参照や物理的な構築順序を制御する組み込み関数（Ref や Fn::GetAtt）の使い分け [p.265]、更新エラー時におけるトランザクション制御（自動ロールバック）挙動、そして複数アカウント・複数リージョンへの一元デプロイを可能にする「StackSets」の設計仕様が最重要ターゲットです [passage 245]。

コードでインフラをただ構築するだけでなく、安全に変更・展開するためのライフサイクル仕様を深く理解することが求められます [passage 245]。

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

キーワード	説明
Resources（リソース）セクション [p.265]	テンプレート内で、実際に作成・プロビジョニングする具体的なAWSリソース（VPC、EC2、S3など）を宣言する、テンプレート内で唯一必須となる中核セクション [p.265]。
Outputs（出力）セクション [p.265]	スタックの構築完了後、作成された特定リソースの動的な属性値（例：ALBのDNS名、EC2のIPアドレスなど）をコンソール画面に表示させたり、他のスタックへ引き渡すために「エクスポート」するセクション [p.265]。
組み込み関数（Intrinsic Functions） [p.265]	テンプレート内で、他のリソースのIDや特定の詳細属性値を動的に参照・取得するための特殊な記述法（代表例：`Ref`, `Fn::GetAtt`） [p.265]。
Ref（参照） [p.265]	指定したリソースの「論理ID」をパラメータとして渡し、そのリソースを代表するデフォルト値（EC2であればインスタンスID、S3であればバケット名など）を動的に返す最も基本的な組み込み関数 [p.265]。
Fn::GetAtt（属性取得） [p.265]	指定したリソースが持つ「特定の個別属性（Attribute）」（例：S3バケットの「ARN（Amazon Resource Name）」、あるいはEC2の「プライベートIPアドレス」など）を細かく指定してピンポイントで取得する関数 [p.265]。
DependsOn 属性 [p.265]	AWSリソースが構築される「物理的な順番」を厳密に制御するための属性。特定リソース（例：データベース用のRDS）のプロビジョニング完了後に、別リソース（例：AP用のEC2）の作成プロセスを開始させたいといった依存境界をデプロイエンジンに命令する。
AWS CloudFormation StackSets	`[passage 245]`: 単一のCloudFormationテンプレートを元に、AWS Organizations内の複数のAWSアカウントや複数のリージョンに対して、並列で同じインフラ（スタック）を一貫して一括デプロイ・管理できるエンティティガバナンス機能 [p.179, passage 245]。

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

① 組み込み関数の決定的な仕様境界：Ref vs Fn::GetAtt [p.265]

「リソースを指し示すデフォルトの物理名（ID）が欲しいか」それとも「特定の詳細な属性情報が欲しいか」で厳密に使い分けます [p.265]。

比較項目	Ref（基本参照関数） [p.265]	Fn::GetAtt（属性指定関数） [p.265]
返却される値	そのリソースのデフォルトの識別子。（例：EC2なら `i-12345678`、S3なら `bucket-name`） [p.265]。	そのリソースの特定の詳細な属性（Attribute）。（例：EC2の「AvailabilityZone」、S3の「Arn」） [p.265]。
記述形式	`Ref: LogicalID`	`Fn::GetAtt: [ LogicalID, AttributeName ]`
主な使用目的	作成したサブネットIDやセキュリティグループIDなどを、そのまま他のリソースへ直接引き渡したいとき [p.265]。	他のリソースへの認可ポリシー（IAM）を記述する際、S3バケット名ではなく「 S3バケットのARN（arn:aws:s3:::...）」を正確に取得してマッピングしたいとき [p.265]。

② 大規模マルチデプロイの境界線：StackSets vs 複数リージョンでの通常デプロイ `[passage 245]`

比較項目	複数リージョンでの通常デプロイ	AWS CloudFormation StackSets `[passage 245]`
管理モデル	各アカウント・各リージョンごとにテンプレートファイルを個別にアップロードし、手動または独自スクリプトで逐次適用する。	管理（管理者）アカウントから一元管理。ターゲットのアカウントIDとリージョンを指定し、並列で自動的に同一のインフラプロビジョニングを走らせる `[passage 245]`。
組織との連動	新たな子アカウントが追加された際、手動で同様の環境をイチから構築し直す必要がある。	AWS Organizationsとシームレスに統合。指定したOU（組織単位）に新しいアカウントが参加すると、自動的に必要な共通初期スタック（セキュリティ設定など）が追加プロビジョニングされる [p.179, passage 245]。
主な試験適用シナリオ	独立した少数のVPC/EC2環境を、東京リージョン内でのみ構成・管理したい場合 [p.264]。	「企業のマルチアカウント環境において、すべての既存アカウントおよび将来追加されるすべての子アカウントの全リージョンに対して、共通のセキュリティグループルールやIAMロールを完全に同じ状態で一元自動デプロイしたい」 [p.179, passage 245]。

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

ひっかけ①：「別リソースとの依存関係を制御するため、EC2にIAMロール（インスタンスプロファイル）をマウントさせた。EC2の起動処理が走る前に、IAMロールの作成が100%完了していることを保証するため、組み込み関数『Ref』を用いてEC2からIAMロールの論理IDを参照させた。これだけで、CloudFormationは必ずIAMロールのプロビジョニングが完了した後に、EC2の作成プロセスをキックする。」
- 真実: 単なる Ref や Fn::GetAtt による値の動的参照だけでは、物理的な「リソース構築完了の順序」を完全に担保することはできません [p.265]。
- 解決理由: CloudFormationはデプロイの処理効率を極限まで引き上げるため、論理的なデータ依存がないと判定されたリソース構築を可能な限り「並列（同時）」に走らせます [p.265]。そのため、値の参照エラーは起きなくても、裏側でIAMロールの作成APIが完了する前にEC2の作成APIが呼び出されてしまい、「認証情報が適用できない」という実行時デプロイ失敗エラーを招きます。
- 対策: 「リソースAの作成が完全に完了したことを確認してからリソースBの作成を開始する」という厳密な順序依存を課したい場合は、必ず対象リソースに DependsOn 属性（例：DependsOn: MyIAMRole） を明示的に追記してデプロイエンジンに命令しなければなりません [p.265]。
ひっかけ②：「本番環境のインフラスタックをCloudFormationテンプレートの更新によってアップデートした。その際、特定のパラメータ設定変更を行ったが、定義の記述ミスによりスタックの更新プロセス自体が途中でエラーとなり、デプロイが異常終了した。この場合、スタック全体は中途半端に更新された状態で停止するため、手動で手戻り作業を行わなければインフラは正常な以前の状態に戻らない。」
- 真実: 手動による手戻り復旧作業は一切不要であり、CloudFormationが自動的に完全に以前の安定した状態へとロールバック（巻き戻し）を実行します [passage 245]。
- 解決理由: CloudFormationには厳格なトランザクション整合性があり、スタックの更新が途中で失敗した場合、「 自動ロールバック（Rollback） 」が標準で発動するためです [passage 245]。更新によって作成中だった不完全なリソースは自動削除され、変更された設定値はアップデートを開始する直前の安全なオリジナル状態へと完全に自動復元されるため、システムを不安定な状態で放置することはありません [passage 245]。