AWS CloudFormation 完全ガイド 2026

初心者から実務者向けの包括的解説

AWS CloudFormation は、Amazon Web Services（AWS）が提供するInfrastructure as Code (IaC) サービスです。2011 年のリリース以来、AWS リソースを YAML/JSON テンプレート で宣言的に定義・プロビジョニング・管理するツールとして、AWS ネイティブの標準選択肢になりました。本ドキュメントは、CloudFormation の概念・使い方・エコシステム・最新動向を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

初心者向け： CloudFormation とは何か、なぜ必要かを学びたい方
開発者向け： テンプレート・リソース定義・ネストスタックを書きたい方
インフラ・DevOps 向け： StackSet・Change Sets・Drift Detection・レジストリを運用したい方
意思決定者向け： CloudFormation vs Terraform vs CDK vs Pulumi の選択、マルチアカウント戦略

2026 年の CloudFormation エコシステム

CloudFormation 1.x 系列：安定・成熟した本体、YAML 推奨、JSON も対応
CloudFormation Registry：サードパーティ・リソースの一元管理
IaC Generator：既存リソースから自動 CloudFormation テンプレート生成
CloudFormation Hooks：デプロイ前のポリシーチェック（GA）
Stack Refactoring：既存スタック再構成・分割機能
AI テンプレート生成：自然言語から CloudFormation テンプレート自動生成
マルチリージョン・マルチアカウント：StackSet / Organizations 統合

概要
CloudFormation が解決する課題
主な特徴
アーキテクチャ
テンプレート（YAML/JSON）と Intrinsic Functions
主要ユースケース
Change Sets と Drift Detection
Nested Stack
StackSet（マルチアカウント・マルチリージョン）
Custom Resources（Lambda backed）
Modules / CloudFormation Registry
Resource Import
CloudFormation Hooks
CloudFormation Guard
CDK / SAM との関係
Service Catalog 連携
CloudFormation vs Terraform vs CDK vs Pulumi
他の類似ツールとの比較
クライアントとエコシステム
ベストプラクティス
トラブルシューティング
2025-2026 最新動向
学習リソース
実装例・活用シーン
導入ロードマップ
実装チェックリスト
まとめ
参考文献

概要

初心者向けメモ： CloudFormation は「AWS コンソール操作をテンプレート化するツール」ではなく、AWS リソースの完全なライフサイクル（作成・更新・削除）をコード化し、バージョン管理・チーム共有・自動デプロイを実現するものです。「Change Sets」で変更差分を確認してから「実行」する、という安全なワークフローが特徴です。

CloudFormation は、AWS が開発・提供する IaC サービス です。公式ドキュメント（CloudFormation User Guide）に基づくと、単なるリソース作成スクリプトではなく、リソースの完全なライフサイクル管理 を実現するプラットフォームです。

CloudFormation の位置づけ

【図1】Infrastructure as Code エコシステムにおける CloudFormation の位置：

graph TD
    Infra["AWS インフラストラクチャ"]
    
    subgraph IaC["Infrastructure as Code"]
        CF["<b>CloudFormation</b><br/>YAML/JSON<br/>AWS ネイティブ"]
        CDK["AWS CDK<br/>TypeScript/Python<br/>CloudFormation 生成"]
        SAM["AWS SAM<br/>Serverless<br/>CloudFormation 生成"]
        Terraform["Terraform<br/>HCL<br/>マルチクラウド"]
        Pulumi["Pulumi<br/>汎用言語"]
    end
    
    subgraph ConfigMgmt["Configuration Management"]
        Ansible["Ansible<br/>Agent不要"]
        Chef["Chef / Puppet"]
    end
    
    CF --> Infra
    CDK --> CF
    SAM --> CF
    Terraform --> Infra
    Pulumi --> Infra
    Ansible -.-> Infra
    Chef -.-> Infra

CloudFormation が解決する課題

1. 手作業の廃止と再現性

❌ 従来の課題：

AWS コンソール手作業 → ドキュメント化忘れ → 誰が何をしたかわからない
本番環境と開発環境で設定がズレている
障害時に復旧手順が不明確
新規アカウント作成時に「標準設定」を毎回手で構成

✅ CloudFormation の解決：

全て YAML/JSON コードで宣言 → Git バージョン管理 → PR レビュー可能
同じテンプレートで複数環境を管理（パラメータ変更のみ） → 一貫性確保
StackSet で 100+ アカウントに一括展開
変更履歴が Git にあり、いつ誰が何を変えたかが明確

2. AWS 新サービスへの即時対応

❌ 従来の課題：

Terraform は新サービス対応に遅延（プロバイダー更新待ち）
マニュアル操作を続ける必要

✅ CloudFormation の解決：

AWS が新サービスをリリース → CloudFormation テンプレート同時提供
新 AWS リソースを即座に IaC で管理可能

3. インフラの差分管理と安全な更新

❌ 従来の課題：

何を変更するか把握できず、思わぬ削除が発生
本番環境への直接変更で予期しないダウンタイム

✅ CloudFormation の解決：

Change Sets で変更差分を事前確認
承認後に実行 → 予期しない変更を防止
失敗時は自動ロールバック

4. マルチアカウント・マルチリージョン一括管理

❌ 従来の課題：

複数の AWS アカウント・リージョンで同じ設定を繰り返す
組織全体の標準化が困難

✅ CloudFormation の解決：

StackSet で複数アカウント・リージョンに一括デプロイ
Organizations との統合で新規アカウント作成時に自動適用

主な特徴

特徴	説明
宣言型（Declarative）	目標状態を記述、実現方法は CloudFormation が決定
AWS ネイティブ	AWS 新サービスに即日対応、深い統合
Change Sets	デプロイ前に変更差分を確認・承認
StackSet	マルチアカウント・マルチリージョン展開
Drift Detection	手動変更を検出・通知
Resource Import	既存リソースを管理下に取り込み
Custom Resources	Lambda バックエンドで未対応リソース対応
CloudFormation Registry	サードパーティ・リソース統一管理
Nested Stacks	テンプレートの再利用・モジュール化
Policy as Code（Hooks）	デプロイ前のポリシーチェック

アーキテクチャ

初心者向けメモ： CloudFormation は「テンプレート」「スタック」「リソース」の 3 層からなります。テンプレートを S3 に置き、スタック作成時に指定すると、CloudFormation が YAML/JSON をパースして AWS リソースを自動作成します。

【図2】CloudFormation の実行フロー・アーキテクチャ：

