SAA（Solutions Architect Associate）攻略・ 2026-07-28

SAA CloudFormation/CDK 設計パターン4選｜IaC の要件別選択基準と試験頻出ポイント

AWS SAA-C03 で問われる IaC 設計パターン4選。単一スタック・ネストスタック・StackSets・CDK の4パターンを要件キーワードから即断できる粒度で解説。変更セット・ドリフト検出・CDK コンストラクトレベル（L1/L2/L3）の試験頻出ポイントも完全網羅。

#AWS #SAA #SAA-C03 #Solutions Architect #CloudFormation #CDK #IaC #ネストスタック #StackSets #インフラのコード化 #試験対策 #AWS認定資格

「IaC でインフラを管理したい」という問いに、SAA-C03 は4パターンしか答えを持っていない。 CloudFormation・ネストスタック・StackSets・CDK はすべて「インフラをコードで定義する」サービスだが、「1アカウント内で管理する」「テンプレートを再利用・分割する」「複数アカウント・リージョンに一括展開する」「プログラミング言語で型安全に定義する」の軸で役割が明確に異なる。攻略の核心は**「展開スコープ（1アカウント vs マルチアカウント）」「テンプレートの再利用性（単一 vs ネスト）」「定義言語（宣言型 YAML vs プログラミング言語）」の3軸**で要件を分類することだ。本記事では、SAA-C03 の IaC 問題を即断できる4設計パターンを、要件キーワードから逆引きできる粒度で解説する。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

1. 結論：CloudFormation/CDK の4設計パターン

SAA-C03 の IaC 問題を最短で解く骨格は、「展開スコープ・再利用性・定義方法」の3軸で要件を分類することだ。

パターン	主な技術	典型的なシナリオ	試験での見分け方
1. 単一スタック	CloudFormation	シンプルな環境の一括管理	「テンプレート1つで管理」
2. ネストスタック	CloudFormation Nested Stacks	大規模環境の分割・再利用	「テンプレートを部品化・モジュール化」
3. StackSets	CloudFormation StackSets	複数アカウント・リージョンへ展開	「全アカウント・全リージョンに一括」
4. CDK	AWS CDK	プログラミング言語でIaC	「TypeScript/Python でインフラ定義」

3つの判断軸を先に固めれば、4パターンのうちどれが正解かを即断できる。「複数アカウント」なら StackSets、「テンプレート分割・再利用」ならネストスタック、「プログラミング言語」なら CDK という流れだ。

2. CloudFormation の基本概念

テンプレートとスタック

CloudFormation の基本単位はテンプレート（YAML/JSON）とスタックだ。

テンプレート： リソース（EC2・VPC・RDS 等）の定義を記述したコードファイル
スタック： テンプレートをデプロイしたもの。リソースのライフサイクルをスタック単位で管理
スタックの操作： 作成・更新・削除で、テンプレートで定義されたリソースを一括管理

# CloudFormation テンプレートの骨格（YAML）
AWSTemplateFormatVersion: '2010-09-09'
Parameters:
  EnvType:
    Type: String
    AllowedValues: [prod, staging, dev]
Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "my-app-${EnvType}-bucket"
Outputs:
  BucketName:
    Value: !Ref MyBucket
    Export:
      Name: !Sub "${AWS::StackName}-BucketName"

変更セット（Change Set）

変更セットはテンプレート変更を本番適用前にプレビューする機能だ。

通常のスタック更新フロー：
  1. テンプレートを修正
  2. 変更セットを作成（Create Change Set）
     → 追加・変更・削除されるリソースの一覧を確認できる
  3. 内容を確認後に変更セットを実行（Execute Change Set）
     → 実際にリソースが変更される

ドリフト検出（Drift Detection）

ドリフト検出はテンプレートと実際のリソース状態の差異を検出する機能だ。

ドリフト発生例： CloudFormation 外（コンソール/CLI）からリソースを手動変更したとき
検出操作： DetectStackDrift → ドリフトしているリソースを一覧表示
試験での出題： 「手動変更でテンプレートと実態がズレた」→ ドリフト検出が正解

ロールバック（Rollback）

スタックの更新や作成に失敗した場合、CloudFormation は自動的に前の状態に戻す（ロールバック）。

OnFailure オプション： ROLLBACK（デフォルト）/ DO_NOTHING / DELETE
スタックポリシー： 特定のリソースを変更から保護する保護ポリシーを設定可能

3. CDK の基本概念とコンストラクトレベル

AWS CDK（Cloud Development Kit）とは

