AWS CloudFormation（Black Belt解説）

記事説明

この記事では、「Management & Governance」分野の重要なサービスである、
AWS CloudFormationについて説明します。

↓Management & Governanceの重要なサービス一覧
・Amazon CloudWatch
・AWS CloudFormation
・AWS CloudTrail
・AWS Config
・AWS Systems Manager

↓参考：【AWS Black Belt Online Seminar】AWS CloudFormation
https://d1.awsstatic.com/webinars/jp/pdf/services/20200826_AWS-BlackBelt_AWS-CloudFormation.pdf

AWS CloudFormationの位置づけ

Amazon Management Toolsとして、5つの機能が提供されています。

１．リソースプロビジョニング
⇒テンプレート定義によるインフラプロビジョニングの自動化
主なサービス：AWS CloudFormationなど

２．構成管理
⇒パッケージの導入、ソフトウェアとリソースのコンフィグレーション、パッチ適用
主なサービス：AWS Systems Managerなど

３．モニタリング
⇒AWSリソースやアプリケーションに対する、モニタリング、アラーム、
メトリクスダッシュボード、ログ、イベント管理
主なサービス：Amazon CloudWatch

４．ガバナンスとコンプライアンス
⇒リソースインベントリ、構成変更管理、ユーザ操作とAPI呼び出しの記録、
セルフマネージドなITカタログ
主なサービス：AWS CloudTrail、AWS Config

５．リソース最適化
⇒コスト低減、パフォーマンス向上、セキュリティの改善に対する推奨事項の自動提供
主なサービス：AWS Trusted Advisor

このうち、AWS CloudFormationは
Amazon Management Toolsの中のリソースプロビジョニング機能として用いられます。

AWS CloudFormationの概要

概要としては、
「EC2 や ELB といった AWS リソースの環境構築を、テンプレート を元に自動化できる」
サービスで、自分好みのシステム構成を自動的に構築することができます。
※テンプレート作成時のフォーマットはJSON or YAML

特にCloudFormationを利用する際の課金は無く、
プロビジョニングされたAWSリソースに対して料金が発生します。

↓引用元
https://d1.awsstatic.com/webinars/jp/pdf/services/20200826_AWS-BlackBelt_AWS-CloudFormation.pdf

テンプレート（Template）・・・
作成するリソースを定義します。設定ファイルのようなものです。

スタック（Stack）・・・
プロビジョニングしたいリソースの集合です。

 CloudFormationの基本機能

作成・・・
テンプレートに定義された構成でスタックを自動作成します。
並列でリソースを作成し依存関係がある場合は自動的に解決してくれます。

変更・・・
スタックに前回のテンプレートとの差分を適用します。
リソース変更時は 無停止変更 or 再起動 or 再作成 のいずれかが発生します。
Change Set を作ることで差分の内容を事前に確認可能となります。

削除・・・
依存関係を解決しつつリソースを全て削除します。
データストアはスナップショット取得 / 保持が可能です。

 CloudFormation利用の流れ

大きな流れは下記の通りになります。

１．YAML/JSONでテンプレートを作成
↓
２．AWS上にアップロード
↓
３．スタックの作成
↓
４．リソースの作成と管理

↓引用元
https://d1.awsstatic.com/webinars/jp/pdf/services/20200826_AWS-BlackBelt_AWS-CloudFormation.pdf

１．YAML/JSONでテンプレートを作成　について
どのリソースをどう構築するか、テンプレートに記述していきます。
それぞれの要素について、以下に記載しておきます。

AWSTemplateFormatVersion・・・
AWS CloudFormationテンプレートバージョンです。
現状は「2010-09-09」が唯一有効な値ですが、
AWS Serverless Application Model(SAM)を利用する際は、別の定義が必要です。

Description・・・
テンプレートの説明文です。

Metadata・・・
テンプレートに関する追加情報です。リソースの説明文などを記載します。

例）
Resources:
  MyInstance:
    Type: "AWS::EC2::Instance”
Metadata:
  MyInstance:
    Description: "Information about the instance"

Parameters・・・
スタック作成 or 更新時にユーザ入力を求めるパラメータです。
KeyPairの名前や、DBのユーザ名など、変数とするものを記載します。
同時に最小文字数等も指定できます。

