どうも、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を指定