CDK はTypeScript・Python・Java・C# 等のプログラミング言語でインフラを定義するフレームワークだ。CDK コードは cdk synth コマンドで CloudFormation テンプレート（YAML）に変換され、CloudFormation を使ってデプロイされる。

CDK の処理フロー：
  CDK コード（TypeScript/Python）
    ↓ cdk synth
  CloudFormation テンプレート（YAML/JSON）
    ↓ cdk deploy（= CloudFormation スタックをデプロイ）
  AWS リソース（EC2・VPC・RDS 等）

cdk bootstrap： CDK 用の S3 バケットや IAM ロールを初回セットアップするコマンド
cdk synth： CDK コードを CloudFormation テンプレートに変換（変換結果を確認できる）
cdk deploy： CDK コードをデプロイ（内部では CloudFormation スタックを作成・更新）
cdk diff： 現在のスタックとコードの差分を確認（変更セット相当）

コンストラクトレベル（L1 / L2 / L3）

CDK の核心概念は**コンストラクト（Construct）**だ。コンストラクトは3つのレベルに分かれる。

CDK コンストラクトレベル（L1 / L2 / L3）

評価項目	L1（Cfn リソース）	L2（Curated）	L3（パターン）
別名	CloudFormation リソース	キュレーテッドコンストラクト	ソリューションパターン
CloudFormation との対応	1:1（完全一致）	1:1（デフォルト値あり）	複数リソースを統合
命名規則	Cfn プレフィックス（例: CfnBucket）	クラス名そのまま（例: s3.Bucket）	パターン名（例: ApplicationLoadBalancedFargateService）
設定の手間	全プロパティを明示	ベストプラクティスがデフォルト	ほぼ自動（カスタマイズ余地は低い）
コントロール	最大（細かく制御可能）	高い	低い（高速実装優先）
典型的な使い方	CloudFormation と同等の制御が必要なとき	通常の開発（最も多く使われる）	ベストプラクティス構成をすぐ作りたいとき

4. パターン1：単一スタック設計

要件のキーワード

「1つのテンプレートですべてのリソースを一元管理したい」
「シンプルな環境（開発・ステージング）をまとめて管理したい」
「少人数チームが単一のライフサイクルで管理する」

単一スタックの構造

単一スタック：
  CloudFormation Stack（1つ）
    ├── VPC・サブネット・セキュリティグループ
    ├── EC2 Auto Scaling グループ
    ├── ALB（Application Load Balancer）
    └── RDS（Multi-AZ）

→ スタックを削除するとすべてのリソースが一括削除
→ スタックを更新するとテンプレートの変更が全リソースに適用

単一スタックが適するシナリオ

リソース数が少ない（目安：200 リソース未満）
チームが1つで独立して管理できる
開発・ステージング・本番を別スタックで立ち上げる

5. パターン2：ネストスタック設計

要件のキーワード

「テンプレートが大きくなりすぎた。再利用可能な部品に分割したい」
「VPC・セキュリティグループ・アプリをそれぞれ独立したテンプレートで管理したい」
「共通のネットワーク設定を複数の環境（dev/staging/prod）で使い回したい」
「リソース上限（500個）に近づいている」

ネストスタックの構造

ネストスタック：
  親スタック（Parent Stack）
    ├── ネットワークスタック（子）
    │     └── VPC・サブネット・インターネットゲートウェイ
    ├── セキュリティスタック（子）
    │     └── セキュリティグループ・IAM ロール・KMS キー
    └── アプリスタック（子）
          └── EC2 Auto Scaling・ALB・RDS

親スタックから子スタックへは AWS::CloudFormation::Stack リソース型で参照

ネストスタックの仕組み

親スタックは AWS::CloudFormation::Stack リソース型を使って子スタックを呼び出す。

# 親スタックからネットワークスタックを呼び出す例
Parameters:
  NetworkTemplateUrl:
    Type: String
    Default: s3://BUCKET/templates/network-stack.yaml  # S3 の HTTPS URL を指定
Resources:
  NetworkStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: !Ref NetworkTemplateUrl
      Parameters:
        VpcCidr: "10.0.0.0/16"

6. パターン3：StackSets（マルチアカウント展開）

要件のキーワード

「100 個の AWS アカウントに同じセキュリティ設定を一括展開したい」
「AWS Organizations の全アカウントに共通の IAM ロールを作成したい」
「複数リージョンに同一の CloudWatch アラームを展開したい」
「組織全体に AWS Config ルールを強制適用したい」

