【DOP-C02/SAP-C02】CloudFormation徹底解説：概要・主要機能・試験で問われるポイント

この記事の位置づけ

AWS 認定 DevOps Engineer – Professional（DOP-C02）と Solutions Architect – Professional（SAP-C02）で頻出する 3 領域を「概要 → 主要機能 → 試験で問われるところ」の順に深掘りするシリーズの第 2 回です。

回	テーマ
第 1 回	Code シリーズ（CodePipeline / CodeBuild / CodeDeploy / CodeArtifact ほか）
第 2 回（本記事）	CloudFormation
第 3 回	Control Tower

試験の基本情報（75 問・180 分・合格 750 点・300 USD）は第 1 回と共通です（DOP 公式ページ、SAP 公式ページ）。

SAP-C02 → SAP-C03 の切り替えに注意
SAP の公式ページには「SAP-C03 の登録受付は 2026 年 10 月 27 日に開始、SAP-C02 の最終受験日は 2026 年 11 月 16 日」と掲示されています（2026-10-20 時点）。本記事は SAP-C02 の試験ガイドに基づきます。

本文の仕様は公式ドキュメント（2026 年 10 月時点）で確認し、出典 URL を付けています。確認しきれなかった記述は末尾にまとめました。

0. 試験ガイドでの位置づけ

DOP-C02 では分野 2「構成管理と IaC」（17%）が中心です（DOP-C02 試験ガイド）。

タスク	内容	CloudFormation の論点
2.1	ライフサイクル全体でシステムをプロビジョニング・管理するためのインフラと再利用可能なコンポーネントの定義	テンプレート設計、ネスト／クロススタック、モジュール、CDK / SAM との関係
2.2	マルチアカウント・マルチリージョンでアカウントを作成・オンボード・保護する自動化のデプロイ	StackSets、Organizations 連携、Control Tower
2.3	複雑なタスクと大規模環境向けの自動化ソリューションの設計と構築	カスタムリソース、マクロ、Hooks、ドリフト

分野 1「SDLC の自動化」（CodePipeline の CloudFormation アクション）、分野 3（デプロイの回復性：UpdatePolicy、ロールバック）、分野 6（IAM 条件キー、Hooks によるガードレール）にもまたがります。

SAP-C02 では分野 1「組織の複雑さに対応する設計」（26%）のタスク 1.4「マルチアカウント AWS 環境の設計」（複数アカウントへの IaC 配布として StackSets が関わる）、分野 2「新しいソリューションのための設計」（29%）のタスク 2.1「デプロイ戦略」（知識項目に IaC として CloudFormation が明記）、分野 3「既存ソリューションの継続的改善」（25%）の運用自動化で登場します（SAP-C02 試験ガイド）。両試験とも対象サービス一覧（Management and Governance）に CloudFormation が含まれています。DOP の一覧には AWS CDK（Developer Tools）と AWS SAM（Serverless）も載っており、分野 2 のタスク 2.1 のスキルに「SAM / CloudFormation / CDK による IaC テンプレートの作成とデプロイ」が明記されています（DOP-C02 対象サービス一覧、分野 2）。SAP の一覧には CDK と SAM は載っていません（SAP-C02 対象サービス一覧。一覧は「網羅的ではない」と注記）。

1. 概要

CloudFormation は テンプレート（JSON / YAML）に書いたリソース定義から、スタックという単位でリソースを作成・更新・削除する サービスです。依存関係の解決、失敗時のロールバック、変更の差分表示（変更セット）、複数アカウント・リージョンへの展開（StackSets）を担います。CloudFormation 自体は無料で、作成したリソースの料金だけがかかります（レジストリのサードパーティ拡張や Hooks には別途課金があります）。

スタック操作の流れは次のとおりです。

1. テンプレートとパラメータを渡してスタックを作成（CREATE_IN_PROGRESS → CREATE_COMPLETE）。失敗すると既定ではロールバック（ROLLBACK_COMPLETE）
2. 更新は「直接更新」か「変更セットの作成 → 確認 → 実行」。失敗すると UPDATE_ROLLBACK_IN_PROGRESS → UPDATE_ROLLBACK_COMPLETE
3. 削除はスタック内のリソースを依存関係の逆順に削除（DeletionPolicy で残す・スナップショットを取ることも可能）

スタックはリージョン単位のリソースです。同じテンプレートを複数リージョン・複数アカウントに配るのが StackSets です。

2. 主要機能（1）テンプレート構文

テンプレートのセクション

テンプレートの構造 より。必須なのは Resources だけです。