graph TD
    Template["<b>CloudFormation テンプレート</b><br/>YAML/JSON<br/>template.yaml"]
    
    subgraph Workflow["CloudFormation ワークフロー"]
        Init["1. テンプレート検証<br/>構文チェック"]
        CreateCS["2. Change Set 作成<br/>差分検出"]
        ReviewCS["3. Change Set レビュー<br/>人間確認"]
        ExecuteCS["4. Change Set 実行<br/>リソース適用"]
        Rollback["失敗時: 自動ロールバック<br/>→ 前状態に復旧"]
    end
    
    S3["S3 バケット<br/>テンプレート保存"]
    
    Stack["スタック<br/>（リソースグループ）"]
    
    Infra["AWS リソース<br/>VPC / EC2 / RDS / Lambda 等"]
    
    Template --> S3
    S3 --> Init
    Init --> CreateCS
    CreateCS --> ReviewCS
    ReviewCS -->|承認| ExecuteCS
    ReviewCS -->|差分なし| Done["✅ スキップ"]
    ExecuteCS --> Stack
    Stack --> Infra
    Infra -->|失敗| Rollback
    Rollback --> Infra

テンプレート（YAML/JSON）と Intrinsic Functions

初心者向けメモ： CloudFormation テンプレートは YAML または JSON で記述します。YAML が読みやすく、JSON はツール生成時に使われます。!Ref !GetAtt !Sub などの組み込み関数を使ってリソース間の参照・値置換を実現します。

テンプレート基本構造

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Multi-tier Web Application Stack'

# パラメータ（ユーザー入力）
Parameters:
  Environment:
    Type: String
    Default: dev
    AllowedValues: [dev, stg, prod]
    Description: Environment name

  InstanceType:
    Type: String
    Default: t3.micro
    Description: EC2 Instance Type

# 条件分岐（本番のみ Multi-AZ など）
Conditions:
  IsProd: !Equals [!Ref Environment, prod]
  IsNotDev: !Not [!Equals [!Ref Environment, dev]]

# リソース定義
Resources:
  # VPC
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: !Sub '${Environment}-vpc'
        - Key: Environment
          Value: !Ref Environment

  # Subnet（AZ ごと）
  SubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: !Select [0, !GetAZs '']
      Tags:
        - Key: Name
          Value: !Sub '${Environment}-subnet-a'

  # Security Group
  WebSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow HTTP/HTTPS
      VpcId: !Ref MyVPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0
      Tags:
        - Key: Name
          Value: !Sub '${Environment}-web-sg'

  # IAM ロール（Lambda / EC2 用）
  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: !Sub '${Environment}-lambda-role'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

  # Lambda 関数
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: !Sub '${Environment}-my-function'
      Runtime: python3.12
      Handler: index.handler
      Role: !GetAtt LambdaExecutionRole.Arn
      Code:
        ZipFile: |
          def handler(event, context):
              return {
                  'statusCode': 200,
                  'body': 'Hello from Lambda!'
              }
      Environment:
        Variables:
          ENVIRONMENT: !Ref Environment

  # RDS インスタンス（本番のみ Multi-AZ）
  MyDatabase:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Snapshot  # 重要：スタック削除時にスナップショット作成
    Properties:
      DBInstanceIdentifier: !Sub '${Environment}-db'
      Engine: mysql
      EngineVersion: '8.0.35'
      DBInstanceClass: !If [IsProd, db.r6g.large, db.t3.micro]
      AllocatedStorage: !If [IsProd, '100', '20']
      StorageType: gp3
      MultiAZ: !If [IsProd, true, false]
      MasterUsername: admin
      MasterUserPassword: !Sub '{{resolve:secretsmanager:${Environment}/db:SecretString:password}}'
      VPCSecurityGroups:
        - !Ref WebSecurityGroup
      BackupRetentionPeriod: !If [IsProd, 30, 7]
      PreferredBackupWindow: '03:00-04:00'
      PreferredMaintenanceWindow: 'sun:04:00-sun:05:00'
      Tags:
        - Key: Name
          Value: !Sub '${Environment}-database'

# 出力（他スタックが参照可能）
Outputs:
  VPCId:
    Description: VPC ID
    Value: !Ref MyVPC
    Export:
      Name: !Sub '${Environment}-VPC-ID'

  SubnetId:
    Description: Subnet A ID
    Value: !Ref SubnetA
    Export:
      Name: !Sub '${Environment}-SubnetA-ID'

  LambdaFunctionArn:
    Description: Lambda Function ARN
    Value: !GetAtt MyFunction.Arn
    Export:
      Name: !Sub '${Environment}-LambdaArn'

  DatabaseEndpoint:
    Description: RDS Endpoint
    Value: !GetAtt MyDatabase.Endpoint.Address
    Export:
      Name: !Sub '${Environment}-DBEndpoint'

Intrinsic Functions（組み込み関数）

関数	説明	例
`!Ref`	パラメータ・リソース参照	`!Ref Environment`
`!GetAtt`	リソース属性取得	`!GetAtt MyFunction.Arn`
`!Sub`	文字列置換	`!Sub '${Environment}-suffix'`
`!If`	条件分岐	`!If [IsProd, large, small]`
`!Select`	配列から選択	`!Select [0, !GetAZs '']`
`!Split`	文字列分割	`!Split [',', 'a,b,c']`
`!Join`	配列を結合	`!Join ['-', [a, b, c]]`
`!ImportValue`	クロススタック参照	`!ImportValue OtherStack-VPC-ID`
`!Equals`	等価比較（条件用）	`!Equals [!Ref Env, prod]`
`!And`, `!Or`, `!Not`	論理演算	`!And [Condition1, Condition2]`

動的参照（Secrets Manager / SSM Parameter Store）

# Secrets Manager から機密情報を取得
DBPassword: !Sub '{{resolve:secretsmanager:${Environment}/db:SecretString:password}}'

# SSM Parameter Store から設定値を取得
ImageId: !Sub '{{resolve:ssm:/ami/latest:1}}'
APIKey: !Sub '{{resolve:ssm-secure:/prod/api-key:1}}'

# CloudFormation 擬似パラメータ
AccountId: !Sub '${AWS::AccountId}'
Region: !Sub '${AWS::Region}'
StackName: !Sub '${AWS::StackName}'
StackId: !Sub '${AWS::StackId}'

主要ユースケース

1. マルチアカウント・マルチリージョン環境構築

Organizations 配下の 100+ アカウント、複数リージョンに標準セキュリティ設定・ネットワーク設定を一括展開。

# StackSet テンプレート
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Baseline Security Stack - StackSet'

Resources:
  # CloudTrail（全リージョン対応）
  TrailBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'cloudtrail-logs-${AWS::AccountId}-${AWS::Region}'
      VersioningConfiguration:
        Status: Enabled
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

  CloudTrail:
    Type: AWS::CloudTrail::Trail
    DependsOn: TrailBucketPolicy
    Properties:
      S3BucketName: !Ref TrailBucket
      IsLogging: true
      IsMultiRegionTrail: true
      IncludeGlobalServiceEvents: true
      EnableLogFileValidation: true
      EventSelectors:
        - ReadWriteType: All
          IncludeManagementEvents: true

