AWS CloudFormation ベストプラクティス - AWS CloudFormation
ライフサイクルと所有権によるスタックの整理クロススタック参照を使用して共有リソースをエクスポートしますすべてのリソースタイプのクォータを確認するテンプレートを再利用して複数の環境にスタックを複製するネストされたスタックを使用して共通テンプレートパターンを再利用するAWS 固有のパラメータタイプの使用パラメータの制約の使用AWS::CloudFormation::Init を使用して Amazon EC2 インスタンスにソフトウェアアプリケーションをデプロイする最新のヘルパースクリプトを使用するテンプレートを使用する前に検証するAWS CloudFormation ですべてのスタックリソースを管理するスタックを更新する前に変更セットを作成するスタックポリシーを使用するコードの確認とリビジョン管理を使用してテンプレートを管理するAmazon EC2 Linux インスタンスを定期的に更新する

AWS CloudFormation ベストプラクティス

ベストプラクティスはワークフロー全体で AWS CloudFormation をより効率的かつ安全に使用するために役立つ推奨事項です。スタックの計画方法と整理方法を学習し、リソースとそこで実行するソフトウェアアプリケーションを記述するテンプレートを作成して、スタックとそのリソースを管理します。次のベストプラクティスは、現在の AWS CloudFormation クライアントの実際の経験に基づいています。

計画と編成
テンプレートの作成
スタックの管理

ライフサイクルと所有権によるスタックの整理

AWS リソースのライフサイクルと所有権を使用して、各スタックでどのリソースを使うを判断します。最初はすべてのリソースを 1 つのスタックに置いてもかまいませんが、スタックの規模が大きくなり範囲が拡大するにつれて、単一のスタックの管理は面倒で時間かかる場合があります。共通のライフサイクルと所有権を持つリソースのグループ化により、所有者は独自のプロセスやスケジュールを使用して、他のリソースに影響を与えることなくリソースのセットを変更できます。

たとえば、ロードバランサーの背後にある自動拡張インスタンスにホストされているウェブサイトを所有する開発者とエンジニアのチームがあったとしましょう。ウェブサイトは独自のライフサイクルを持ちウェブサイトチームによって保守されているため、このウェブサイトのスタックやそのリソースを作成できます。それでは、同様にバックエンドのデータベースを使用するウェブサイトがあり、そのデータベースは別のスタックでデータベース管理者が所有し保守しているとしましょう。ウェブサイトチームまたはデータベースチームがリソースを更新する必要があるときはいつでも、互いのスタックに影響を与えることなく実行できます。すべてのリソースが単一のスタックにある場合は、更新の連携や連絡は難しくなるでしょう。

スタックの整理についての詳細なガイダンスについては、2 つの一般的なフレームワークを使用できます。多層アーキテクチャーとサービス指向アーキテクチャー (SOA) です。

多層アーキテクチャーは、スタックを積み上げて構築する複数の水平の層に整理します。各層はその直下の層に依存します。各層には 1 つ以上のスタックを持つことができますが、各層のスタックは類似したライフサイクルと所有権を持つ AWS リソースを持つ必要があります。

サービス指向アーキテクチャーを使用すると、業務上の大きな問題を処理しやすい大きさに整理できます。これらのパートはそれぞれ、明確に定義された目的があり、機能の自己充足単位を表します。これらのサービスを、それぞれ独自のライフサイクルと所有者があるスタックにマッピングできます。これらのサービス (スタック) をすべて 1 つに繋いで、相互に通信するようにできます。

クロススタック参照を使用して共有リソースをエクスポートします

ライフサイクルと所有権に基づいて AWS リソースを整理するときに、別のスタックにあるリソースを使用するスタックを構築することもできます。値をハードコード化することで、または入力パラメーターを使用して、リソース名と ID を割り当てることができます。ただし、これらのメソッドはテンプレートの再利用を困難にしたり、スタック実行のオーバーヘッドを増やす場合があります。代わりに、スタックからリソースをエクスポートするクロススタック参照を使用すると、他のスタックがリソースを使用できます。スタックは Fn::ImportValue 関数を使用して、エクスポートされたリソースを呼び出して使用できます。

たとえば、VPC、セキュリティグループ、およびサブネットを含むネットワークスタックがあるかもしれません。すべてのパブリックウェブアプリケーションにこれらのリソースを使用する場合。リソースをエクスポートすることによって、パブリックウェブアプリケーションのすべてのスタックでリソースが使用できるようになります。詳細については、「チュートリアル: 別の AWS CloudFormation スタックのリソース出力を参照する」を参照してください。

すべてのリソースタイプのクォータを確認する