セクション	役割
AWSTemplateFormatVersion	テンプレート形式のバージョン（2010-09-09 のみ）
Description	説明（最大 1,024 バイト）
Metadata	テンプレート全体の追加情報。AWS::CloudFormation::Interface（コンソールでのパラメータのグループ化と表示順）など。cfn-init 用の AWS::CloudFormation::Init はここではなく 各リソースの Metadata 属性 に書く（AWS::CloudFormation::Init）
Parameters	実行時に渡す値（最大 200 個）
Rules	パラメータの組み合わせの検証（アサーション）
Mappings	固定のルックアップ表（例：リージョン → AMI ID）。Fn::FindInMap で参照
Conditions	条件（例：本番かどうか）。リソースや出力の作成可否、Fn::If で値を切り替える
Transform	マクロ。AWS::Serverless-2016-10-31（SAM）、AWS::Include、AWS::LanguageExtensions、自作マクロ
Resources	必須。作成するリソース
Outputs	出力値（最大 200 個）。Export で他スタックから参照可能にする

組み込み関数と疑似パラメータ

組み込み関数リファレンス の中で、試験で意味を問われるものです。

関数	用途
Ref	パラメータの値、またはリソースの ID（物理 ID）を返す
Fn::GetAtt	リソースの属性（ARN、DNS 名など）を返す
Fn::Sub	文字列に ${Var} を埋め込む（Fn::Join より読みやすい）
Fn::Join / Fn::Split / Fn::Select	文字列やリストの結合・分割・選択
Fn::FindInMap	Mappings の参照
Fn::If / Fn::Equals / Fn::And / Fn::Or / Fn::Not	条件
Fn::ImportValue	他スタックの Export 値を取り込む（同一アカウント・同一リージョン）
Fn::GetStackOutput	他スタックの出力を Export なし・クロスアカウント・クロスリージョン で参照する（弱い参照、作成・更新時に解決、パーティション越えは不可）。クロスアカウントでは参照先アカウントに cloudformation:DescribeStacks を許可したロールを作り、参照元スタックの実行ロールからの sts:AssumeRole を信頼ポリシーで許可して RoleArn に指定する（リファレンス）
Fn::GetAZs	リージョンの AZ 一覧
Fn::Cidr	CIDR の分割
Fn::Base64	ユーザーデータのエンコード
Fn::Transform	スニペット単位でマクロを呼ぶ
Fn::ForEach / Fn::Length / Fn::ToJsonString	AWS::LanguageExtensions 変換で使える。Fn::ForEach はリソースやプロパティの繰り返し生成（Fn::ForEach）

疑似パラメータは AWS::AccountId、AWS::Region、AWS::StackName、AWS::StackId、AWS::Partition、AWS::URLSuffix、AWS::NotificationARNs、AWS::NoValue（プロパティを「指定しない」扱いにする）です。

パラメータ

Parameters セクション より。

• 型：String、Number、List<Number>、CommaDelimitedList、AWS 固有型（AWS::EC2::VPC::Id、AWS::EC2::KeyPair::KeyName など。存在するリソースかどうかを検証 してくれる）、SSM パラメータ型
• SSM パラメータ型（AWS::SSM::Parameter::Value<String> など）：パラメータ名を渡すと、スタック操作時に Parameter Store から 最新の値 を取得する。SecureString はこの方法では使えない（動的参照を使う）
• NoEcho: true でコンソールや API の出力にマスクをかける
• AllowedValues、AllowedPattern、MinLength などの制約、Default
• Rules セクションで「環境が prod なら特定のインスタンスタイプのみ」のような パラメータの組み合わせ を検証できる（Rules）

動的参照（Dynamic References）

秘密情報をテンプレートやパラメータに書かずに参照する仕組みです（動的参照）。1 テンプレートあたり最大 60 個です。

パターン	書き方	特徴
ssm	{{resolve:ssm:パラメータ名:バージョン}}	平文パラメータ。バージョン省略時は作成・更新時点の最新値
ssm-secure	{{resolve:ssm-secure:パラメータ名:バージョン}}	SecureString。CloudFormation は値を保存しない。対応するリソースプロパティでのみ使える。変更セットは文字列そのものを比較し、値の変化を検出しない
secretsmanager	{{resolve:secretsmanager:シークレットID:SecretString:JSONキー:バージョンステージ:バージョンID}}	Secrets Manager。SecretString のみ対応

ssm-secure と secretsmanager はカスタムリソースでは使えません。参照は スタックの作成・更新時に解決される ので、シークレットのローテーション後に新しい値を反映するには、その参照を含むリソースを更新するスタック更新が必要です。

引っかけ（テンプレート構文）