2. CI/CD パイプラインとの自動化

GitHub/GitLab と統合して、PR → Change Set 作成 → Review → Merge → 自動 apply。

# CodePipeline から CloudFormation 実行
aws cloudformation create-change-set \
  --stack-name production-api \
  --change-set-name auto-update-$(date +%s) \
  --template-url https://s3.amazonaws.com/my-bucket/template.yaml \
  --parameters ParameterKey=Environment,ParameterValue=prod \
  --capabilities CAPABILITY_NAMED_IAM

# Change Set 自動実行（承認済みの場合）
aws cloudformation execute-change-set \
  --stack-name production-api \
  --change-set-name auto-update-xxxxx

3. データレイク構築（S3 + Glue + Athena）

データレイク基盤を CloudFormation で標準化。

Resources:
  DataLakeBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 'data-lake-${AWS::AccountId}'
      VersioningConfiguration:
        Status: Enabled

  GlueCatalog:
    Type: AWS::Glue::Catalog
    # AWS Glue Data Catalog の設定

  AthenaWorkgroup:
    Type: AWS::Athena::WorkGroup
    Properties:
      Name: !Sub '${Environment}-workgroup'
      WorkGroupConfiguration:
        ResultConfigurationUpdates:
          OutputLocation: !Sub 's3://${DataLakeBucket}/athena-results/'

4. サンドボックス環境の自動プロビジョニング

開発者がセルフサービスで臨時の開発環境を作成。

Parameters:
  DeveloperName:
    Type: String
    Description: Developer name for sandbox

  ExpirationDate:
    Type: String
    Default: '2026-12-31'
    Description: Sandbox expiration date

Resources:
  SandboxVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      Tags:
        - Key: Owner
          Value: !Ref DeveloperName
        - Key: Expires
          Value: !Ref ExpirationDate

5. Disaster Recovery（DR）環境

ホットスタンバイ環境を別リージョンで自動構築。

Conditions:
  IsSecondaryRegion: !Equals [!Ref AWS::Region, us-west-2]

Resources:
  # プライマリ環境
  PrimaryRDS:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceIdentifier: primary-db
      # ...

  # セカンダリ環境（読み取り専用レプリカ）
  SecondaryRDS:
    Type: AWS::RDS::DBInstanceReadReplica
    Condition: IsSecondaryRegion
    Properties:
      SourceDBInstanceIdentifier: arn:aws:rds:us-east-1:...

6. SaaS テンプレート（テナント自動プロビジョニング）

新規テナント登録時に VPC・DB・アプリケーション環境を自動作成。

Parameters:
  TenantId:
    Type: String
  TenantName:
    Type: String
  TenantPlan:
    Type: String
    AllowedValues: [free, pro, enterprise]

Resources:
  TenantDatabase:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceIdentifier: !Sub 'tenant-${TenantId}-db'
      DBInstanceClass: !If
        - IsPro
        - db.r6g.xlarge
        - db.t3.micro
      Tags:
        - Key: TenantId
          Value: !Ref TenantId

7. マイグレーション（オンプレ → AWS）

既存オンプレリソースを AWS に段階的に移行。

8. コンプライアンス・ガバナンス

CloudFormation Guard・Hooks で規制要件を自動チェック。

9. 本番環境の自動スケーリング

AutoScaling Group を CloudFormation で定義。

10. リリース・ロールバック自動化

CloudFormation スタック更新で新バージョン、ロールバック時は前バージョン復旧。

Change Sets と Drift Detection

初心者向けメモ： Change Sets は「提案書」のようなもの。実際に変更するまえに、何が変わるかを確認し、承認後に実行します。

Change Sets の流れ

# 1. Change Set 作成（変更を提案）
aws cloudformation create-change-set \
  --stack-name production-api \
  --change-set-name update-lambda-runtime \
  --template-body file://template.yaml \
  --parameters ParameterKey=Environment,ParameterValue=prod \
  --capabilities CAPABILITY_NAMED_IAM

# 2. Change Set を確認
aws cloudformation describe-change-set \
  --stack-name production-api \
  --change-set-name update-lambda-runtime

# 出力例：
# {
#   "Changes": [
#     {
#       "Type": "Resource",
#       "ResourceChange": {
#         "Action": "Modify",
#         "LogicalResourceId": "MyFunction",
#         "ResourceType": "AWS::Lambda::Function",
#         "Details": [
#           {
#             "Target": {
#               "Attribute": "Properties",
#               "Name": "Runtime"
#             },
#             "Evaluation": "Dynamic",
#             "ChangeSource": "DirectModification"
#           }
#         ]
#       }
#     }
#   ]
# }

# 3. 承認後に実行
aws cloudformation execute-change-set \
  --stack-name production-api \
  --change-set-name update-lambda-runtime

# 4. スタック更新状況を監視
aws cloudformation wait stack-update-complete \
  --stack-name production-api

Drift Detection（ドリフト検出）

CloudFormation で管理しているリソースが、手動でコンソール変更されていないかを検出。

# ドリフト検出開始
aws cloudformation detect-stack-drift \
  --stack-name production-api

# ドリフト結果を確認
aws cloudformation describe-stack-drift-detection-status \
  --stack-drift-detection-id <drift-detection-id>

# 出力例：
# {
#   "StackDriftDetectionStatus": "DETECTION_COMPLETE",
#   "StackDriftStatus": "DRIFTED",
#   "DriftedStackResourceCount": 2
# }

# 詳細を確認
aws cloudformation list-stack-resources \
  --stack-name production-api

# ドリフトしたリソースを修復（テンプレートに合わせて戻す）
aws cloudformation update-stack \
  --stack-name production-api \
  --template-body file://template.yaml

Nested Stack

初心者向けメモ： Nested Stack は「テンプレートの中にテンプレートを埋め込む」機能。複数のテンプレートを再利用でき、大規模な CloudFormation を「分割・管理」できます。

Nested Stack の構造

parent-stack.yaml
├── VPC スタック（vpc-stack.yaml）
├── Database スタック（database-stack.yaml）
└── Application スタック（app-stack.yaml）

実装例

# parent-stack.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Multi-tier Application - Parent Stack'

Parameters:
  Environment:
    Type: String
    Default: dev

