AWS CloudFormation完全ガイド：15分で理解する基礎から実践まで【2024年版】

SHARE

目次

目次へ

AWS CloudFormationとは？初心者でもわかる基礎知識

Infrastructure as Code（IaC）の概要と重要性

AWSのインフラ構築、覚えることが多くて大変だと感じていませんか？手作業での構築は時間がかかるうえ、人的ミスのリスクも高くなります。そんな課題を解決するのが、Infrastructure as Code（IaC）です。

IaCとは、インフラの構成をコードで管理する手法です。AWS CloudFormationは、AWSが提供する代表的なIaCサービスで、以下のような特徴があります：

  • インフラの構成をJSONやYAMLで記述
  • テンプレートを使って環境を自動構築
  • 環境の複製や削除が容易
  • バージョン管理が可能

CloudFormationが解決する3つの課題

CloudFormationは、以下の主要な課題を効果的に解決します：

  1. 構築時間の短縮
  • テンプレートの再利用による迅速なデプロイ
  • 複数リソースの同時作成
  • パラメータ化による柔軟な環境構築
  1. 人的ミスの防止
  • コードによる構成管理
  • テンプレートの検証機能
  • 変更履歴の追跡
  1. 一貫性の確保
  • 環境間の構成差異を排除
  • スタックによる関連リソースの一括管理
  • テンプレートの標準化

他のIaCツールとの比較：なぜCloudFormationを選ぶべきか

市場には様々なIaCツールが存在しますが、CloudFormationには以下の独自の利点があります：

ツール名特徴メリットデメリット
CloudFormationAWSネイティブ・新機能への即時対応
・高度な統合
・無料		・AWS限定
・学習曲線が急
Terraformマルチクラウド・複数クラウド対応
・豊富なプロバイダ		・状態管理が必要
・別途学習が必要
Ansible構成管理型・シンプルな文法
・エージェントレス		・実行速度が遅い
・べき等性の管理

CloudFormationを選ぶべき主な理由：

  1. AWSサービスとの完全な統合
  • 最新のAWSサービスに即時対応
  • AWSのベストプラクティスに準拠
  • AWS固有の機能を最大限活用可能
  1. コスト面での優位性
  • 追加料金なしで利用可能
  • リソース作成時のみ課金
  • テンプレート保存に費用不要
  1. 充実したサポートとコミュニティ
  • AWSの公式サポート
  • 豊富なサンプルテンプレート
  • 活発なユーザーコミュニティ

CloudFormationは、特にAWSを主体としたインフラ構築を行う場合に最適なツールと言えます。次のセクションでは、実際のテンプレートの書き方について詳しく解説していきます。

CloudFormationテンプレートの書き方：完全解説

YAMLとJSONの違いと選び方

CloudFormationテンプレートは、YAMLまたはJSON形式で記述できます。それぞれの特徴を理解し、適切な形式を選択しましょう。

YAML形式の特徴：

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-unique-bucket-name
      VersioningConfiguration:
        Status: Enabled

JSON形式の特徴：

{
  "Resources": {
    "MyBucket": {
      "Type": "AWS::S3::Bucket",
      "Properties": {
        "BucketName": "my-unique-bucket-name",
        "VersioningConfiguration": {
          "Status": "Enabled"
        }
      }
    }
  }
}

形式選択のポイント：

項目YAMLJSON
可読性◎ 高い△ やや低い
記述量◎ 少ない△ 多い
厳密性△ やや低い◎ 高い
学習性○ 容易○ 容易

テンプレートの基本構造と必須要素

CloudFormationテンプレートは、以下の主要セクションで構成されています：

AWSTemplateFormatVersion: '2010-09-09'  # テンプレートバージョン（必須）
Description: 'テンプレートの説明文'      # 説明（推奨）

Parameters:  # 入力パラメータの定義
  EnvironmentType:
    Type: String
    AllowedValues: [dev, prod]

Mappings:  # 固定値のマッピング
  EnvironmentMap:
    dev:
      InstanceType: t2.micro
    prod:
      InstanceType: t2.small