• 「DB パスワードを安全に渡す」→ NoEcho パラメータより Secrets Manager / ssm-secure の動的参照 が正解になりやすい（テンプレートにもパラメータ履歴にも値が残らない）
• SSM パラメータ型は SecureString 非対応。SecureString を使うなら動的参照
• Fn::ImportValue は 同一アカウント・同一リージョン限定。クロスアカウント／クロスリージョンなら Fn::GetStackOutput（または SSM パラメータ経由の受け渡し）
• Transform を含むテンプレートの直接作成・更新には CAPABILITY_AUTO_EXPAND が必要。変更セット経由なら展開後のテンプレートを確認できる
• IAM リソースを含むテンプレートには CAPABILITY_IAM、名前付き IAM リソースには CAPABILITY_NAMED_IAM が必要。「InsufficientCapabilities エラー」の原因

3. 主要機能（2）リソース属性と更新の挙動

ここが DOP で最も細かく問われる部分です。

DependsOn

リソース作成順序を明示します。Ref や Fn::GetAtt で参照していれば暗黙の依存関係ができますが、参照関係がない場合（例：EIP やインターネットゲートウェイへのルートは AWS::EC2::VPCGatewayAttachment の完了を待つ必要がある）は DependsOn を書きます。

DeletionPolicy / UpdateReplacePolicy

DeletionPolicy は スタック削除時、またはテンプレートからリソースを取り除いたとき の挙動を決めます。

値	挙動
Delete（既定）	リソースを削除する
Retain	リソースを残す（スタックの管理対象から外れる）
RetainExceptOnCreate	基本は Retain と同じ。ただし そのリソースを最初に作成したスタック操作 がロールバックされるときだけ削除する（作成失敗の残骸を残さない）
Snapshot	削除前にスナップショットを取る。対応するのは EC2 Volume、ElastiCache CacheCluster / ReplicationGroup、Neptune / DocumentDB / RDS の DBCluster、RDS DBInstance、Redshift Cluster など

既定値の例外：AWS::RDS::DBCluster と、DBClusterIdentifier を指定しない AWS::RDS::DBInstance の既定は Snapshot です。

UpdateReplacePolicy は 更新で置き換え（Replacement）が起きたときに古いリソースをどうするか を決めます。値は Delete / Retain / Snapshot の 3 つ（RetainExceptOnCreate はない）で、DeletionPolicy とは独立に指定します。

CreationPolicy

CreationPolicy は「指定した数の成功シグナルを受け取るまで CREATE_COMPLETE にしない」属性です。インスタンス内で cfn-signal を実行して「アプリの起動まで完了した」ことを伝えます。

• 対応リソース：AWS::AppStream::Fleet、AWS::AutoScaling::AutoScalingGroup、AWS::EC2::Instance、AWS::CloudFormation::WaitCondition
• ResourceSignal の Count（必要なシグナル数）と Timeout（ISO 8601 形式、例 PT15M。最大 12 時間）
• Auto Scaling グループでは AutoScalingCreationPolicy.MinSuccessfulInstancesPercent で「何 % のインスタンスが成功すれば良いか」を指定
• タイムアウトまでにシグナルが足りない、または失敗シグナルを受け取るとリソース作成が失敗してロールバック

WaitCondition + WaitConditionHandle は CreationPolicy より古い仕組みで、外部プロセスからの通知を待つときや、他のリソースの作成を遅らせたいときに使います。EC2 / Auto Scaling には CreationPolicy が推奨です。

UpdatePolicy

UpdatePolicy は 更新時の挙動 を決めます。

ポリシー	対象	挙動
AutoScalingRollingUpdate	Auto Scaling グループ	起動テンプレート／起動設定、VPCZoneIdentifier、PlacementGroup の変更時（および現在の起動設定と一致しないインスタンスを含むグループの更新時）にローリング更新。MaxBatchSize、MinInstancesInService、MinSuccessfulInstancesPercent、PauseTime、WaitOnResourceSignals（cfn-signal を待つ）、SuspendProcesses。UpdatePolicy 自体の変更は発動条件に含まれず、ローリング更新を起こす更新とは別に先に変更しておくことが推奨されている
AutoScalingInstanceRefresh	Auto Scaling グループ	Auto Scaling の インスタンスリフレッシュ で置き換える新しい方式。launch-before-terminate などのインスタンスメンテナンスポリシーやアラームによるロールバックに対応。AutoScalingRollingUpdate とは併用不可
AutoScalingReplacingUpdate	Auto Scaling グループ	WillReplace: true で 新しい Auto Scaling グループを作ってから古いものを削除（Blue/Green 的）。CreationPolicy と組み合わせ、失敗時は古いグループに戻る。両方指定時は WillReplace: true が優先
AutoScalingScheduledAction	Auto Scaling グループ	スケジュールアクションで変わった MinSize / MaxSize / DesiredCapacity をテンプレートの値で上書きしないようにする（IgnoreUnmodifiedGroupSizeProperties: true）
CodeDeployLambdaAliasUpdate	AWS::Lambda::Alias	エイリアスのバージョン変更時に CodeDeploy でトラフィック移行する（SAM で DeploymentPreference を有効にすると CodeDeploy のリソースが自動作成され、同様の段階的移行が行われる）
UseOnlineResharding	ElastiCache ReplicationGroup	シャード数の変更をリソース置き換えなしで行う
EnableVersionUpgrade	OpenSearch Service ドメイン	バージョンアップをリソース置き換えなしで行う