StackSets とネストスタックの違い

StackSets vs ネストスタック

評価項目	StackSets	ネストスタック
展開スコープ	複数アカウント × 複数リージョン	同一アカウント内のみ
主な用途	組織全体への一括ガバナンス適用	テンプレートの分割・再利用
権限モデル	サービス管理型（Organizations）or 自己管理型（IAM）	スタック内で完結
Organizations 連携	○ Organizations と直接統合	× 無関係
典型例	全アカウントに Config ルール・IAM ロールを展開	VPC スタック・アプリスタックを分割管理

StackSets の権限モデル

StackSets には2つの権限モデルがある。

1. サービス管理型（Service-Managed）権限
   → AWS Organizations と統合
   → OU（組織単位）やアカウントを指定して一括展開
   → 管理アカウントまたは委任管理者が操作
   → 新規アカウントも自動的にスタックが展開される（自動デプロイ）

2. 自己管理型（Self-Managed）権限
   → 管理アカウントに AWSCloudFormationStackSetAdministrationRole を作成
   → ターゲットアカウントに AWSCloudFormationStackSetExecutionRole を作成
   → 細かいロール制御が可能

StackSets の代表的なユースケース

セキュリティ基盤の一括適用： AWS Config ルール・GuardDuty・Security Hub を全アカウントに有効化
IAM ロールの統一： 全アカウントに共通の監査用 IAM ロールを作成
ログ集約設定： CloudTrail ログを中央アカウントの S3 バケットに集約する設定を展開
ネットワーク標準化： VPC フローログの有効化を組織全体に強制

7. パターン4：CDK による IaC

要件のキーワード

「TypeScript/Python でインフラを定義したい」
「プログラミング言語の機能（ループ・条件分岐・テスト）でインフラを管理したい」
「型安全なインフラ定義が必要」
「再利用可能なライブラリとしてインフラパターンを配布したい」

CDK vs CloudFormation の使い分け

CloudFormation テンプレート vs CDK

評価項目	CloudFormation（YAML/JSON）	AWS CDK（TypeScript 等）
定義言語	宣言型（YAML/JSON）	プログラミング言語（TS/Python/Java/C#）
型安全	なし（文字列ベース）	あり（IDE 補完・コンパイル時チェック）
ループ・条件分岐	Conditions / Fn::ForEach で限定的	ネイティブに使える
テストの書きやすさ	困難	ユニットテストを書ける（CDK アサーション）
最終的なデプロイ	直接 CloudFormation スタック	cdk synth → CloudFormation スタック
学習コスト	YAML/JSON の知識のみ	プログラミング言語 + CDK API の知識

CDK の典型的なコード例（L2 コンストラクト）

// CDK（TypeScript）で S3 バケット + Lambda を定義する例
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as lambda from 'aws-cdk-lib/aws-lambda';

const bucket = new s3.Bucket(this, 'DataBucket', {
  versioned: true,                          // バージョニング有効
  encryption: s3.BucketEncryption.S3_MANAGED, // SSE-S3 暗号化
  removalPolicy: RemovalPolicy.RETAIN,       // スタック削除時も保持
});

const fn = new lambda.Function(this, 'ProcessorFn', {
  runtime: lambda.Runtime.NODEJS_20_X,
  handler: 'index.handler',
  code: lambda.Code.fromAsset('lambda'),
  environment: { BUCKET_NAME: bucket.bucketName },
});

// L2 の便利なヘルパーメソッド：IAM ポリシー設定を1行で完了
bucket.grantRead(fn);

8. クロススタック参照（Cross-Stack Reference）

要件のキーワード

「スタック A が作った VPC ID を スタック B で使いたい（ネストせずに）」
「別チームが管理するスタックのリソースを参照したい」

クロススタック参照の仕組み

CloudFormation では Outputs セクションにエクスポート名を定義し、別スタックが Fn::ImportValue で参照する。

# VPC スタック（出力側）
Outputs:
  VpcId:
    Value: !Ref MyVpc
    Export:
      Name: !Sub "${AWS::StackName}-VpcId"   # エクスポート名を定義

# アプリスタック（参照側）
Resources:
  AppSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: !ImportValue "vpc-stack-VpcId"   # 他スタックの値を参照

9. 要件キーワード早見表

