AWS CloudFormation ベストプラクティス - AWS CloudFormation

AWS CloudFormation ベストプラクティス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

モジュールを使用してリソース構成を再利用する

インフラストラクチャが大きくなるにつれ、各テンプレートで同じコンポーネントを宣言する共通パターンができてきます。モジュールは、スタックテンプレート全体に含めるリソース設定をパッケージ化する、透過的で管理しやすく、繰り返し可能な方法です。モジュールは、共通のサービス設定とベストプラクティスを、スタックテンプレートに含めるためのモジュール式のカスタマイズ可能なビルディングブロックとしてカプセル化できます。

これらのビルディングブロックは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを定義するためのベストプラクティスなど、単一のリソース用にすることも、アプリケーションアーキテクチャの一般的なパターンを定義するために、複数のリソース用にすることもできます。これらのビルディングブロックは他のモジュールにネストできるため、ベストプラクティスを上位レベルのビルディングブロックに積み重ねることができます。CloudFormation モジュールは CloudFormation レジストリで利用できるため、ネイティブリソースと同じように使用できます。CloudFormation モジュールを使用すれば、モジュールテンプレートが使用テンプレートに展開され、Ref または Fn::GetAtt を使用してモジュール内のリソースにアクセスできるようになります。詳細については、モジュールを参照してください。

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

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

パラメータの制約の使用

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

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

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

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

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

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

yum install -y aws-cfn-bootstrap

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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