更新の種類と変更セット

更新の挙動 より、プロパティごとに次の 3 種類があります。

種類	内容
中断なしの更新	物理 ID を変えず、稼働に影響しない
中断を伴う更新	物理 ID は変わらないが、再起動などの影響がある
置き換え（Replacement）	新しいリソースを作って物理 ID が変わり、古いリソースは削除される（UpdateReplacePolicy で残せる）

変更セット は更新前の差分プレビューです。Replacement 列が True / Conditional のリソースは置き換えの可能性があります。変更セットは更新が成功するかどうかは保証しません。作成時の事前検証でプロパティの構文エラー・リソース名の競合・サービスクォータなどは検出されますが、カスタムリソースのロジックやサービス固有の制約といった実行時の失敗は防げません。変更セットの種類は CREATE（スタックが未作成）、UPDATE、IMPORT（既存リソースの取り込み）です。

変更セットのオプションには、ImportExistingResources（同じ識別子の既存リソースを自動で取り込む）、DeploymentMode: REVERT_DRIFT（ドリフト対応の変更セット。実際の状態・前回のデプロイ状態・テンプレートの 3 者を比較し、ドリフトをテンプレートの状態に戻す。ドリフト対応の変更セット）があります。

失敗時の挙動とロールバック

• 作成失敗：既定はロールバック。--on-failure DO_NOTHING | ROLLBACK | DELETE で変更できる
• 更新失敗：既定は UPDATE_ROLLBACK。スタック失敗オプション で「正常にプロビジョニングされたリソースを保持」を選ぶと、失敗したリソースだけが *_FAILED のまま残り、修正して失敗箇所から再試行 できる（ロールバックして最初からやり直す時間を省く）
• UPDATE_ROLLBACK_FAILED：ロールバック自体が失敗した状態。手動で原因（外部で削除されたリソースなど）を直してから continue-update-rollback を実行する。--resources-to-skip で特定リソースをスキップ、または --force-rollback でロールバックに失敗したリソースをまとめてスキップ（両方同時は不可。ロールバックの続行）
• ロールバックトリガー：CloudWatch アラーム（最大 5 個、複合アラームも可）を指定し、作成・更新中と その後 0〜180 分の監視期間 に ALARM になればスタック操作全体をロールバックする（ロールバックトリガー）

スタックポリシーと削除保護

• スタックポリシー（リソースの保護）：更新時にどのリソースへの更新を許可／拒否するかを JSON で定義する。ポリシーを設定すると、明示的に Allow していないリソースはすべて更新拒否 になる（典型例：全リソース Allow + 本番 DB だけ Deny）。保護されたリソースを一時的に更新するには、更新時に一時的なポリシー（--stack-policy-during-update-body）を渡す。スタックごとに 1 つ
• 削除保護（termination protection）（スタックの削除保護）：スタックの削除を失敗させる。既定は無効。ルートスタックに設定するとネストスタックにも適用され、ネストスタック単体には設定できない。ただしスタック更新でネストスタックが削除される場合は削除される
• リソース単位の削除保護：DeletionPolicy: Retain

IAM とサービスロール

• 既定ではスタック操作を実行する ユーザーの権限 でリソースが作られる
• サービスロール（--role-arn）を指定すると、CloudFormation はそのロールの権限でリソースを操作する。ユーザーには iam:PassRole と cloudformation:* だけを与え、リソース作成権限はロールに集約する（「開発者に直接 EC2 作成権限を与えずテンプレート経由で作らせる」パターン）。ロールはスタックに紐づき、以降の操作でも使われる
• IAM 条件キーで制御できる：cloudformation:TemplateUrl（承認済みバケットのテンプレートだけ）、cloudformation:ResourceTypes（作成できるリソース種別の制限）、cloudformation:RoleARN、cloudformation:StackPolicyUrl（IAM による制御）

ヘルパースクリプト

EC2 インスタンス内で動く 4 つのスクリプトです（ヘルパースクリプトリファレンス）。Amazon Linux の AMI には同梱されており、aws-cfn-bootstrap パッケージで他の OS にも入れられます。