Resources:
  # VPC スタック
  VPCStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      StackName: !Sub '${Environment}-vpc-stack'
      TemplateURL: https://s3.amazonaws.com/my-bucket/vpc-stack.yaml
      Parameters:
        Environment: !Ref Environment
      Tags:
        - Key: Environment
          Value: !Ref Environment

  # Database スタック（VPC に依存）
  DatabaseStack:
    Type: AWS::CloudFormation::Stack
    DependsOn: VPCStack
    Properties:
      StackName: !Sub '${Environment}-db-stack'
      TemplateURL: https://s3.amazonaws.com/my-bucket/database-stack.yaml
      Parameters:
        VPCId: !GetAtt VPCStack.Outputs.VPCId
        SubnetId: !GetAtt VPCStack.Outputs.SubnetId
        Environment: !Ref Environment

Outputs:
  VPCId:
    Value: !GetAtt VPCStack.Outputs.VPCId

  DatabaseEndpoint:
    Value: !GetAtt DatabaseStack.Outputs.DBEndpoint

# vpc-stack.yaml（ネストされたスタック）
AWSTemplateFormatVersion: '2010-09-09'
Description: 'VPC Stack'

Parameters:
  Environment:
    Type: String

Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16

  MySubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: 10.0.1.0/24

Outputs:
  VPCId:
    Value: !Ref MyVPC
    Export:
      Name: !Sub '${Environment}-VPCId'

  SubnetId:
    Value: !Ref MySubnet
    Export:
      Name: !Sub '${Environment}-SubnetId'

StackSet（マルチアカウント・マルチリージョン）

初心者向めモ： StackSet を使うと、1 つのテンプレートを複数の AWS アカウント・複数リージョンに一括デプロイできます。Organizations 配下の全アカウントに「標準セキュリティ設定」を自動適用する場合に最適。

StackSet の流れ

# 1. StackSet を作成
aws cloudformation create-stack-set \
  --stack-set-name baseline-security \
  --template-body file://baseline-template.yaml \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
  --capabilities CAPABILITY_NAMED_IAM

# 2. 対象アカウント・リージョンを指定
aws cloudformation create-stack-instances \
  --stack-set-name baseline-security \
  --deployment-targets OrganizationalUnitIds='["ou-root-xxxxxxxx"]' \
  --regions ap-northeast-1 us-east-1 eu-west-1 \
  --operation-preferences MaxConcurrentPercentage=25

# 3. Organizations 新規アカウント作成時に自動展開
# → SERVICE_MANAGED mode なら、新規アカウント自動 scope 対象化

# 4. StackSet 更新（全インスタンスに適用）
aws cloudformation update-stack-set \
  --stack-set-name baseline-security \
  --template-body file://updated-template.yaml \
  --operation-preferences MaxConcurrentPercentage=50

# 5. StackSet インスタンス削除
aws cloudformation delete-stack-instances \
  --stack-set-name baseline-security \
  --deployment-targets Accounts='["123456789012"]' \
  --regions ap-northeast-1 \
  --retain-stacks false  # true=スタックは残す、false=削除

SERVICE_MANAGED vs SELF_MANAGED

項目	SERVICE_MANAGED	SELF_MANAGED
セットアップ	Organizations 統合（簡単）	アカウントごと許可設定（複雑）
新規アカウント	自動 Scope 対象化	手動追加必要
権限管理	AWS が管理	自分で管理
推奨用途	Organizations 環境	レガシー・複雑な要件

Custom Resources（Lambda backed）

初心者向めモ： CloudFormation がネイティブ対応していないリソース（サードパーティ API・カスタム処理）を、Lambda で実現できます。

Custom Resource 実装

Resources:
  # Custom Resource（Lambda で実装）
  CustomDomain:
    Type: Custom::DomainRegistration
    Properties:
      ServiceToken: !GetAtt CustomResourceFunction.Arn
      DomainName: my-app.example.com
      DomainProvider: GoDaddy  # サードパーティ
      ApiKey: !Sub '{{resolve:secretsmanager:godaddy-api-key:SecretString:key}}'

  # Lambda バックエンド
  CustomResourceFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: cfn-custom-resource
      Runtime: python3.12
      Handler: index.handler
      Role: !GetAtt LambdaRole.Arn
      Code:
        ZipFile: |
          import cfnresponse
          import boto3
          import requests
          import json

          def handler(event, context):
              try:
                  request_type = event['RequestType']
                  props = event['ResourceProperties']
                  domain = props['DomainName']
                  api_key = props['ApiKey']

                  if request_type == 'Create':
                      # GoDaddy API でドメイン登録
                      response = requests.post(
                          'https://api.godaddy.com/v1/domains',
                          headers={'Authorization': f'Bearer {api_key}'},
                          json={'domain': domain}
                      )
                      response_data = {
                          'DomainId': response.json()['id']
                      }

                  elif request_type == 'Update':
                      # 更新処理（必要に応じて）
                      response_data = {'DomainId': event['PhysicalResourceId']}

                  elif request_type == 'Delete':
                      # GoDaddy API でドメイン削除
                      requests.delete(
                          f'https://api.godaddy.com/v1/domains/{event["PhysicalResourceId"]}',
                          headers={'Authorization': f'Bearer {api_key}'}
                      )
                      response_data = {}

                  cfnresponse.send(
                      event, context, cfnresponse.SUCCESS,
                      response_data,
                      physicalResourceId=response_data.get('DomainId', 'custom-resource')
                  )

              except Exception as e:
                  cfnresponse.send(
                      event, context, cfnresponse.FAILED,
                      {'Error': str(e)}
                  )

  LambdaRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Modules / CloudFormation Registry

初心者向めモ： CloudFormation Registry は「サードパーティ・リソース」を一元管理するレジストリ。Lambda 関数・HTTP エンドポイント・リソースプロバイダーを登録・共有できます。

CloudFormation Registry へのリソース登録

# 1. リソースプロバイダーを開発（RPDK）
cfn init
cfn submit --dry-run

# 2. AWS アカウントに登録
cfn submit --set-type-default --region us-east-1

# 3. テンプレートで使用

Resources:
  # サードパーティ・リソース（Datadog など）
  DatadogMonitor:
    Type: Datadog::Monitors::Monitor
    Properties:
      Name: My CloudFormation Monitor
      Type: metric alert
      Query: 'avg(last_5m):avg:system.cpu{*} > 0.9'
      Message: CPU is high

Resource Import

初心者向めモ： 既存 AWS リソースを CloudFormation で管理下に取り込みます。コンソール手作業で作ったリソースを、後から CloudFormation で管理したい場合に活用。

Import の流れ

# 1. CloudFormation テンプレートを用意（リソース定義だけ）
cat > import-template.yaml <<EOF
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  ImportedRDS:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceIdentifier: my-existing-db
      # 他の属性は既存リソースから引き継ぎ
EOF

# 2. Change Set で import を実行
aws cloudformation create-change-set \
  --stack-name imported-stack \
  --change-set-name import-rds \
  --template-body file://import-template.yaml \
  --change-set-type IMPORT \
  --resources-to-import '[
    {
      "LogicalResourceId": "ImportedRDS",
      "PhysicalResourceId": "my-existing-db"
    }
  ]'