Resources:  # AWSリソースの定義（必須）
  MyEC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !FindInMap [EnvironmentMap, !Ref EnvironmentType, InstanceType]

Outputs:  # 出力値の定義
  InstanceId:
    Description: EC2インスタンスID
    Value: !Ref MyEC2Instance

各セクションの役割：

  1. AWSTemplateFormatVersion: テンプレートのバージョンを指定
  2. Description: テンプレートの説明文を記載
  3. Parameters: 可変値をパラメータとして定義
  4. Mappings: 固定値の対応表を定義
  5. Resources: 作成するAWSリソースを定義
  6. Outputs: スタック作成後に参照可能な出力値を定義

パラメータとマッピングの効果的な使い方

パラメータの活用例：

Parameters:
  # 環境タイプの選択
  EnvironmentType:
    Type: String
    Default: dev
    AllowedValues:
      - dev
      - staging
      - prod
    Description: デプロイする環境を選択してください

  # インスタンスタイプの選択
  InstanceType:
    Type: String
    Default: t2.micro
    AllowedValues:
      - t2.micro
      - t2.small
      - t2.medium
    Description: EC2インスタンスタイプを選択してください

  # キーペアの指定
  KeyPairName:
    Type: AWS::EC2::KeyPair::KeyName
    Description: SSH接続用のキーペアを選択してください

マッピングの活用例：

Mappings:
  # リージョン別AMI ID
  RegionMap:
    ap-northeast-1:
      AMI: ami-0123456789abcdef0
    ap-southeast-1:
      AMI: ami-0123456789abcdef1

  # 環境別インスタンス設定
  EnvironmentConfig:
    dev:
      InstanceType: t2.micro
      VolumeSize: 20
    prod:
      InstanceType: t2.small
      VolumeSize: 50

# マッピングの使用例
Resources:
  MyEC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !FindInMap [RegionMap, !Ref 'AWS::Region', AMI]
      InstanceType: !FindInMap [EnvironmentConfig, !Ref EnvironmentType, InstanceType]

実践的なTips：

  1. パラメータのバリデーション設定
  • AllowedValues で選択肢を制限
  • MinLength/MaxLength で文字列長を制限
  • MinValue/MaxValue で数値範囲を制限
  1. デフォルト値の適切な設定
  • 最も一般的な値をデフォルトに
  • 環境変数との連携を考慮
  1. マッピングの効果的な利用
  • リージョン別の設定管理
  • 環境別のリソース設定
  • 定数値の一元管理

これらの基本要素を理解し、適切に組み合わせることで、柔軟で再利用性の高いテンプレートを作成できます。

実践！はじめてのCloudFormation構築ガイド

VPCとEC2インスタンスの構築手順

まずは基本的なネットワーク環境とEC2インスタンスの構築から始めましょう。以下のテンプレートで、VPCとパブリックサブネット、EC2インスタンスを作成します。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Basic VPC and EC2 Instance Template'

Parameters:
  EnvironmentName:
    Description: 環境名
    Type: String
    Default: dev

  VpcCIDR:
    Description: VPCのCIDRブロック
    Type: String
    Default: 10.0.0.0/16

  PublicSubnetCIDR:
    Description: パブリックサブネットのCIDRブロック
    Type: String
    Default: 10.0.1.0/24

Resources:
  # VPCの作成
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCIDR
      EnableDnsHostnames: true
      EnableDnsSupport: true
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-vpc

  # インターネットゲートウェイ
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-igw

  # VPCへのインターネットゲートウェイアタッチ
  AttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MyVPC
      InternetGatewayId: !Ref InternetGateway

  # パブリックサブネット
  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: !Ref PublicSubnetCIDR
      AvailabilityZone: !Select [0, !GetAZs '']
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-public-subnet

  # ルートテーブル
  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyVPC
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-public-rt

  # インターネットへのルート
  DefaultPublicRoute:
    Type: AWS::EC2::Route
    DependsOn: AttachGateway
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  # サブネットとルートテーブルの関連付け
  PublicSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable

  # EC2インスタンス用のセキュリティグループ
  EC2SecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: EC2 Security Group
      VpcId: !Ref MyVPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: 0.0.0.0/0

  # EC2インスタンス
  EC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: ami-0d52744d6551d851e  # Amazon Linux 2 AMI ID (ap-northeast-1)
      SubnetId: !Ref PublicSubnet
      SecurityGroupIds:
        - !Ref EC2SecurityGroup
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-ec2