例）
Parameters:
  VPCStack:
    Type: String
    Default: handson-cfn
  DBUser:
    Type: String
Default: dbmaster
  DBPassword:
    Type: String
    Default: H&ppyHands0n
    MinLength: 8
    NoEcho: true

プロパティ	内容
Type	データ型を表す。String（文字列）やNumber（数値）など。
Default	デフォルト値
NoEcho	入力時に*****となる（パスワードなどで使用）
AllowedValues	入力可能値の一覧指定 （例：[“true”,”false”] ）
AllowedPattern	正規表現で入力可能パターンを指定（例：[a-zA-Z]*）
MaxLength	最大文字数
MinLength	最小文字数
MaxValue	最大値
MinValue	最小値
Description	プロパティの詳細説明
ConstraintDescription	入力した値がAllowedPatternやMaxLengthなどの制約に引っかかった時に表示する説明（どのような制約があるかの説明を記述）

Mappings・・・
キーと値のマッピングです。
リージョンやパラメータによって、値が変わる場合に利用します。（汎用性UP）
下記の場合は、リージョンによって利用するキーペアを可変にしています。

例）
Mappings:
  RegionMap:
    us-east-1:
      "AMI": "ami-xxxxxxxxxx"
      "KEYPAIR": "myKey-east"
    us-west-1:
      "AMI": "ami-yyyyyyyyyy"
      "KEYPAIR": "myKey-west”
    ap-northeast-1:
      "AMI": "ami-zzzzzzzzzz"
      "KEYPAIR": "myKeytokyo"

また、ここで可変としたデータについては、
Functionの”FindInMap”を使って値を取得します。

例）
Resources:
  Ec2Instance:
    Type: "AWS::EC2::Instance"
    Properties:
    ImageId: !FindInMap [ RegionMap, !Ref "AWS::Region", AMI ]

“Fn::FindInMap”の引数は[ “MapName”, “Key”, “Value”]となるので、
Mappingsで指定したRegionMapのKEYPAIR=【合致したリージョン】のAMIを取得します。

Conditions・・・
条件名と条件判断内容を記載します。
Resourcesセクションなどでリソース作成時に利用しますが、
あまり条件を付けすぎると煩雑になってしまうので要注意です。

例）
Parameters:
  EnvType:
    Description: "Environment type."
    Default: "development"
    Type: String
    AllowedValues: ["production", "staging", "development"]
    ConstraintDescription: "must specify."