# 3. 確認して実行
aws cloudformation execute-change-set \
  --stack-name imported-stack \
  --change-set-name import-rds

CloudFormation Hooks

初心者向めモ： Hooks は「デプロイ前のポリシーチェック」。規制要件（タグ必須、暗号化必須、パブリックアクセス禁止）を自動チェックし、違反スタックをブロックできます。

Hooks の使用例

# 1. Hooks をアカウントレベルで登録
aws cloudformation set-type-configuration \
  --arn arn:aws:cloudformation:us-east-1:aws:hook/required-tags/default \
  --configuration '{
    "CloudFormationConfiguration": {
      "HookConfiguration": {
        "TargetOperations": ["CREATE_UPDATE"],
        "Properties": {
          "TagKeys": "Environment,CostCenter,Owner"
        }
      }
    }
  }'

# 2. テンプレートをデプロイ（Hooks が自動チェック）
aws cloudformation create-stack \
  --stack-name my-stack \
  --template-body file://template.yaml

# Hooks が違反を検出 → デプロイ失敗
# Error: Resource [MyRDS] is missing required tag 'CostCenter'

CloudFormation Guard

初心者向めモ： Guard は「Policy as Code」ツール。CloudFormation テンプレートがポリシーに違反していないかを検証。Terraform の Sentinel / OPA に相当。

Guard ポリシーの例

# required-tags.guard
rule REQUIRED_TAGS {
  Resources.*.Properties.Tags[*].Key == "Environment"
  Resources.*.Properties.Tags[*].Key == "CostCenter"
  Resources.*.Properties.Tags[*].Key == "Owner"
}

# s3-encryption.guard
rule S3_ENCRYPTION_ENABLED {
  Resources[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[0].ServerSideEncryptionByDefault.SSEAlgorithm == "AES256"
  }
}

# no-public-rds.guard
rule NO_PUBLIC_RDS {
  Resources[ Type == "AWS::RDS::DBInstance" ] {
    Properties.PubliclyAccessible == false
  }
}

# Guard 検証
cfn-lint --rules required-tags.guard template.yaml

# 出力：
# E3001 | Template is not valid YAML | template.yaml
# W2001 | Resource [MyDB] violates rule REQUIRED_TAGS

CDK / SAM との関係

初心者向めモ： AWS CDK・SAM は、高レベルの言語・DSL で書いた後、CloudFormation テンプレートに変換（合成）します。最終的にはすべて CloudFormation を使用します。

関係図

┌─────────────────────────────────────────────────┐
│ IaC ツール選択                                    │
├─────────────────────────────────────────────────┤
│                                                 │
│ AWS CDK（TypeScript/Python/Java/C#）            │
│   ↓ cdk synth                                   │
│   CloudFormation YAML 生成                       │
│   ↓ cdk deploy                                  │
│   AWS CloudFormation スタック作成・更新          │
│                                                 │
│ AWS SAM（Serverless Application Model）         │
│   ↓ sam build                                   │
│   ↓ sam deploy                                  │
│   CloudFormation スタック作成                    │
│                                                 │
│ 生 CloudFormation（YAML/JSON）                  │
│   ↓ aws cloudformation create-stack            │
│   AWS リソース作成                              │
│                                                 │
└─────────────────────────────────────────────────┘

CDK例（TypeScript）

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as rds from 'aws-cdk-lib/aws-rds';
import * as lambda from 'aws-cdk-lib/aws-lambda';

export class MyStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // VPC 作成（L2 Construct）
    const vpc = new ec2.Vpc(this, 'MyVPC', {
      cidrMask: 24,
      maxAzs: 2,
    });

    // RDS インスタンス
    const db = new rds.DatabaseInstance(this, 'MyDatabase', {
      engine: rds.DatabaseInstanceEngine.mysql({ version: rds.MysqlEngineVersion.VER_8_0 }),
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.MICRO),
      vpc,
    });

    // Lambda 関数
    const fn = new lambda.Function(this, 'MyFunction', {
      runtime: lambda.Runtime.PYTHON_3_12,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'),
      environment: {
        DB_HOST: db.dbInstanceEndpointAddress,
      },
    });
  }
}

// スタックをデプロイ
const app = new cdk.App();
new MyStack(app, 'MyStack');

SAM例（YAML）

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: 'Serverless Application'

Globals:
  Function:
    Timeout: 30
    MemorySize: 256
    Runtime: python3.12

Resources:
  # Lambda 関数（AWS::Serverless::Function）
  HelloFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: hello-function
      Handler: app.lambda_handler
      CodeUri: ./src/
      Events:
        HelloEvent:
          Type: Api
          Properties:
            Path: /hello
            Method: GET
            RestApiId: !Ref MyApi

  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: dev

  # DynamoDB テーブル
  UsersTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: users
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: id
          AttributeType: S
      KeySchema:
        - AttributeName: id
          KeyType: HASH

Service Catalog 連携

初心者向めモ： Service Catalog は「IT が事前に承認したテンプレート」をセルフサービスで提供。開発者が安全に環境作成できます。

# Service Catalog ポートフォリオ作成
aws servicecatalog create-portfolio \
  --display-name "Development Environment Portfolio" \
  --description "Self-service development stacks"

# CloudFormation テンプレートを Product として登録
aws servicecatalog create-product \
  --name "Python Web Server" \
  --product-type CLOUD_FORMATION_TEMPLATE \
  --provisioning-artifact-parameters TemplateUrl=s3://my-bucket/python-app.yaml

# エンドユーザーがプロダクトをプロビジョニング
aws servicecatalog provision-product \
  --product-name "Python Web Server" \
  --provisioning-parameters Key=EnvironmentName,Value=dev-env

CloudFormation vs Terraform vs CDK vs Pulumi

初心者向めモ： CloudFormation は「AWS 専業」だが新サービス即対応。Terraform は「マルチクラウド」で豊富なエコシステム。CDK は「プログラマー向け」。Pulumi は「汎用言語」で記述。選択は組織・要件次第。

項目	CloudFormation	Terraform	CDK	Pulumi
言語	YAML/JSON	HCL	TS/Python/Java	Python/Go/TS/C#
学習曲線	⭐⭐（YAML シンプル）	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
マルチクラウド	❌ AWS のみ	✅ 3000+	❌ AWS のみ	✅
State 管理	AWS 管理	tfstate ファイル	AWS 管理	Pulumi SaaS / Self-hosted
変更差分確認	✅ Change Sets	✅ terraform plan	✅（preview）	✅
ドリフト検出	✅ 組み込み	❌ plan で検出	❌	❌
新サービス対応	✅ 即日	⏳ 数週間	✅ 自動更新	⏳
エコシステム	AWS 公式モジュール	Registry 豊富	Construct Hub	Package Manager
ロールバック	✅ 自動ロールバック	❌ 手動対応	✅	✅
組織採用	AWS 専業企業	マルチクラウド	AWS 深い統合	複雑なロジック