Outputs:
  VpcId:
    Description: VPC ID
    Value: !Ref MyVPC

  PublicSubnetId:
    Description: パブリックサブネットID
    Value: !Ref PublicSubnet

  EC2InstanceId:
    Description: EC2インスタンスID
    Value: !Ref EC2Instance

S3バケットとIAMロールの設定方法

次に、S3バケットとEC2インスタンス用のIAMロールを作成します。

Resources:
  # S3バケット
  MyS3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub ${AWS::AccountId}-${EnvironmentName}-bucket
      VersioningConfiguration:
        Status: Enabled
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256

  # EC2用のIAMロール
  EC2Role:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

  # EC2インスタンスプロファイル
  EC2InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Path: /
      Roles:
        - !Ref EC2Role

よくあるエラーとトラブルシューティング

CloudFormationでよく遭遇するエラーと解決方法をまとめました：

  1. スタックの作成失敗
エラー原因解決方法
ROLLBACK_COMPLETEリソース作成の失敗エラーログを確認し、失敗したリソースの設定を見直す
UPDATE_ROLLBACK_FAILED更新時のロールバック失敗手動でリソースの状態を確認し、必要に応じて削除
ValidationErrorテンプレート構文エラーYAMLやJSONの構文を確認、インデントを修正
  1. リソース固有のエラー
  • VPC関連
  • CIDR範囲の重複
  • サブネット作成時のAZ指定ミス
  • IGWのアタッチ忘れ
  • EC2関連
  • AMI IDの無効化
  • インスタンスタイプの制限
  • セキュリティグループの設定ミス
  • IAM関連
  • ポリシードキュメントの構文エラー
  • 権限不足
  • 名前の重複

トラブルシューティングのベストプラクティス：

  1. エラーの特定と分析
  • CloudFormationコンソールでエラーメッセージを確認
  • CloudWatchログで詳細なエラー情報を確認
  • リソースの状態を個別に確認
  1. テスト環境での検証
  • 本番適用前に必ずテスト環境で確認
  • 小規模な変更から段階的に適用
  • ロールバック手順の準備
  1. バージョン管理の活用
  • テンプレートの変更履歴を管理
  • 成功したテンプレートをバックアップ
  • 変更内容のドキュメント化

CloudFormationの運用ベストプラクティス

大規模環境での効率的なスタック管理術

大規模な環境でCloudFormationを運用する際は、以下の方針に従って管理することで、保守性と運用効率を高めることができます。

  1. スタックの分割管理
# ネットワークスタック (network.yaml)
Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      # ... その他のVPC設定

Outputs:
  VpcId:
    Description: VPC ID
    Value: !Ref VPC
    Export:
      Name: !Sub ${AWS::StackName}-VpcId

# アプリケーションスタック (application.yaml)
Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      SubnetId: !ImportValue network-stack-SubnetId
      # ... その他のEC2設定

スタック分割のベストプラクティス：

レイヤー含めるリソース更新頻度
インフラ層VPC、サブネット、ルートテーブル低
セキュリティ層IAMロール、セキュリティグループ中
アプリケーション層EC2、RDS、ELB高
監視層CloudWatch、SNS中
  1. テンプレートの再利用性向上
# 共通コンポーネント (common/s3-bucket.yaml)
Parameters:
  BucketName:
    Type: String
  Environment:
    Type: String
    AllowedValues: [dev, stg, prod]

Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Ref BucketName
      Tags:
        - Key: Environment
          Value: !Ref Environment

セキュリティとコスト最適化のポイント

  1. セキュリティ強化策
