Edited at

【AWS】CloudFormationまとめ

More than 1 year has passed since last update.

どうも、iron千葉です。

CloudFormationについて、ユーザガイドを見てポイントをまとめました。

ポイントだけ確認したい人、ざっと全体を見たい人におすすめです


CloudFormationとは?


  • AWSリソース(EC2やRDS、S3等)を自動で構築できる

  • テンプレート(JSON形式)を1回作成すると、同じ構成を何度も構築できる

  • CloudFormation自体は利用無料(利用したインスタンス等のみ料金がかかる)

  • テンプレート化することにより、AWSの構成を見える化、バージョン管理もできる


CloudFormationの概念


  • テンプレート:JSON形式で記述する、AWSリソースのパラメータ

  • 複数のリソースを連携できる(例えば、EC2作成→EIP割り当て等)

  • テンプレート=スタック(AWSではリソースはスタック単位で管理される)


    • スタック作成時にスタックで利用するテンプレートを指定する




CloudFormationの仕組み


  • 通常利用時のワークフロー


    • テンプレート作成

    • ローカルまたはS3へ保存

    • スタック作成(作成したテンプレートを指定)

    • 自動でプロビジョニングされる



  • スタックの更新時のワークフロー


    • テンプレートの修正

    • ローカルまたはS3へ保存

    • 更新したテンプレートを指定

    • 変更したリソースのみ更新される



  • 更新時の挙動


    • インスタンスタイプを変更すると、インスタンスは再起動する

    • AMIを変更すると、新しいインスタンスが作成された後、古いインスタンスは削除される※インスタンス交換(AMI-IDやパブリックIPは変わるよ!)

    • cfn-hupを利用して、アプリケーションをデプロイしている場合、反映まで最大15分かかる(cfn-hupがデフォルト15分間で実行されるため)

    • 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-initn等


テンプレートを利用する前に検証をする


  • 構文エラー、循環などのチェック

  • コンソールから利用する場合は、自動で検証する

  • CLI利用時は、テンプレート検証アクションを実行する必要あり


CloudFormationのAWSリソース更新時の注意


  • リソースをマネジメントコンソールで直接変更しない

  • CloudFomationスタックとリソース情報に不整合が生じエラーになる

  • リソース変更時は、必ずテンプレート更新、スタック更新する


スタックポリシーを使用する


  • 重要なスタックリソースを保護する


CloudTrailの利用


  • CloudTrailを利用し、CloudFormationAPI呼び出しを追跡できる


テンプレートをバージョン管理する


  • バージョン管理することで、インフラのバージョン管理が可能

  • 任意の過去の状態に戻すことが可能


IAMでのアクセス制御


  • IAMを利用することにより柔軟なアクセス制御ができる

  • スタックの作成、削除、更新権限の割り当て

  • さらに、EC2やS3等のAWSリソースの利用権限も必要

  • たとえば、ネットワークチームはVPC、運用チームはEC2起動・停止、開発は全ての権限等チームごとにIAMユーザを作成し、権限を設定できる


CloudFormationから作ったリソースを、CloudFormation管理から外す


  • deleteポリシーでRetainを指定すると、削除せずにCloudFormation管理から外せる

  • 削除時に、RDSやEBSのスナップショットを取得してから削除も可能。deleteポリシーにsnapshotを指定