要件キーワード	正解の選択肢	間違えやすい誤答
「インフラをコード化・テンプレートで管理」	CloudFormation	手動構築（コンソール操作）
「変更前にリソースの変更内容を確認したい」	変更セット（Change Set）	テンプレートの直接更新
「手動変更でテンプレートと実態がズレた」	ドリフト検出（Drift Detection）	手動で確認・修正
「更新失敗時に自動で以前の状態に戻したい」	CloudFormation ロールバック	手動ロールバック
「テンプレートを部品化・再利用したい（1アカウント）」	ネストスタック	単一スタックのコピー
「テンプレートをスタック間で共有（疎結合）」	クロススタック参照（Fn::ImportValue）	ハードコードした値の参照
「50 アカウント × 5 リージョンに同じ設定を展開」	StackSets（サービス管理型）	ネストスタック（1アカウント内のみ）
「Organizations 全アカウントに Config ルールを強制」	StackSets + Organizations	各アカウントで個別設定
「TypeScript/Python でインフラを定義」	AWS CDK	CloudFormation（YAML のみ）
「CDK で書いたコードはどう動く？」	CloudFormation スタックに変換してデプロイ	EC2 に直接デプロイ
「CDK のベストプラクティスが組み込まれた高レベル部品」	L2 コンストラクト	L1 コンストラクト（CloudFormation 直接）
「CDK で複数リソースのパターンを一括作成」	L3 コンストラクト（パターン）	L2 を個別に組み合わせ

10. 頻出ひっかけパターンと正しい打ち手

ひっかけ1：StackSets とネストスタックを混同する

誤り： 「複数の AWS アカウントに同じ VPC 設定を展開したい → ネストスタック」
正解： ネストスタックは同一アカウント内のテンプレート分割のための仕組みだ。複数アカウントへの一括展開には StackSets を使う。「複数アカウント・複数リージョン」というキーワードが出たら、常に StackSets を選ぶ。

ひっかけ2：CDK は CloudFormation を使わないと思い込む

誤り： 「CDK を使えば CloudFormation を使わずにデプロイできる」
正解： CDK は cdk synth で CloudFormation テンプレートに変換し、CloudFormation スタックとしてデプロイする。CDK の裏側は常に CloudFormation だ。 試験で「CDK でデプロイされるリソースの管理方法は？」→ CloudFormation スタックで管理される、が正解。

ひっかけ3：変更セットを使わずにテンプレートを直接更新する

誤り： 「本番環境のスタックを更新するとき、テンプレートを変更したら即 Update Stack を実行する」
正解： 本番環境では必ず変更セット（Change Set）を作成して内容を確認してから実行する。特に RDS のようなステートフルなリソースが含まれる場合、置き換え（Replace）が発生するとデータ損失につながる。

ひっかけ4：エクスポート済みの値を参照しているスタックを先に削除しようとする

誤り： 「クロススタック参照の依存関係を解消するため、まずエクスポート元のスタック（VPC スタック）を削除する」
正解： エクスポート値を参照しているスタック（アプリスタック）を先に削除するか、参照を解除してから、エクスポート元のスタックを削除する。削除順序を逆にすると CloudFormation がエラーを返す。

📑 目次

1. 結論：CloudFormation/CDK の4設計パターン

2. CloudFormation の基本概念

テンプレートとスタック

変更セット（Change Set）

ドリフト検出（Drift Detection）

ロールバック（Rollback）

3. CDK の基本概念とコンストラクトレベル

AWS CDK（Cloud Development Kit）とは

コンストラクトレベル（L1 / L2 / L3）

4. パターン1：単一スタック設計

要件のキーワード

単一スタックの構造

単一スタックが適するシナリオ

5. パターン2：ネストスタック設計

要件のキーワード

ネストスタックの構造

ネストスタックの仕組み

6. パターン3：StackSets（マルチアカウント展開）

要件のキーワード

StackSets とネストスタックの違い

StackSets の権限モデル

StackSets の代表的なユースケース

7. パターン4：CDK による IaC

要件のキーワード

CDK vs CloudFormation の使い分け

CDK の典型的なコード例（L2 コンストラクト）

8. クロススタック参照（Cross-Stack Reference）

要件のキーワード

クロススタック参照の仕組み

9. 要件キーワード早見表

10. 頻出ひっかけパターンと正しい打ち手

ひっかけ1：StackSets とネストスタックを混同する

ひっかけ2：CDK は CloudFormation を使わないと思い込む

ひっかけ3：変更セットを使わずにテンプレートを直接更新する

ひっかけ4：エクスポート済みの値を参照しているスタックを先に削除しようとする

11. 次のアクション チェックリスト

12. 関連記事

13. 関連サイト

出典・参考情報

11. 次のアクションチェックリスト