選択基準

AWS 専業・新サービス即対応 → CloudFormation
マルチクラウド・豊富なモジュール → Terraform
プログラマー向け・複雑なロジック → CDK / Pulumi
サーバーレス特化 → SAM

他の類似ツールとの比較

ツール	タイプ	言語	対応範囲	主な用途
CloudFormation	宣言型 IaC	YAML/JSON	AWS のみ	AWS インフラ管理・StackSet マルチアカウント
Terraform	宣言型 IaC	HCL	3000+	マルチクラウド・OSS エコシステム
Pulumi	汎用言語	Python/Go/TS	マルチクラウド	プログラマー向け・複雑ロジック
AWS CDK	汎用言語	TS/Python/Java	AWS のみ	CloudFormation の高レベル抽象化
AWS SAM	簡略 DSL	YAML	AWS サーバーレス	Lambda・API Gateway 特化
Ansible	命令型	YAML	OS・アプリ	サーバー構成・オーケストレーション
Chef / Puppet	命令型	Ruby/DSL	OS・アプリ	構成管理・ノードベース
Crossplane	宣言型 IaC	YAML	マルチクラウド	Kubernetes ネイティブ IaC

クライアントとエコシステム

初心者向めモ： CloudFormation 単体でも十分ですが、補助ツール（cfn-lint・taskcat・cfn-guard）を組み合わせることで、運用を大幅に効率化できます。

cfn-lint

CloudFormation テンプレートの品質チェック・ベストプラクティス違反検出。

# インストール
pip install cfn-lint

# 検証実行
cfn-lint template.yaml

# 出力例：
# E3001 | Template is not valid JSON | template.yaml
# W2001 | Found property without default | Parameter

cfn-nag

セキュリティ・ベストプラクティス違反を検出。

# インストール
pip install cfn-nag

# 実行
cfn-nag template.yaml

# 出力：
# W1：WARNING | S3 bucket does not have logging enabled
# F1：FAIL | RDS instance is publicly accessible

taskcat

CloudFormation テンプレートの機能テスト・マルチリージョン・マルチパラメータテスト。

# インストール
pip install taskcat

# テスト実行
taskcat test run -t template.yaml

# 複数リージョン・パラメータを並列テスト

AWS CloudFormation Designer

ビジュアルテンプレートエディタ。ドラッグ＆ドロップでリソース配置。

CLI コマンド

# テンプレート検証
aws cloudformation validate-template \
  --template-body file://template.yaml

# スタック作成
aws cloudformation create-stack \
  --stack-name my-stack \
  --template-body file://template.yaml \
  --parameters ParameterKey=Environment,ParameterValue=prod

# スタック更新（Change Set 経由）
aws cloudformation create-change-set \
  --stack-name my-stack \
  --change-set-name update-1 \
  --template-body file://template.yaml

# スタック削除
aws cloudformation delete-stack \
  --stack-name my-stack

ベストプラクティス

初心者向めモ： CloudFormation は強力なツールですが、使い方を誤るとインフラが壊れます。以下のプラクティスを守りましょう。

1. テンプレート管理

✅ DO：

テンプレートを Git で管理
PR → レビュー → マージ → デプロイのワークフロー
テンプレートの変更はすべて Change Sets で確認
.gitignore に機密情報を含めない

❌ DON’T：

テンプレートのハードコード（API キー・パスワード）
テンプレートを S3 に直接修正（Git 経由以外）
Change Sets なしで直接スタック更新

2. スタック設計

✅ DO：

リソースを機能別・更新頻度別に複数スタックに分割
VPC・ネットワーク安定スタック（ほぼ変更なし）
Database スタック（変更は慎重に）
Application スタック（頻繁に更新）
大スタック（500 リソース超）は避ける

❌ DON’T：

全リソースを 1 スタックに詰め込む
更新頻度の異なるリソースを混在
超大規模スタック（タイムアウト・エラー増加）

3. 削除ポリシー

✅ DO：

Data ストレージ（RDS・S3）には DeletionPolicy: Retain または Snapshot
重要データベース：SnapshotOnDelete
一時的なリソース：Delete

❌ DON’T：

DeletionPolicy 未設定で本番 RDS・S3 を削除
スタック削除 → データベース・バケット永久削除

MyDatabase:
  Type: AWS::RDS::DBInstance
  DeletionPolicy: Snapshot  # 重要！
  Properties:
    # ...

MyBucket:
  Type: AWS::S3::Bucket
  DeletionPolicy: Retain  # スタック削除時も保持
  Properties:
    # ...

4. Parameters・Conditions の活用

✅ DO：

Environment パラメータで dev/stg/prod を切り替え
Condition で本番環境のみ Multi-AZ・バックアップを有効化
秘密情報は Secrets Manager / SSM Parameter Store から動的参照

❌ DON’T：

ハードコード（Environment をテンプレートに直書き）
パスワード・API キーを平文記述

Parameters:
  Environment:
    Type: String
    AllowedValues: [dev, stg, prod]

Conditions:
  IsProd: !Equals [!Ref Environment, prod]

Resources:
  MyRDS:
    Type: AWS::RDS::DBInstance
    Properties:
      MultiAZ: !If [IsProd, true, false]
      BackupRetentionPeriod: !If [IsProd, 30, 7]

5. Change Sets の活用

✅ DO：

本番変更は必ず Change Set で確認
Change Set を実行前に複数人で Review
Change Set の実行結果をモニタリング

❌ DON’T：

Change Sets スキップして直接 apply
1 人で本番 Change Set 実行

6. タグの統一

✅ DO：

全リソースに共通タグ：Environment・CostCenter・Owner
タグは規制要件（コスト配分・リソース追跡）に必須
タグを CloudFormation Guard で強制

❌ DON’T：

タグなしリソース
タグ命名規則が不統一

Resources:
  MyResource:
    Type: AWS::EC2::Instance
    Properties:
      Tags:
        - Key: Environment
          Value: !Ref Environment
        - Key: CostCenter
          Value: Engineering
        - Key: Owner
          Value: DevOps Team

7. Nested Stacks の使い分け

✅ DO：

再利用可能な Module（VPC・Database・Security）を Nested Stack に
Nested Stack テンプレートを S3 に保存
Nested Stack 出力を親スタックで参照

❌ DON’T：

すべてを Nested Stack に（複雑化）
1 レベル Nested Stack のみ（深い入れ子は避ける）

8. ドリフト検出の定期実行

✅ DO：