スクリプト	役割
cfn-init	Metadata の AWS::CloudFormation::Init を読み、packages → groups → users → sources → files → commands → services の順に構成する。configSets で順序やまとまりを定義
cfn-signal	CreationPolicy や WaitCondition に成功／失敗を通知する（cfn-signal -e $?）。渡せるデータは 4,096 バイトまで
cfn-get-metadata	メタデータを取得する
cfn-hup	デーモンとして動き、メタデータの変更を検知してフックに書いたアクションを実行 する（スタック更新でインスタンスを再作成せずに設定を更新するために使う）。ポーリング間隔は既定 15 分（cfn-hup）

典型構成は「ユーザーデータで cfn-init を実行 → 結果を cfn-signal で通知 → CreationPolicy が待つ」、更新時は「cfn-hup が AWS::CloudFormation::Init の変更を検知して cfn-init を再実行」です。

引っかけ（リソース属性と更新）

• DeletionPolicy は スタック削除とテンプレートからの削除 に効く。更新での置き換えに効くのは UpdateReplacePolicy
• RDS の DBInstance（クラスター外）と DBCluster は 既定で Snapshot。「削除時にスナップショットを残すように設定する」という選択肢は既定で満たされている場合がある
• CreationPolicy の Timeout は 最大 12 時間。cfn-signal が来ないとロールバック
• AutoScalingRollingUpdate は 起動テンプレート／起動設定／サブネット（VPCZoneIdentifier） の変更時に発動する。AMI を更新するなら起動テンプレートを変える
• 「ダウンタイムなしで Auto Scaling グループを丸ごと入れ替え、失敗時は元に戻す」→ AutoScalingReplacingUpdate（WillReplace: true）+ CreationPolicy
• スタックポリシーは 更新だけ に効く（削除保護ではない）。削除を防ぐのは termination protection
• 変更セットは 成功を保証しない（構文エラーやクォータは作成時に検証されるが、実行時の失敗は防げない）
• 「ロールバックが途中で止まった（UPDATE_ROLLBACK_FAILED）」→ continue-update-rollback（必要なら --resources-to-skip）
• cfn-hup は インスタンスを再作成せずに 設定変更を反映する手段。インスタンス置き換えが必要なのは AMI や起動テンプレートの変更

4. 主要機能（3）スタックの分割と大規模展開

ネストスタックとクロススタック参照

方式	仕組み	向き
ネストスタック（ネストスタック）	親テンプレートに AWS::CloudFormation::Stack を置き、TemplateURL（S3）と Parameters を渡す。子の出力は Fn::GetAtt 子.Outputs.名前 で取得	1 つのデプロイ単位の中で共通部品（ロードバランサー、セキュリティグループ）を再利用する。更新はルートスタックから 行う
クロススタック参照（ウォークスルー）	提供側が Outputs に Export、利用側が Fn::ImportValue	VPC のように ライフサイクルが異なる共有基盤 を疎結合で参照する

クロススタック参照の制約：Export 名はアカウント内・リージョン内で一意、リージョン越え不可、参照されている間はエクスポート元スタックを削除できず、エクスポート値の変更・削除もできない。この制約が困る場合は Fn::GetStackOutput（弱い参照）や SSM パラメータ経由の受け渡しを使います。

StackSets

StackSets は 1 つのテンプレートを複数アカウント・複数リージョンにスタックインスタンスとして展開 する仕組みです。管理者アカウントで作成し、ターゲットアカウント・リージョンごとにスタックが作られます。

権限モデル（StackSets の概念）

モデル	仕組み	特徴
セルフマネージド	管理者アカウントに AWSCloudFormationStackSetAdministrationRole、各ターゲットアカウントに AWSCloudFormationStackSetExecutionRole を 自分で作る（前提条件）	Organizations 外のアカウントにも展開できる。アカウントの追加は手動
サービスマネージド	Organizations との信頼アクセスを有効化すると、CloudFormation がロールを作る	OU 単位 で指定でき、自動デプロイ（OU に新しく入ったアカウントへ自動展開、離脱時の保持可否）が使える。管理アカウントか 委任管理者（委任管理者の登録）から操作

操作オプション（StackSets の概念）

