【AWS】CloudFormationまとめ

どうも、iron千葉です。
CloudFormationについて、ユーザガイドを見てポイントをまとめました。
ポイントだけ確認したい人、ざっと全体を見たい人におすすめです


# CloudFormationとは？
* AWSリソース（EC2やRDS、S3等）を自動で構築できる
* テンプレート（JSON形式）を１回作成すると、同じ構成を何度も構築できる
* CloudFormation自体は利用無料（利用したインスタンス等のみ料金がかかる）
* テンプレート化することにより、AWSの構成を見える化、バージョン管理もできる

# CloudFormationの概念
* テンプレート：JSON形式で記述する、AWSリソースのパラメータ
* 複数のリソースを連携できる（例えば、EC2作成→EIP割り当て等）
* テンプレート=スタック（AWSではリソースはスタック単位で管理される）
    * スタック作成時にスタックで利用するテンプレートを指定する

# CloudFormationの仕組み
* 通常利用時のワークフロー
    * テンプレート作成
    * ローカルまたはS3へ保存
    * スタック作成（作成したテンプレートを指定）
    * 自動でプロビジョニングされる
* スタックの更新時のワークフロー
    * テンプレートの修正
    * ローカルまたはS3へ保存
    * 更新したテンプレートを指定
    * 変更したリソースのみ更新される
* 更新時の挙動
    * インスタンスタイプを変更すると、インスタンスは再起動する
    * AMIを変更すると、新しいインスタンスが作成された後、古いインスタンスは削除される※インスタンス交換（AMI-IDやパブリックIPは変わるよ！）
    * cfn-hupを利用して、アプリケーションをデプロイしている場合、反映まで最大15分かかる（cfn-hupがデフォルト１５分間で実行されるため）
    * cfn-hupを利用してアプリケーションをデプロイする場合でAuto-Scalingグループを利用している場合、インスタンス間で同時に反映されない（cfn-hupの起動タイミングが異なるため）
        * cfn-hupがすべてのインスタンスで同時に実行された場合、更新中はサービスが利用できなくなることがある
        * cfn-hupが異なるタイミングで実行された場合、古いバージョンと新しいバージョンが混在する可能性がある
        * これらを問題を解決するには？UpdatePolicy 属性を利用することで回避できる（↓の方参照）
* スタックの削除
    * スタックを削除すると、スタック内のAWSリソースはすべて削除される
    * 削除ポリシーにより、削除したくないリソースを削除しないようにできる（Retain、スナップショット）
* 注意事項
    * 自動でプロビジョニングさせるにはIAMでの権限が必要→EC2作成権限がなければ作成はできずに失敗する
    * 途中で失敗した場合、ロールバックされる（途中まで作成したものを全て削除する）

# カスタムリソース
* AWSリソース（EC2やS3）ではないリソースをCloudFormationに含めることができる
* カスタムリソースの仕組み
    * 登場人物：AWSカスタマ - CloudFormation - プロバイダ
    * カスタムリソースを含んだスタックを作成（サービストークンと入出力パラメータ含む）
    * CloudFormationはSNSを利用して、プロバイダと通信をする（作成・更新・削除、入力データを連携する）→プロバイダはレスポンスに利用するS3 URLを返す
    * プロバイダが処理をして、成功・失敗を返す。成功した場合はリソースの情報、失敗した場合はエラー内容を返す。CloudFormationが受け取る
    * CloudFormationからAWSカスタマに通知
* つまり、AWSリソース以外を利用する場合は、SNSを介してCloudFormationリソースとして利用できる

# CloudFormer
* 既存のAWSリソースからテンプレートを作成できる
* CloudFormer専用のインスタンスを一時的に起動させ、Webアクセス、対象のリソースを選択、あとは待つだけ
* 専用インスタンスは利用が終わったら削除
* 実際に利用すときは、作成されたテンプレート内容を確認・修正して問題ないことを確認してから利用する（そのまま使わない）


# ベストプラクティス

## ライフサイクルと所有権によるスタック
* 規模が大きくなると管理が煩雑になるため、複数のテンプレートに分けて管理する
* テンプレートはライフサイクル、権限（操作する部署・チーム）が同じものでまとめる
* Web用、DB用、ネットワーク用等、管理者ごとチームごとに分割する

## IAM を使用したアクセス制御
* CloudFormationの操作（スタックの作成・表示・削除）をIAMの権限で制御できる
* テンプレートに記載されているAWSリソースの操作権限も必要になる

## すべてのリソースタイプのクォータを確認する
* スタック作成前に、VPCやEC2等の作成数上限に達していないか確認する

## テンプレートを再利用して複数の環境にスタックを複製する
* 同じテンプレートを使いまわせる
* 検証と本番で同じテンプレートを利用することにより、構成を同じにできる

## スタックのネスト
* テンプレートにテンプレートを指定できる（ネスト）
* 例えば、ロードバランサのテンプレート、EC2テンプレートを参照するテンプレートを作成できる
* →この時に、ロードバランサのテンプレートを更新した場合、それを参照するスタックの更新時に反映できる

## 認証情報はテンプレートに直接記載しない
* テンプレートではなく、入力パラメータとして使用する
* NoEchoプロパティを利用する（入力した値が***と表示される）

## AWS固有パラメータを利用
* キーペア等、AWS固有パラメータを利用すると、毎回検証して表示してくれる

## パラメータの制約の使用
* 文字数制限、文字制限、許可パターンを指定する

## ソフトウェアをインストールしたい場合はヘルパースクリプトを利用する
* cfn-initｎ等

## テンプレートを利用する前に検証をする
* 構文エラー、循環などのチェック
* コンソールから利用する場合は、自動で検証する
* CLI利用時は、テンプレート検証アクションを実行する必要あり

## CloudFormationのAWSリソース更新時の注意
* リソースをマネジメントコンソールで直接変更しない
* CloudFomationスタックとリソース情報に不整合が生じエラーになる
* リソース変更時は、必ずテンプレート更新、スタック更新する

## スタックポリシーを使用する
* 重要なスタックリソースを保護する

## CloudTrailの利用
* CloudTrailを利用し、CloudFormationAPI呼び出しを追跡できる

## テンプレートをバージョン管理する
* バージョン管理することで、インフラのバージョン管理が可能
* 任意の過去の状態に戻すことが可能

# IAMでのアクセス制御
* IAMを利用することにより柔軟なアクセス制御ができる
* スタックの作成、削除、更新権限の割り当て
* さらに、EC2やS3等のAWSリソースの利用権限も必要
* たとえば、ネットワークチームはVPC、運用チームはEC2起動・停止、開発は全ての権限等チームごとにIAMユーザを作成し、権限を設定できる

# CloudFormationから作ったリソースを、CloudFormation管理から外す
* deleteポリシーでRetainを指定すると、削除せずにCloudFormation管理から外せる
* 削除時に、RDSやEBSのスナップショットを取得してから削除も可能。deleteポリシーにsnapshotを指定