Conditions:
  CreateProdResources: {"Fn::Equals" : [{"Ref" : "EnvType"}, “production"]}
Resources:
  Ec2Instance:
    Type: "AWS::EC2::Instance"
      Condition: "CreateProdResources"

上記の例は既にややこしいですが、EnvType（環境タイプ）のパラメータとして、
「production（開発環境）」であれば、条件が成立して、EC2インスタンスを作成します。

Transform・・・
サーバーレスアプリケーションや定型コンテンツ挿入等のための、マクロを指定します。
拡張機能のようなイメージですね。

【★必須】Resources・・・
Amazon EC2やAmazon RDSなど、スタックを構成するリソースとプロパティを記載します。
実際に構成するリソースを記載する部分です。

例）
Resources:
  EC2WebServer01:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref EC2AMI
      InstanceType: t2.micro
      SubnetId:
        Fn::ImportValue: !Sub ${VPCStack}-PublicSubnet1

Outputs・・・
スタック構築後にAWS CloudFormationから出力させる値です。
DNS名やEIPの値など、AWS側で自動的に割り振られるデータを出力したい時に使います。

例）
Resources:
  EC2WebServer01:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref EC2AMI
      InstanceType: t2.micro
Outputs:
  EC2WebServer01:
    Value: !Ref EC2WebServer01
    Export:
      Name: !Sub ${AWS::StackName}-EC2WebServer01

「Name：」の部分が組み込み関数となっており、
下記の図のように、「エクスポート名」部分に出力することができます。

↓引用元
https://d1.awsstatic.com/webinars/jp/pdf/services/20200826_AWS-BlackBelt_AWS-CloudFormation.pdf

２．AWS上にアップロード　について
コンソールやパイプラインを用いてアップロードします。
なお、S3に既にアップロードされている場合は、それを利用できます。

３．スタックの作成　について
コンソールやCLIを用いてスタックを作成します。
スタック単位でリソースの管理が可能で、スタックの削除を実行すると、
スタックにひもづくリソースが削除されます。
使用するリソースおよびリソースの構築順は、テンプレートの依存関係から
CloudFormationが自動的に決定します。

↓引用元
https://d1.awsstatic.com/webinars/jp/pdf/services/20200826_AWS-BlackBelt_AWS-CloudFormation.pdf

４．リソースの作成と管理　について
作成されたリソースに対して、保守運用を行います。
また、リソースが最新化された場合、テンプレートの変更等を忘れずに行っていきます。

開発・テストにおける有効なツールについて

Visual Studio Code・・・
自動補完してくれるので、効率よくテンプレートの作成ができます。

cfn-lint・・・
定義が書いてあるものの使われていないもの、型の違いに対して警告を出します。

TaskCat・・・
複数の AWS リージョンで並列にテンプレートからスタックを作成してテストが可能です。

cfn-nag・・・
潜在的なセキュリティの問題を開発プロセスの初期段階で気づくことができます。

CloudFormation Guard・・・
CloudFormationテンプレート検証を行うためのツールセット

ぜひ開発時には利用してみてください。

デプロイについて

デプロイの方法は大きく３種類あります。

１．AWS CodePipeline を利用したデプロイ
安全に、自動でデプロイできます。デプロイリソースへの手動アクセスを阻止し、
ヒューマンエラーを減らします。

２．Change Setで 変更内容を事前確認した上でのデプロイ
変更を要求した箇所とその変更により影響を受ける箇所を事前に確認可能です。
注意点としては、変更によってリソースが中断されたり、再作成される可能性があります。

３．StackSets (マルチリージョン/マルチアカウント）
一回の操作で複数のアカウントやリージョンへスタックを作成、更新、削除
できるCloudFormationの機能です。

↓引用元
https://d1.awsstatic.com/webinars/jp/pdf/services/20200826_AWS-BlackBelt_AWS-CloudFormation.pdf

デプロイ後の運用について

テンプレートを変更したい場合・・・
現行のスタックからドリフト検出を行い、差分をテンプレートに反映し、
直接更新 or Change Setでスタックを更新します。

スタックとリソースの削除保護・・・
これには３つの方法があります。

１．ユーザのIAMポリシーでCloudFormationの利用権限を絞ることができます。
２．スタックポリシーでスタックの削除保護を行うことができます。
⇒特定のリソースに対する変更を禁止できます。
３．リソースのDeletionPolicyで削除されないようにできます。
⇒スタックが削除された場合に、リソースを保持したり、スナップショットを取得できます。

CloudFormation リソースインポート・・・
手動で作成したAWSリソースをCloudFormationスタックにインポートして管理することができます。
リソースをスタックから切り離し、別のスタック管理下に移動することも可能です。
上記より、既存スタックのリファクタリング難易度が下がります。

CloudFormationのベストプラクティス

規模が大きくなると単一のテンプレートでの管理は手間と時間がかかり、
変更時の影響範囲も大きくなるため、スタックを分割した方が良いです。

大きく分けて、３つ分けた方が良いとされています。

１．アプリケーション層　←　最も変更が多い
・EC2
・RDS
・ELB
・SQSキュー
・Active Directory
・CI/CDサーバ

２．セキュリティ層
・セキュリティグループ
・IAMロール
・IAMグループ
・IAMポリシー

３．ネットワーク層　←　最も変更が少ない
・VPC
・サブネット
・エンドポイント
・ルートテーブル
・内部DNS（Route53）
・IGW, NAT GW, VGW

↓引用元
https://d1.awsstatic.com/webinars/jp/pdf/services/20200826_AWS-BlackBelt_AWS-CloudFormation.pdf

まとめ

AWSのサービスの中で非常に重要な位置づけである、CloudFormationに関する記事でした。
BlackBeltの資料も図をたくさん用いられており、分かりやすかったです。

上手く使うことができれば、開発コストを非常に下げることができるサービスなので、
バシバシ使えるようになりたいと思います。

こういったサービスを利用できることが、
開発者側の観点で、クラウドサービスを利用する最大のメリットと思います。

それでは、お読みいただきありがとうございました。