• 最大同時アカウント数（数または %）：一度に操作するアカウント数。管理者アカウントがリージョンごとに同時に操作できるスタックインスタンスは全スタックセット合計で 10,000（クォータ）
• 障害許容数（数または %、リージョンごと）：これを超える失敗で操作を停止する。同時実行モード STRICT_FAILURE_TOLERANCE（既定）と SOFT_FAILURE_TOLERANCE（許容数に関わらず同時実行数を維持）
• リージョンの同時実行：SEQUENTIAL（既定。指定した順に 1 リージョンずつ）/ PARALLEL
• スタックの保持：スタックセットから外すときにスタックとリソースを残す
• アカウントフィルター（AccountFilterType。DeploymentTargets）：OU 指定と個別アカウント指定を組み合わせる。NONE（OU の全アカウント）/ INTERSECTION（OU 内かつ列挙したアカウントだけ）/ DIFFERENCE（OU から列挙したアカウントを除外。停止中アカウントの除外など）/ UNION（OU + 追加アカウント。既定だが CreateStackInstances では非対応）
• パラメータの オーバーライド（インスタンス単位）、スタックインスタンスのステータス（CURRENT / OUTDATED / INOPERABLE）、StackSets のドリフト検出

制約：サービスマネージド権限のスタックセットは マクロ（SAM などの変換を含む）を含むテンプレートに対応していない（クォータページの記載）。管理者アカウントあたりのスタックセット数は 1,000、スタックセットあたりのスタックインスタンスは 100,000 です。

ドリフト検出

ドリフト検出 は、スタックのリソースの実際の設定とテンプレートの定義の差を検出します。

• ステータス：スタックは DRIFTED / IN_SYNC / NOT_CHECKED / UNKNOWN、リソースは MODIFIED / DELETED / IN_SYNC / NOT_CHECKED
• 検出に対応しているリソース種別だけが対象。KMSKeyId プロパティは検出対象外。サービスが返さない値（パスワードなど）や Lambda の Code のように元の値に対応づけられないプロパティは比較できない。配列のサービス既定値が誤検知されることがある
• 必要な権限：対象リソースの読み取り権限 + cloudformation:DetectStackDrift / DetectStackResourceDrift / BatchDescribeTypeConfigurations
• 検出だけで修正はしない。修正は (1) ドリフト対応の変更セット（REVERT_DRIFT）でテンプレートの状態に戻す、(2) 手動で戻す、(3) テンプレート側を実態に合わせて更新する（インポート操作で取り込み直す方法もある）、のいずれか
• 継続的な監視は AWS Config のマネージドルール cloudformation-stack-drift-detection-check で行う（構成例として、EventBridge のスケジュールから DetectStackDrift を定期実行する方法もある）

既存リソースの取り込み・テンプレート生成・リファクタリング

機能	内容
リソースのインポート（インポート）	手動で作ったリソースをテンプレートに記述して IMPORT 型の変更セットでスタックに取り込む。インポート対象のリソースには DeletionPolicy が必須（値は任意。手動インポート）。インポート対応のリソース種別のみ。スタック間のリソース移動も「片方で Retain して削除 → もう片方でインポート」で可能
IaC ジェネレーター（IaC ジェネレーター）	アカウント（リージョン）内のリソースをスキャンし、選んだリソースからテンプレートを生成する。生成したテンプレートでそのままインポートできる。スキャン結果は 30 日で失効
スタックリファクタリング（リファクタリング）	リソースを 再作成せずに スタック間で移動したり、論理 ID を変更したりする。対象はコンソールでは 2 スタック以上、CLI では最大 5 スタック。ネストスタック間の移動にも対応
ImportExistingResources	変更セットのオプション。テンプレートに書いたリソースと同じ識別子の既存リソースがあれば、作成の代わりに自動で取り込む

Hooks（プロアクティブな検証）

CloudFormation Hooks は、リソースの作成・更新・削除（preCreate / preUpdate / preDelete）やスタック・変更セットの操作の 前 にテンプレートを検証し、違反なら失敗（FAIL）か警告（WARN）にします。

種類	実装
Lambda Hooks	検証ロジックを Lambda 関数で書く
Guard Hooks	CloudFormation Guard のルール（S3 に置く）で宣言的に書く
カスタム Hooks	CloudFormation CLI で開発してレジストリに登録

Control Tower の プロアクティブコントロール はこの Hooks で実装されています。「S3 バケットの暗号化なし設定をデプロイ前に止めたい」「検証を CI ではなく CloudFormation 側で強制したい」が典型的なシナリオです。

Git 同期

Git 同期 は、CodeConnections で接続した Git リポジトリの デプロイファイル（template-file-path、parameters、tags を書いた JSON / YAML）を監視し、コミットされるとスタックを自動更新します。プルリクエストに変更内容のサマリーをコメントするオプションもあります。CodePipeline を組まずに「GitOps 的に CloudFormation を運用する」ための機能です。

カスタムリソース・マクロ・レジストリ

