AWS CloudFormation のベストプラクティス
ベストプラクティスはワークフロー全体で AWS CloudFormation をより効率的かつ安全に使用するために役立つ推奨事項です。スタックの計画方法と整理方法を学習し、リソースとそこで実行するソフトウェアアプリケーションを記述するテンプレートを作成して、スタックとそのリソースを管理します。次のベストプラクティスは、現在の CloudFormation のお客様の実際の経験に基づいています。
- 計画と編成
- テンプレートの作成
- スタックの管理
フィードバックループを短縮して配信速度を向上させる
CloudFormation テンプレートで記述したインフラストラクチャのフィードバックループを短縮するのに役立つ、プラクティスやツールを採用します。これには、ワークステーションで早期にテンプレートのリンティングとテストを行うことが含まれます。そうすることで、コントリビューションをソースコードリポジトリに送信する前でも、潜在的な構文や構成上の問題を発見する機会が得られます。このような問題を早期に発見することで、開発、品質保証、生産などの正式なライフサイクル環境に問題を持ち込まないようにすることができます。この早期テストによるフェイルファストのアプローチには、やり直しの待ち時間が減り、潜在的な影響範囲が減り、プロビジョニングオペレーションが成功する自信が高まるというメリットがあります。
フェイルファストの実践に役立つツールの選択肢には、AWS CloudFormation Linter
両方のツールを使用してフィードバックループを短縮する方法について、ステップバイステップで実践的なウォークスルーを行うには、「AWS CloudFormation ワークショップ
ライフサイクルと所有権によるスタックの整理
AWS リソースのライフサイクルと所有権を使用して、各スタックでどのリソースを使うを判断します。最初はすべてのリソースを 1 つのスタックに置いてもかまいませんが、スタックの規模が大きくなり範囲が拡大するにつれて、単一のスタックの管理は面倒で時間かかる場合があります。共通のライフサイクルと所有権を持つリソースのグループ化により、所有者は独自のプロセスやスケジュールを使用して、他のリソースに影響を与えることなくリソースのセットを変更できます。
たとえば、ロードバランサーの背後にある自動拡張インスタンスにホストされているウェブサイトを所有する開発者とエンジニアのチームがあったとしましょう。ウェブサイトは独自のライフサイクルを持ちウェブサイトチームによって保守されているため、このウェブサイトのスタックやそのリソースを作成できます。それでは、同様にバックエンドのデータベースを使用するウェブサイトがあり、そのデータベースは別のスタックでデータベース管理者が所有し保守しているとしましょう。ウェブサイトチームまたはデータベースチームがリソースを更新する必要があるときはいつでも、互いのスタックに影響を与えることなく実行できます。すべてのリソースが単一のスタックにある場合は、更新の連携や連絡は難しくなるでしょう。
スタックの整理についての詳細なガイダンスについては、2 つの一般的なフレームワークを使用できます。多層アーキテクチャーとサービス指向アーキテクチャー (SOA) です。
多層アーキテクチャーは、スタックを積み上げて構築する複数の水平の層に整理します。各層はその直下の層に依存します。各層には 1 つ以上のスタックを持つことができますが、各層のスタックは類似したライフサイクルと所有権を持つ AWS リソースを持つ必要があります。
サービス指向アーキテクチャーを使用すると、業務上の大きな問題を処理しやすい大きさに整理できます。これらのパートはそれぞれ、明確に定義された目的があり、機能の自己充足単位を表します。これらのサービスを、それぞれ独自のライフサイクルと所有者があるスタックにマッピングできます。これらのサービス (スタック) を 1 つに繋いで、相互に通信するようにできます。
クロススタック参照を使用して共有リソースをエクスポートします
ライフサイクルと所有権に基づいて AWS リソースを整理するときに、別のスタックにあるリソースを使用するスタックを構築することもできます。値をハードコード化または入力パラメータを使用して、リソース名と ID を渡すことができます。ただし、これらのメソッドはテンプレートの再利用を困難にしたり、スタック実行のオーバーヘッドを増やす場合があります。代わりに、スタックからリソースをエクスポートするクロススタック参照を使用すると、他のスタックがリソースを使用できます。スタックは Fn::ImportValue 関数を使用して、エクスポートされたリソースを呼び出して使用できます。
たとえば、VPC、セキュリティグループ、およびサブネットを含むネットワークスタックがあるかもしれません。すべてのパブリックウェブアプリケーションにこれらのリソースを使用する場合。リソースをエクスポートすることによって、パブリックウェブアプリケーションのすべてのスタックでリソースが使用できるようになります。詳細については、「チュートリアル: 別の AWS CloudFormation スタックのリソース出力を参照する」を参照してください。
すべてのリソースタイプのクォータを確認する
スタックを起動する前に、必要なすべてのリソースを AWS アカウントの制限に触れずに作成できることを確認します。制限に触れる場合は、クオータを増やすかまたは追加リソースを削除するまで、CloudFormation でスタックが正常に作成されません。各サービスには、スタックを起動する前に知っておくべきさまざまな制限があります。例えば、デフォルトでは、AWS アカウント でリージョンごとに 2,000 件の CloudFormation スタックのみを起動できます。制限およびデフォルトの制限を引き上げる方法の詳細については、「AWS 全般のリファレンス」の「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 文字で英数字のみ、といった制限を設定できます。詳細については、「パラメータ」を参照してください。
疑似パラメータを使用して移植性を高める
テンプレート内の疑似パラメータを、Ref や Fn::Sub などの組み込み関数の引数として使用できます。擬似パラメータは、CloudFormation によって事前定義されたパラメータです。テンプレートでは宣言しません。組み込み関数で擬似パラメータを使用すると、リージョンやアカウント間のスタックテンプレートの移植性が向上します。
例えば、特定のリソースプロパティについて、別の既存リソースの Amazon リソースネーム (ARN) を指定する必要があるテンプレートを作成したいとします。この場合、既存のリソースは ARN: arn:aws:ssm:us-east-1:111122223333:parameter/MySampleParameter を持つ AWS Systems Manager パラメータストアリソースです。ARN 形式をターゲットの AWS パーティション、リージョン、アカウント ID に合わせる必要があります。これらの値をハードコーディングする代わりに、AWS::Partition、AWS::Region、AWS::AccountId の疑似パラメータを使用してテンプレートの移植性を高めることができます。この場合に CloudFormation で ARN 内の要素を連結する方法の例としては、!Sub
'arn:${AWS::Partition}:ssm:${AWS::Region}:${AWS::AccountId}:parameter/MySampleParameter があります。
別の例として、別の CloudFormation スタックのリソース出力を参照するために チュートリアル: 別の AWS CloudFormation スタックのリソース出力を参照する を使用する場合を考えましょう。この例では、VPC のサブネットを作成し、その ID を同じアカウントとリージョンの他のスタックで使用できるようにエクスポートしたとします。別のスタックでは、Amazon EC2 インスタンスを記述するときに、サブネット ID のエクスポートされた値を参照します。
スタックのエクスポートはアカウントごと、リージョンごとに一意である必要があります。そのため、この場合は、AWS::StackName 擬似パラメータを使用してエクスポート用のプレフィックスを作成できます。スタック名もアカウントやリージョンごとに一意であることが必要なため、この疑似パラメータをプレフィックスとして使用すると、一意のエクスポート名を持つ可能性が高まるだけでなく、値をエクスポートするスタック全体の再利用可能なアプローチも促進されます。また、任意のプレフィックスを使用することも可能です。
Export 出力フィールドと Fn::ImportValue組み込み関数の詳細な使用例については、チュートリアル: 別の AWS CloudFormation スタックのリソース出力を参照する を参照してください。
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 API 操作を実行してください。
検証中に、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 コンソール
スタックを更新する前に変更セットを作成する
変更セットは、スタックの変更案が実行中のリソースに与える影響を、実装前に確認できるようにします。CloudFormation は、変更セットが実行するまでスタックを変更しないため、変更案のまま続行するか、別の変更案を作成するかを決定できます。
変更セットを使用して、変更が実行中のリソース、特に重要なリソースに与える可能性のある影響を確認できます。例えば、Amazon RDS データベースインスタンスの名前を変更すると、CloudFormation によって新しいデータベースが作成され、古いものは削除されます。古いデータベースのデータをバックアップしていないと、データは失われます。変更設定を生成することで、変更によってデータベースが置き換えられることがわかります。このように、スタックを更新する前に計画を立てることができます。詳細については、「変更セットを使用したスタックの更新」を参照してください。
スタックポリシーを使用する
スタックポリシーは、重要なスタックリソースを保護して、意図しない更新でリソースが中断されたり置き換えられるのを防ぎます。スタックポリシーは、指定したリソースに対して実行できる更新アクションを記述する JSON ドキュメントです。重要なリソースがあるスタックを作成するときは常に、スタックポリシーを指定してください。
スタックの更新中に、保護されたリソースを明示的に指定して更新する必要があります。指定しない場合は保護されたリソースは変更されません。詳細については、「スタックのリソースが更新されないようにする」を参照してください。
コードの確認とリビジョン管理を使用してテンプレートを管理する
スタックのテンプレートには、プロパティ値などの AWS リソースの構成が記述されています。リソースの変更を確認し正確な履歴を保持するには、コードの確認とリビジョン管理を使用します。この方法は、テンプレートの異なるバージョン間の変更を追跡するのに役立ちます。また、スタックリソースの変更を追跡するのにも役立ちます。また、履歴を保守することで、いつでもスタックをテンプレートの特定のバージョンに戻すことができます。
Amazon EC2 インスタンスを定期的に更新
CloudFormation で作成されたすべての Amazon EC2 Windows インスタンスと Amazon EC2 Linux インスタンスに対して、定期的に yum update コマンドを実行して RPM パッケージを更新します。こうすることで、最新の修正およびセキュリティの更新を確実に取得します。