定期的（週 1 回）にドリフト検出を実行
ドリフト検出結果をログ保存
ドリフトが見つかったら原因を調査・修復

❌ DON’T：

ドリフト検出を実行しない（手動変更を見過ごす）
ドリフト見つかったまま放置

# CloudWatch Events で定期実行
aws events put-rule --name cfn-drift-detection-daily \
  --schedule-expression "cron(0 2 * * ? *)"

トラブルシューティング

初心者向めモ： CloudFormation は時々エラーを出します。以下のトラブルを参考に対処してください。

1. “Stack with id XXX does not exist”

スタックが存在しない、またはスタック削除中。

# スタック一覧確認
aws cloudformation describe-stacks \
  --region ap-northeast-1

# 削除中のスタック確認
aws cloudformation describe-stacks \
  --stack-name my-stack
  # StackStatus: DELETE_IN_PROGRESS

2. “Resource creation cancelled”

リソース作成時に依存リソースが未作成。

# 依存関係を明示
Resources:
  SubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      # ...

  RouteTable:
    Type: AWS::EC2::RouteTable
    DependsOn: SubnetA  # 依存を明示
    Properties:
      VpcId: !Ref MyVPC

3. “User: arn:aws:iam::XXX is not authorized”

IAM 権限不足。

# IAM ポリシーに CloudFormation 権限を追加
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloudformation:*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}

4. “Rollback in progress”

スタック更新失敗時に自動ロールバック中。完了まで待つ。

# スタック削除（ロールバック完了後）
aws cloudformation delete-stack --stack-name my-stack

5. “Change set did not contain any changes”

変更がない場合。Change Set 削除。

aws cloudformation delete-change-set \
  --stack-name my-stack \
  --change-set-name no-changes-cs

6. “Template contains invalid JSON”

JSON テンプレートの構文エラー。YAML に変換（推奨）。

# YAML 検証
cfn-lint template.yaml

# CloudFormation 検証
aws cloudformation validate-template \
  --template-body file://template.yaml

7. “DeletionPolicy cannot be modified”

既存リソースの DeletionPolicy 変更は不可。新規リソース作成時に設定。

8. “Maximum number of templates exceeded”

アカウント側のテンプレート数上限。古いテンプレート削除。

2025-2026 最新動向

初心者向けメモ： CloudFormation は進化し続けています。IaC Generator（2024年2月GA）・Hooks GA・Stack Refactoring・AI テンプレート生成など、2025-2026 年の重要なトレンドを把握しましょう。

1. IaC Generator（既存リソース自動コード化）

既存 AWS リソースから自動 CloudFormation テンプレート生成。Cloud Control API 対応リソースのみサポート。スキャン有効期間は 30 日間で、同一スキャンから複数テンプレート生成可能。

# スキャン対象リソースを選択
aws cloudformation create-generated-template \
  --resources AWS::EC2::Instance/i-1234567890abcdef0 AWS::RDS::DBInstance/mydb

# 生成されたテンプレートを確認
aws cloudformation describe-generated-template \
  --generated-template-name cfn-generated-template-xxx

2. CloudFormation Hooks GA

ポリシーチェック機能が GA。組織全体に規制要件・ベストプラクティスを強制。

3. Stack Refactoring

既存スタック内のリソースを再構成・分割。ダウンタイム最小化。

# スタック分割（VPC スタックを抽出）
aws cloudformation create-change-set \
  --change-set-type IMPORT \
  --stack-name vpc-stack

4. IPv6 サポート強化

IPv6 デュアルスタック環境の CloudFormation テンプレート対応。

5. AI テンプレート生成（自然言語）

「Python Web サーバー + RDS + ALB」と説明 → テンプレート自動生成。

6. Resource Control Policies との統合

AWS Identity Center で CloudFormation リソース作成の許可/拒否を管理。

7. セキュリティ強化

OIDC トークンベース認証：GitHub Actions / GitLab CI から OIDC で認証
Resource-based Policy：スタック・テンプレートのアクセス制御
Secrets Manager 統合拡大：より多くの動的参照パターン

8. パフォーマンス改善

並列リソース作成：依存関係がないリソースは同時作成
クイックスタック更新：変更が軽微な場合、更新時間短縮

学習リソース

公式ドキュメント

学習サイト・チュートリアル

AWS Training & Certification：aws.training
- CloudFormation Fundamentals
- Advanced CloudFormation
AWS Samples：github.com/aws-samples
- CloudFormation テンプレート集

認定資格

AWS Certified Solutions Architect：CloudFormation 知識必須
AWS Certified DevOps Engineer：CloudFormation + CI/CD

コミュニティ

AWS forums：forums.aws.amazon.com
Stack Overflow：amazon-cloudformation タグ
GitHub Discussions：aws-cloudformation

実装例・活用シーン

シーン 1：スタートアップの AWS インフラ構築

新規スタートアップが 0 から AWS インフラを構築。CloudFormation で即座にデプロイ、StackSet で本番環境自動複製。

シーン 2：エンタープライズ Organizations 管理

100+ AWS アカウント、複数リージョンに標準セキュリティ・コンプライアンス設定を StackSet で一括適用。

シーン 3：Disaster Recovery（DR）環境

プライマリ環境が障害 → CloudFormation でセカンダリリージョンに即座に本番環境再構築（RTO/RPO 最小化）。

シーン 4：マルチテナント SaaS

新規テナント登録 → CloudFormation で自動 VPC・DB・アプリケーション環境プロビジョニング。

シーン 5：CI/CD パイプライン統合

GitHub PR → Change Set 作成 → Review → Merge → 自動 deploy で安全な本番更新。

導入ロードマップ

Phase 1：基礎構築（1-2 月）

CloudFormation の基本学習（テンプレート・リソース・スタック）
開発環境で簡単な AWS リソース作成
YAML テンプレート・パラメータ・Condition 習得
Change Sets でリソース更新実施

チェックリスト：

[ ] CloudFormation テンプレート作成経験
[ ] AWS 認証（IAM）設定
[ ] 簡単なスタック作成・更新・削除
[ ] Change Sets 確認・実行

Phase 2：チーム導入（3-6 月）

Git によるテンプレート管理
PR レビューワークフロー整備
cfn-lint / cfn-guard 導入
小規模本番環境で試験

チェックリスト：

[ ] Git リポジトリ構築
[ ] CI/CD パイプライン（Change Set 自動作成）
[ ] cfn-lint / cfn-nag 自動化
[ ] Nested Stacks テンプレート化

Phase 3：本番展開（6-12 月）

既存本番環境の段階的 import
Nested Stack / StackSet 構成設計
Drift Detection 定期実行
CloudFormation Guard ポリシー定義

チェックリスト：