• カスタムリソース（カスタムリソース）：AWS::CloudFormation::CustomResource または Custom::名前 で、ServiceToken（Lambda 関数か SNS トピックの ARN）に Create / Update / Delete のリクエストを送る。プロバイダは 事前署名付き S3 URL に SUCCESS / FAILED を書き戻す（応答データは 4,096 バイトまで）。既定のタイムアウトは 1 時間 で、ServiceTimeout プロパティで短くできる。応答がないとスタック操作は失敗（タイムアウトまで待つ）。Update で PhysicalResourceId を変えて返すと、古いリソースに Delete が送られる
• マクロ（マクロ）：Lambda でテンプレートを書き換える。テンプレート全体（Transform）とスニペット（Fn::Transform）の 2 種類。SAM は AWS がホストするマクロ
• レジストリ（レジストリ）：AWS 公開・サードパーティ公開・プライベートの リソースタイプ、モジュール（モジュール。::MODULE 接尾辞。複数リソースを 1 つの部品としてテンプレートに書き、処理時に展開される）、Hooks を登録・有効化する。CloudFormation CLI（cfn）で開発し register-type で登録。カスタムリソースと違い、Lambda や SNS を自分で運用せずに CRUDL を提供できる

高速モード（express mode）とクォータ

• 高速モード（express mode）：リソースの安定化（EC2 なら running になるまで）を待たずに完了扱いにする開発・検証向けのモード。本番では既定モードを使う。CDK の hotswap との比較がドキュメントに載っている
• クォータ（CloudFormation のクォータ）

項目	値
スタック数	2,000（引き上げ可）
テンプレートあたりのリソース	500
パラメータ / 出力 / マッピング	各 200
テンプレート本文	リクエスト直接は 51,200 バイト、S3 経由は 1 MB
動的参照	60 / テンプレート
ネストスタック	1 回の操作で作成・更新・削除できるリソースは 2,500
ロールバックトリガー	5
cfn-signal / カスタムリソース応答	4,096 バイト

CodePipeline・CDK・SAM との関係

• CodePipeline の CloudFormation アクション（アクションリファレンス）：CREATE_UPDATE、DELETE_ONLY、REPLACE_ON_FAILURE（失敗状態のスタックを削除して作り直す。テスト環境向け）、CHANGE_SET_REPLACE（変更セット作成）、CHANGE_SET_EXECUTE（実行）。本番は「変更セット作成 → 手動承認 → 実行」。StackSets 用のアクション（CloudFormationStackSet / CloudFormationStackInstances）もある
• CDK：プログラミング言語で書いた定義を CloudFormation テンプレートに合成（cdk synth）してデプロイ（cdk deploy）。cdk diff が変更セット相当。ブートストラップスタックが必要。試験では「開発者が慣れた言語で IaC を書きたい」が CDK を選ぶ合図
• SAM：Transform: AWS::Serverless-2016-10-31 を付けたテンプレート。AWS::Serverless::Function などを CloudFormation リソースに展開。sam deploy は変更セットを使う。DeploymentPreference で CodeDeploy のカナリア／リニアを設定
• Control Tower / Organizations：Control Tower はベースラインの配布に StackSets を使い、CfCT（Customizations for Control Tower）は StackSets と SCP を組み合わせる（第 3 回で解説）

5. 試験で問われるところ（総まとめ）