Resources:
  # セキュアなS3バケットの定義
  SecureS3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
      VersioningConfiguration:
        Status: Enabled
      LoggingConfiguration:
        DestinationBucketName: !Ref LoggingBucket
        LogFilePrefix: s3-access-logs/

  # セキュリティグループのベストプラクティス
  SecureWebServerSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Secure Web Server SG
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: !Ref AllowedCidr
  1. コスト最適化戦略
  • リソースのタグ付け規則
Resources:
  EC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      Tags:
        - Key: Project
          Value: !Ref ProjectName
        - Key: Environment
          Value: !Ref Environment
        - Key: CostCenter
          Value: !Ref CostCenter
        - Key: Owner
          Value: !Ref OwnerEmail
  • コスト管理のためのパラメータ設定
Parameters:
  InstanceType:
    Type: String
    AllowedValues:
      - t3.micro
      - t3.small
    Default: t3.micro
  AutoScalingMaxSize:
    Type: Number
    Default: 4
    MaxValue: 10

自動化とCI/CDパイプラインとの統合方法

  1. CodePipelineとの統合例
Resources:
  # CodePipelineの定義
  CloudFormationPipeline:
    Type: AWS::CodePipeline::Pipeline
    Properties:
      RoleArn: !GetAtt CodePipelineRole.Arn
      Stages:
        - Name: Source
          Actions:
            - Name: Source
              ActionTypeId:
                Category: Source
                Owner: AWS
                Provider: CodeCommit
                Version: 1
              Configuration:
                RepositoryName: !Ref RepositoryName
                BranchName: main
              OutputArtifacts:
                - Name: SourceCode
        - Name: Deploy
          Actions:
            - Name: DeployToTest
              ActionTypeId:
                Category: Deploy
                Owner: AWS
                Provider: CloudFormation
                Version: 1
              Configuration:
                StackName: !Sub ${ProjectName}-test
                TemplatePath: SourceCode::template.yaml
                Capabilities: CAPABILITY_NAMED_IAM
              RunOrder: 1
  1. 変更セットを使用した安全なデプロイ
# 変更セットの作成
aws cloudformation create-change-set \
  --stack-name my-stack \
  --template-body file://template.yaml \
  --change-set-name my-changes

# 変更内容の確認
aws cloudformation describe-change-set \
  --change-set-name my-changes \
  --stack-name my-stack

# 変更の実行
aws cloudformation execute-change-set \
  --change-set-name my-changes \
  --stack-name my-stack

実装のポイント：

  1. 自動化のベストプラクティス
  • テンプレートの静的解析
  • テスト環境での自動検証
  • 承認プロセスの組み込み
  • ロールバック手順の自動化
  1. パイプラインの構成管理
  • 環境ごとのパラメータファイル管理
  • シークレット情報の安全な受け渡し
  • デプロイ履歴の追跡

CloudFormation実践事例と応用テクニック

マルチAZ構成の実装例

高可用性を実現するマルチAZ構成の実装例を紹介します。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Multi-AZ Web Application Architecture'

Parameters:
  EnvironmentName:
    Type: String
    Default: production

  VpcCIDR:
    Type: String
    Default: 10.0.0.0/16

Resources:
  # VPCの定義
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCIDR
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName}-vpc

  # マルチAZのサブネット定義
  PublicSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [0, !GetAZs '']
      CidrBlock: !Select [0, !Cidr [!Ref VpcCIDR, 4, 8]]
      MapPublicIpOnLaunch: true

  PublicSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [1, !GetAZs '']
      CidrBlock: !Select [1, !Cidr [!Ref VpcCIDR, 4, 8]]
      MapPublicIpOnLaunch: true

  # Auto Scaling Group の定義
  WebServerASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      VPCZoneIdentifier: 
        - !Ref PublicSubnet1
        - !Ref PublicSubnet2
      LaunchTemplate:
        LaunchTemplateId: !Ref LaunchTemplate
        Version: !GetAtt LaunchTemplate.LatestVersionNumber
      MinSize: 2
      MaxSize: 4
      DesiredCapacity: 2
      HealthCheckType: ELB
      HealthCheckGracePeriod: 300
      TargetGroupARNs:
        - !Ref ALBTargetGroup

  # Application Load Balancer の定義
  ApplicationLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Subnets:
        - !Ref PublicSubnet1
        - !Ref PublicSubnet2
      SecurityGroups:
        - !Ref ALBSecurityGroup