スタックを起動する前に、必要なすべてのリソースを AWS アカウントの制限に触れずに作成できることを確認します。制限に触れる場合は、クオータを増やすかまたは追加リソースを削除するまで、AWS CloudFormation でスタックが正常に作成されません。各サービスには、スタックを起動する前に知っておくべきさまざまな制限があります。たとえば、デフォルトでは、AWS アカウントのリージョンごとに起動できる AWS CloudFormation スタックは 200 のみです。制限およびデフォルトの制限を増やす方法の詳細については、『AWS General Reference』の「AWS サービスの制限」を参照してください。

テンプレートを再利用して複数の環境にスタックを複製する

スタックとリソースをセットアップした後、テンプレートを再利用してインフラストラクチャを複数の環境に複製できます。たとえば、開発、テスト、本番の環境を作成して、本番環境に実装する前に変更をテストすることができます。テンプレートを再利用可能にするには、パラメーター、マッピング、および条件セクションを使用してスタックの作成時にカスタマイズできるようにします。たとえば、開発環境では、本番環境と比べて低価格のインスタンスタイプを指定し、その他の構成や設定は同じにできます。パラメーター、マッピング、条件の詳細については、「テンプレートの分析」を参照してください。

ネストされたスタックを使用して共通テンプレートパターンを再利用する

インフラストラクチャが大きくなるにつれ、各テンプレートで同じコンポーネントを宣言する共通パターンができてきます。これらの共通するコンポーネントを他と分類し、専用テンプレートを作成できます。こうすると、異なるテンプレートを組み合わせることができますが、単一の統合されたスタックを作成するにはネストされたスタックを使用します。ネストされたスタックは、スタックを作成するスタックです。ネストされたスタックを作成するには、テンプレートの AWS::CloudFormation::Stack リソースを使用して他のテンプレートを参照します。

たとえば、ほとんどのスタックに使用しているロードバランサー設定があると仮定します。テンプレートに同じ構成をコピーアンドペーストする代わりに、ロードバランサーを対象にした専用テンプレートを作成できます。次に、AWS::CloudFormation::Stack リソースを使用して他のテンプレート内からそのテンプレートを参照するだけです。ロードバランサーのテンプレートが更新されれば、それを参照するスタックはすべて、スタックの更新後に更新されたロードバランサーのみを使用します。更新の簡素化に加えて、この方法により、あまり理解の深くないコンポーネントの作成や管理をエキスパートに任せることができます。お客様はそのテンプレートを参照するだけで済みます。

AWS 固有のパラメータタイプの使用

テンプレートに Amazon Virtual Private Cloud ID や Amazon EC2 キーペア名など既存の AWS 固有値の入力が必須の場合は、AWS 固有パラメータタイプを使用します。たとえば、パラメーターを AWS::EC2::KeyPair::KeyName タイプと指定して、AWS アカウントとスタックを作成するリージョンの既存のキーペア名を取得します。AWS CloudFormation はスタックを作成する前にすばやく AWS 固有パラメータタイプの値を検証します。また、AWS CloudFormation コンソールを使用する場合は、AWS CloudFormation が有効な値のドロップダウンリストを表示するため、現在の VPC ID またはキーペアの名前を調べたり暗記する必要はありません。詳細については、「パラメータ」を参照してください。

パラメータの制約の使用

制約を使用すると、許可される入力値を記述することで AWS CloudFormation がスタックを作成する前に無効な値を捕捉できます。最小文字数、最長文字数、許可パターンなどの制限を設定できます。たとえば、データベースのユーザー名の値は最小 8 文字で英数字のみ、といった制限を設定できます。詳細については、「パラメータ」を参照してください。

AWS::CloudFormation::Init を使用して Amazon EC2 インスタンスにソフトウェアアプリケーションをデプロイする

スタックを起動する際に、cfn-init ヘルパースクリプトと AWS::CloudFormation::Init リソースを使用して、Amazon EC2 インスタンスでソフトウェアアプリケーションをインストールして設定できます。AWS::CloudFormation::Init を使用することで、スクリプトで手順を順番に実行するよりも自由に設定を記述できます。また、インスタンスを作り直すことなく設定を更新できます。また設定に不具合があれば、AWS CloudFormation が生成するログで問題を調査できます。

テンプレートで、AWS::CloudFormation::Init リソースにインストールと設定の状態を指定します。cfn-init および AWS::CloudFormation::Init の使用方法についてのウォークスルーは、「AWS CloudFormation による Amazon EC2 へのアプリケーションのデプロイ.」を参照してください。

最新のヘルパースクリプトを使用する

ヘルパースクリプトは定期的に更新されます。テンプレートの UserData プロパティに必ず次のコマンドを含めてからヘルパースクリプトを呼び出し、起動したインスタンスで最新のヘルパースクリプトを取得できるようにしてください。 