問題文のシナリオ	正解の方向
同じ構成を複数アカウント・複数リージョンへ配りたい。新規アカウントにも自動で	StackSets（サービスマネージド権限 + OU 指定 + 自動デプロイ）
Organizations 外のアカウントにも配りたい	StackSets（セルフマネージド権限、管理・実行ロールを手動作成）
管理アカウント以外から StackSets を運用したい	委任管理者
展開中の障害で全体に影響させたくない	障害許容数と最大同時アカウント数を小さく、リージョンは SEQUENTIAL
本番 DB をスタック更新で誤って置き換えたくない	スタックポリシーで Deny、DeletionPolicy / UpdateReplacePolicy に Retain または Snapshot
スタック削除で DB のデータを失いたくない	DeletionPolicy: Snapshot（RDS は既定）または Retain
スタックを誤って削除されたくない	削除保護（termination protection）
EC2 の初期設定が終わってからスタックを完了扱いにしたい	CreationPolicy + cfn-init + cfn-signal
スタック更新で設定ファイルだけ差し替え、インスタンスは再作成したくない	cfn-hup が AWS::CloudFormation::Init の変更を検知して cfn-init を再実行
AMI 更新を Auto Scaling グループにダウンタイムなしで適用	AutoScalingRollingUpdate（MinInstancesInService + WaitOnResourceSignals）または AutoScalingReplacingUpdate
更新後にアラームが鳴ったら自動で元に戻したい	ロールバックトリガー（監視期間 0〜180 分）
更新に失敗したが、ロールバックせず失敗箇所から再開したい	「正常にプロビジョニングされたリソースを保持」（--disable-rollback）
UPDATE_ROLLBACK_FAILED から復旧したい	continue-update-rollback（--resources-to-skip）
パスワードをテンプレート・パラメータに残したくない	Secrets Manager / ssm-secure の動的参照
別スタックの VPC ID を使いたい	Export + Fn::ImportValue（同一アカウント・リージョン）、クロスアカウントなら Fn::GetStackOutput
共通部品を複数のテンプレートで再利用したい	ネストスタック、またはレジストリのモジュール
手動で作ったリソースを CloudFormation 管理下に置きたい	リソースのインポート（IaC ジェネレーターでテンプレート生成も可）
スタック間でリソースを移したい（再作成せず）	スタックリファクタリング（または Retain 削除 + インポート）
手動変更を検出したい／継続的に監視したい	ドリフト検出、AWS Config ルール cloudformation-stack-drift-detection-check
検出したドリフトをテンプレートの状態へ戻したい	ドリフト対応の変更セット（REVERT_DRIFT）
CloudFormation が対応していないリソースや外部 API を扱いたい	カスタムリソース（Lambda）、またはレジストリのリソースタイプ
デプロイ前に「暗号化なしの S3 は禁止」を強制したい	Hooks（Guard / Lambda）、Control Tower のプロアクティブコントロール
開発者にテンプレート経由でしかリソースを作らせたくない	CloudFormation サービスロール + iam:PassRole、cloudformation:TemplateUrl / ResourceTypes 条件キー
承認された S3 のテンプレートだけ使わせたい	IAM 条件キー cloudformation:TemplateUrl
変更内容を人が確認してから本番適用したい	変更セット（CodePipeline では CHANGE_SET_REPLACE → 承認 → CHANGE_SET_EXECUTE）
Git への push でスタックを更新したい（パイプラインなし）	Git 同期
環境ごとにリソース数を変えたい（本番だけ Multi-AZ）	Conditions + Fn::If、Mappings
同じ構造のリソースを多数生成したい	AWS::LanguageExtensions + Fn::ForEach
テンプレートが 51,200 バイトを超える	S3 にアップロードして TemplateURL を使う（1 MB まで）、ネストスタックで分割
リソース数が 500 を超える	ネストスタックで分割
Lambda のデプロイを段階的に（カナリア）	SAM DeploymentPreference（CodeDeploy によるエイリアスのトラフィック移行）
開発中の反復を速くしたい	高速モード（本番では使わない）、CDK hotswap

横断の引っかけ

• 「StackSets で OU 指定・自動デプロイ」は サービスマネージド権限 が前提。セルフマネージドでは OU 指定できない
• サービスマネージドの StackSets は SAM（Transform）を含むテンプレートを扱えない
• 変更セット・ドリフト検出・スタックポリシーは それぞれ別の目的（差分確認・差分検出・更新制御）。問題文の目的に合わせる
• Fn::ImportValue のエクスポート元は 参照されている間は削除・変更できない。「VPC スタックを更新したらエクスポート値が変えられない」は設計上の正常な制約
• ドリフト検出は 直さない。直すのは変更セット（REVERT_DRIFT）や手動
• カスタムリソースは 必ず応答を返す 設計にする（例外時も FAILED を返す）。返さないと最大 1 時間待ってから失敗する
• Hooks は デプロイ前 の検証。デプロイ後の検出は Config ルール、検出 + 自動修復は Config + Systems Manager Automation

6. 確認しきれなかった記述

• UpdatePolicy 自体の変更が AutoScalingRollingUpdate を発動するかは明文化されていません。発動条件の一覧に含まれず、「別の更新で先に変更する」推奨があることから、本文では「発動しない」前提で書いています
• SAM の DeploymentPreference が内部的に CodeDeployLambdaAliasUpdate に展開される点は SAM のドキュメントに明文がなく、「CodeDeploy のリソースが自動作成される」ことだけを確認しています
• 変更セットの事前検証で権限不足が検出されるかは明記されていません

おわりに

CloudFormation は「テンプレートの書き方」より 「スタックのライフサイクルで何が起きるか（作成・更新・置き換え・削除・失敗・ロールバック）」 を問われます。DeletionPolicy / UpdateReplacePolicy / CreationPolicy / UpdatePolicy の 4 属性と、StackSets の 2 つの権限モデル、変更セット・ドリフト・スタックポリシーの役割の違いを押さえれば、DOP 分野 2 と SAP 分野 1 の IaC 問題は安定します。第 3 回は Control Tower を同じ構成で解説します。

---

📩 AWS認定の学習Tips・「試験に出ないが現場で必須」の知識をX（naoto@クラウドエンジニア）で毎日発信中 👉 https://x.com/naoto_tech_AI