マルチAZ構成のポイント：

  1. 可用性の確保
  • 最低2つのAZにリソースを配置
  • Auto Scaling Groupの活用
  • ロードバランサーによる負荷分散
  1. 障害対策
  • ヘルスチェックの適切な設定
  • 自動復旧メカニズムの実装
  • バックアップ戦略の策定

カスタムリソースの活用シナリオ

CloudFormationでは標準でサポートされていない操作を実行するために、カスタムリソースを活用できます。

Resources:
  # Lambda関数の定義
  CustomResourceFunction:
    Type: AWS::Lambda::Function
    Properties:
      Handler: index.handler
      Role: !GetAtt LambdaExecutionRole.Arn
      Code:
        ZipFile: |
          import cfnresponse
          import boto3

          def handler(event, context):
              try:
                  if event['RequestType'] == 'Create':
                      # カスタム処理の実装
                      response_data = {"Message": "Resource created successfully"}
                      cfnresponse.send(event, context, cfnresponse.SUCCESS, response_data)
                  elif event['RequestType'] == 'Delete':
                      # 削除時の処理
                      cfnresponse.send(event, context, cfnresponse.SUCCESS, {})
                  else:
                      cfnresponse.send(event, context, cfnresponse.SUCCESS, {})
              except Exception as e:
                  cfnresponse.send(event, context, cfnresponse.FAILED, {"Error": str(e)})

  # カスタムリソースの定義
  MyCustomResource:
    Type: Custom::MyCustomResource
    Properties:
      ServiceToken: !GetAtt CustomResourceFunction.Arn
      CustomParameter: "SampleValue"

カスタムリソースの活用例：

  1. 外部APIとの連携
  • サードパーティサービスの設定
  • データベースの初期化
  • 構成情報の動的取得
  1. 高度な初期設定
  • 複雑なリソース設定の自動化
  • 動的なパラメータ生成
  • クロススタック連携

DriftDetectionを使った構成管理の自動化

CloudFormationのDrift Detection機能を活用して、インフラストラクチャの一貫性を維持する方法を紹介します。

# CloudWatch Eventsルールの定義
Resources:
  DriftDetectionRule:
    Type: AWS::Events::Rule
    Properties:
      Description: "Trigger drift detection daily"
      ScheduleExpression: "rate(1 day)"
      State: ENABLED
      Targets:
        - Arn: !GetAtt DriftDetectionFunction.Arn
          Id: "DriftDetectionTarget"

  # Drift Detection用Lambda関数
  DriftDetectionFunction:
    Type: AWS::Lambda::Function
    Properties:
      Handler: index.handler
      Role: !GetAtt LambdaExecutionRole.Arn
      Code:
        ZipFile: |
          import boto3

          def handler(event, context):
              cfn = boto3.client('cloudformation')
              stacks = cfn.list_stacks(
                  StackStatusFilter=['CREATE_COMPLETE', 'UPDATE_COMPLETE']
              )

              for stack in stacks['StackSummaries']:
                  try:
                      cfn.detect_stack_drift(StackName=stack['StackName'])
                  except Exception as e:
                      print(f"Error detecting drift for {stack['StackName']}: {str(e)}")

Drift Detectionの実装ポイント：

  1. 定期的な監視の自動化
  • 日次でのドリフト検出
  • 結果の通知設定
  • 修正アクションの自動実行
  1. 効果的な運用方法
  • 重要リソースの優先監視
  • 許容できる変更の定義
  • インシデント対応プロセスの整備

活用のベストプラクティス：

項目推奨設定理由
検出頻度日次早期発見と対応が可能
通知設定重要度別優先度に応じた対応が可能
自動修正選択的リスクを考慮して判断

これらの高度なテクニックを活用することで、より堅牢でメンテナンス性の高いインフラストラクチャを実現できます。

前の記事

【保存版】AWS CodeDeployで実現する自動デプロイ環…

次の記事

AWS Amplifyで実現する！初期費用ゼロの本番環境構築と…