yum install -y aws-cfn-bootstrap

最新のヘルパースクリプトの取得の詳細については、「CloudFormation ヘルパースクリプトリファレンス」を参照してください。

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

スタックの作成または更新にテンプレートを使用する前に、AWS CloudFormation を使用してテンプレートを検証できます。テンプレートを検証することで、AWS CloudFormation がリソースを作成する前に、依存関係の循環などの構文エラーや意味的エラーを捕捉するのに役立ちます。AWS CloudFormation コンソールを使用する場合は、入力パラメーターを指定するとコンソールが自動的にテンプレートを検証します。AWS CLI または AWS CloudFormation API の場合は、aws cloudformation validate-template コマンドまたはテンプレートの検証アクションを使用します。

検証中に、AWS CloudFormation はテンプレートが有効な JSON であるかどうかをまず確認します。そうでない場合は、AWS CloudFormation はテンプレートが有効な YAML であるかどうかを確認します。両方のチェックが失敗すると、AWS CloudFormation はテンプレートの検証エラーを返します。

組織のポリシーに準拠するためにテンプレートを検証する

組織のポリシーガイドラインに準拠しているかどうかテンプレートを検証することもできます。AWS CloudFormation Guard (cfn-guard) は、オープンソースのコマンドラインインターフェイス (CLI) ツールです。コードとしてのポリシー言語を提供し、必要なリソース設定と禁止されたリソース設定の両方をチェックできるルールを定義します。その後、これらのルールに対してテンプレートを検証できます。たとえば、管理者はルールを作成して、ユーザーが常に暗号化された Amazon S3 バケットを作成するようにできます。

ユーザーは、テンプレートの編集中にローカルで、または CI/CD パイプラインの一部として自動的に cfn-guard を使用して、非準拠リソースのデプロイメントを停止できます。

さらに、cfn-guard には、既存の準拠 CloudFormation テンプレートからルールを抽出できる機能 rulegen が含まれています。

詳細については、GitHub の cfn-guard リポジトリを参照してください。

AWS CloudFormation ですべてのスタックリソースを管理する

スタックを起動した後、AWS CloudFormation コンソール、API、または AWS CLI を使用して、スタック内のリソースを更新します。スタックのリソースを AWS CloudFormation 以外の方法で変更しないでください。変更するとスタックのテンプレートとスタックリソースの現在の状態の間で不一致が起こり、スタックの更新または削除でエラーが発生する場合があります。詳細については、「チュートリアル: スタックの更新」を参照してください。

スタックを更新する前に変更セットを作成する

変更セットによって、スタックの変更案が実行中のリソースに与える影響を、実装前に確認できます。AWS CloudFormation では変更セットが実行されるまでスタックは変更されないため、変更案のまま続行するか別の変更案を作成するかを決定できます。

変更セットを使用して、変更が実行中のリソース、特に重要なリソースに与える可能性のある影響を確認できます。たとえば、Amazon RDS データベースインスタンスの名前を変更すると、AWS CloudFormation によって新しいデータベースが作成され、古いものは削除されます。古いデータベースのデータをバックアップしていないと、データは失われます。変更設定を生成することで、変更によってデータベースが置き換えられることがわかります。このように、スタックを更新する前に計画を立てることができます。詳細については、「変更セットを使用したスタックの更新」を参照してください。

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

スタックポリシーは、重要なスタックリソースを保護して、意図しない更新でリソースが中断されたり置き換えられるのを防ぎます。スタックポリシーは、指定したリソースに対して実行できる更新アクションを記述する JSON ドキュメントです。重要なリソースがあるスタックを作成するときは常に、スタックポリシーを指定してください。

スタックの更新中に、保護されたリソースを明示的に指定して更新する必要があります。指定しない場合は保護されたリソースは変更されません。詳細については、「スタックのリソースが更新されないようにする」を参照してください。

コードの確認とリビジョン管理を使用してテンプレートを管理する

スタックのテンプレートには、プロパティ値などの AWS リソースの設定が記述されています。リソースの変更を確認し正確な履歴を保持するには、コードの確認とリビジョン管理を使用します。この方法は、テンプレートの異なるバージョン間の変更を追跡するのに役立ちます。また、スタックリソースの変更を追跡するのにも役立ちます。また、履歴を保守することで、いつでもスタックをテンプレートの特定のバージョンに戻すことができます。

Amazon EC2 Linux インスタンスを定期的に更新する

すべての Amazon EC2 Linux インスタンスおよび AWS CloudFormation を使用して作成された Amazon EC2 Linux インスタンスで、定期的に yum update コマンドを実行して RPM パッケージを更新します。こうすることで、最新の修正およびセキュリティの更新を確実に取得します。