[ ] 既存インフラ 50% 以上 import
[ ] Nested Stack 再利用テンプレート 5+ 個
[ ] StackSet でマルチアカウント展開
[ ] Guard Policy 定義・運用

Phase 4：運用成熟化（1+ 年）

GitOps ワークフロー定着
Hooks によるポリシーチェック自動化
継続的な改善・アップグレード

実装チェックリスト

セットアップ

[ ] CloudFormation テンプレート管理用 Git リポジトリ作成
[ ] S3 バケット（テンプレート保存用）作成
[ ] IAM ロール（CloudFormation 実行権限）作成
[ ] AWS CLI 環境設定

テンプレート設計

[ ] パラメータを定義（環境別の値は Parameter で記述）
[ ] Condition で本番/開発を分岐
[ ] リソースを機能別・更新頻度別に分割
[ ] Nested Stack で再利用性向上
[ ] DeletionPolicy を重要リソースに設定

品質・検証

[ ] cfn-lint でテンプレート検証
[ ] cfn-nag でセキュリティチェック
[ ] CloudFormation Guard ポリシー定義
[ ] 複数パラメータ・マルチリージョンテスト

運用管理

[ ] Change Sets で差分確認（本番変更は必須）
[ ] Drift Detection 定期実行
[ ] スタック削除テスト（DeletionPolicy 確認）
[ ] バージョン管理（Git tag でテンプレート履歴管理）

セキュリティ

[ ] 秘密情報を Secrets Manager / SSM Parameter Store に移行
[ ] IAM ロールを最小権限に設定
[ ] Hooks で規制要件チェック自動化
[ ] 機密情報を Output に expose しない

まとめ

CloudFormation は、「AWS ネイティブの IaC サービス」。YAML/JSON テンプレートで VPC・EC2・RDS・Lambda 等のインフラを宣言的に定義し、スタックでリソースをグループ管理する。Change Sets で本番への影響を事前確認、StackSets でマルチアカウント展開、Drift Detection で手動変更を監視する。CDK・SAM のバックエンドとしても機能し、AWS の全サービスに即日対応するネイティブ IaC の標準選択肢。

主要なメッセージ

宣言型管理：「目標状態」を YAML/JSON で記述、実現方法は CloudFormation が決定
AWS ネイティブ：AWS 新サービスに即日対応、深い統合
Change Sets ワークフロー：差分事前確認 → 承認 → 適用で安全な変更
StackSet マルチアカウント：100+ アカウント・複数リージョンに一括展開
Drift Detection：手動変更を検出・通知
Nested Stacks：テンプレートの再利用・モジュール化
Custom Resources：未対応リソースを Lambda で実現
CDK・SAM 統合：高レベル抽象化で効率化（最終的に CloudFormation 生成）
CloudFormation Guard：Policy as Code で規制要件自動チェック
AI テンプレート生成：自然言語 → CloudFormation テンプレート自動化

次のステップ

ローカル開発：簡単なテンプレート作成で基本習得（1-2 週間）
チーム導入：Git + PR ワークフロー + cfn-lint（1-2 ヶ月）
本番活用：既存リソース import → Change Sets + Drift Detection（3-6 ヶ月）
運用成熟化：StackSet・Hooks・Policy as Code（1+ 年）

CloudFormation を使いこなすことで、インフラの変更を 安全・透明・効率的 に行い、チーム全体でスケーラブルな AWS 基盤を構築できます。

参考文献

公式リソース

バリデーション・品質ツール

cfn-lint GitHub（テンプレート検証）
cfn-lint PyPI（Python パッケージ）
cfn-guard GitHub（Policy as Code・Rust実装）
cfn-nag GitHub（セキュリティチェック）
taskcat GitHub（テンプレートテスト）
CloudFormation Designer（ビジュアルエディタ）

IaC ツール比較・統合

Terraform Documentation（HCL・マルチクラウド）
Terraform vs CloudFormation vs Pulumi（2026年比較）
Pulumi Documentation（Python/TypeScript・プログラミング言語）
HashiCorp Terraform（インフラ統一管理）

学習リソース

セキュリティ・ポリシー

コミュニティ

最終更新：2026-04-26 バージョン：v1.1（IaC Generator・cfn-guard・Terraform/Pulumi比較追加）

目次

AWS CloudFormation 完全ガイド 2026

初心者から実務者向けの包括的解説

ドキュメントの目的

2026 年の CloudFormation エコシステム

目次

概要

CloudFormation の位置づけ

CloudFormation が解決する課題

1. 手作業の廃止と再現性

2. AWS 新サービスへの即時対応

3. インフラの差分管理と安全な更新

4. マルチアカウント・マルチリージョン一括管理

主な特徴

アーキテクチャ

テンプレート（YAML/JSON）と Intrinsic Functions

テンプレート基本構造

Intrinsic Functions（組み込み関数）

動的参照（Secrets Manager / SSM Parameter Store）

主要ユースケース

1. マルチアカウント・マルチリージョン環境構築

2. CI/CD パイプラインとの自動化

3. データレイク構築（S3 + Glue + Athena）

4. サンドボックス環境の自動プロビジョニング

5. Disaster Recovery（DR）環境

6. SaaS テンプレート（テナント自動プロビジョニング）

7. マイグレーション（オンプレ → AWS）

8. コンプライアンス・ガバナンス

9. 本番環境の自動スケーリング

10. リリース・ロールバック自動化

Change Sets と Drift Detection

Change Sets の流れ

Drift Detection（ドリフト検出）

Nested Stack

Nested Stack の構造

実装例

StackSet（マルチアカウント・マルチリージョン）

StackSet の流れ

SERVICE_MANAGED vs SELF_MANAGED

Custom Resources（Lambda backed）

Custom Resource 実装

Modules / CloudFormation Registry

CloudFormation Registry へのリソース登録

Resource Import

Import の流れ

CloudFormation Hooks

Hooks の使用例

CloudFormation Guard

Guard ポリシーの例

CDK / SAM との関係

関係図

CDK例（TypeScript）

SAM例（YAML）

Service Catalog 連携

CloudFormation vs Terraform vs CDK vs Pulumi

選択基準

他の類似ツールとの比較

クライアントとエコシステム

cfn-lint

cfn-nag

taskcat

AWS CloudFormation Designer

CLI コマンド

ベストプラクティス

1. テンプレート管理

2. スタック設計

3. 削除ポリシー

4. Parameters・Conditions の活用

5. Change Sets の活用

6. タグの統一

7. Nested Stacks の使い分け

8. ドリフト検出の定期実行

トラブルシューティング

1. “Stack with id XXX does not exist”

2. “Resource creation cancelled”

3. “User: arn:aws:iam::XXX is not authorized”

4. “Rollback in progress”

5. “Change set did not contain any changes”

6. “Template contains invalid JSON”

7. “DeletionPolicy cannot be modified”