CloudFormation ベストプラクティス

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

フィードバックループを短くしてデプロイ速度を向上させる

CloudFormation テンプレートで記述したインフラストラクチャのフィードバックループを短縮するのに役立つ、プラクティスやツールを採用します。これには、ワークステーションで早期にテンプレートのリンティングとテストを行うことが含まれます。そうすることで、コントリビューションをソースコードリポジトリに送信する前でも、潜在的な構文や構成上の問題を発見する機会が得られます。このような問題を早期に発見することで、開発、品質保証、生産などの正式なライフサイクル環境に問題を持ち込まないようにすることができます。この早期テストによるフェイルファストのアプローチには、やり直しの待ち時間が減り、潜在的な影響範囲が減り、プロビジョニングオペレーションが成功する自信が高まるというメリットがあります。

フェイルファストの実践に役立つツールの選択肢には、「AWS CloudFormation Linter」(cfn-lint) や「TaskCat」コマンドラインツールが含まれます。cfn-lint ツールは、CloudFormation テンプレートを「AWS CloudFormation リソース仕様」に対して検証する機能をもたらします。これには、リソースプロパティの有効な値の確認やベストプラクティスが含まれます。cfn-lint のプラグインは多くのコードエディターで利用できます。エディター内の問題を視覚化し、リンターのフィードバックを直接得ることができます。ソースコードリポジトリの設定に cfn-lint を統合することも選択できるため、コントリビューションをコミットするときにテンプレートの検証を実行できます。詳細については、「cfn-lint による AWS CloudFormation テンプレートの Git コミット前検証」を参照してください。最初のリンティングを実行し、cfn-lint で発生した可能性のある問題を修正したら、選択した AWS リージョン にプログラムでスタックを作成することにより、TaskCat を使用してテンプレートをテストできます。TaskCat は、選択した各リージョンに対して合格/不合格の評価を含むレポートも生成します。

両方のツールを使用してフィードバックループを短縮する方法について、ステップバイステップで実践的なウォークスルーを行うには、「AWS CloudFormation ワークショップ」の「リンティングとテストラボ」に従ってください。

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

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

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

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

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

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

クロススタック参照を使用して、別のスタックがエクスポートした出力の値を返します。

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

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

マルチアカウントデプロイとマルチリージョンデプロイに AWS CloudFormation StackSets を使用する

AWS CloudFormation StackSets は、複数のアカウントとリージョン全体でのスタックの作成、更新、削除を単一のオペレーションで実行できるようにすることで、スタックの機能を拡張します。StackSet は、組織全体での一般的なインフラストラクチャコンポーネント、コンプライアンス制御、共有サービスのデプロイに使用します。

StackSet を使用するときは、許可の管理を簡素化するために、AWS Organizations を使用してサービスマネージド型の許可を実装します。このアプローチは、各アカウントで IAM ロールを手動設定することを必要とせずに、組織内のアカウントに StackSet をデプロイできるようにします。

StackSet の詳細については、「StackSets の概念」を参照してください。

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

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

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

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

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

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

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

Infrastructure as Code 慣行を導入する

Infrastructure as Code (IaC) 慣行を実装することで、CloudFormation テンプレートをコードとして扱います。テンプレートをバージョン管理システムに保存し、コードレビューを実装して、自動化されたテストを使用して変更を検証します。このアプローチは、一貫性を確保し、コラボレーションを向上させ、インフラストラクチャ変更の監査証跡を提供します。

インフラストラクチャコードに CI/CD パイプラインを実装して、CloudFormation テンプレートのテストとデプロイを自動化することを検討してください。AWS CodePipeline、AWS CodeBuild、AWS CodeDeploy といったツールは、インフラストラクチャをデプロイするための自動化されたワークフローの作成に使用できます。

IaC ベストプラクティスの実装に関する詳細については、「Using AWS CloudFormation as an IaC tool」を参照してください。

CloudFormation での継続的デリバリーの使用に関する詳細については、「CodePipeline を使用した継続的デリバリー」を参照してください。

テンプレートに認証情報を埋め込まない

CloudFormation テンプレートに機密情報を埋め込むのではなく、スタックテンプレートで動的なリファレンスを使用することをお勧めします。

動的なリファレンスにより、AWS Systems Manager パラメータストアや AWS Secrets Manager などの他のサービスで保存、管理されている外部値をスタックテンプレートに指定するためのシンプルで強力な方法が提供されます。動的なリファレンスを使用すると、CloudFormation は、スタックオペレーションおよび変更セットオペレーション中に指定されたリファレンスの値を取得して、その値を適切なリソースに渡します。ただし、CloudFormation が実際の参照値を保存することはありません。詳細については、「動的な参照を使用してテンプレート値を指定する」を参照してください。

AWS Secrets Manager を使用して、データベースやその他のサービスの認証情報を安全に暗号化、保存、取得できます。AWS Systems Manager パラメータストア は、構成データ管理のための安全な階層型ストレージを提供します。

起動テンプレートのパラメータの詳細については、「CloudFormation テンプレートの Parameters 構文」を参照してください。

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

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

パラメータの制約の使用

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

疑似パラメータを使用して移植性を高める

テンプレート内の疑似パラメータを、Ref や Fn::Sub などの組み込み関数の引数として使用できます。擬似パラメータは、CloudFormation によって事前定義されたパラメータです。テンプレートでは宣言しません。組み込み関数で擬似パラメータを使用すると、リージョンおよびアカウント間でスタックテンプレートのポータビリティが向上します。

例えば、特定のリソースプロパティについて、別の既存リソースの Amazon リソースネーム (ARN) を指定する必要があるテンプレートを作成したいとします。この場合、既存のリソースは ARN: arn:aws:ssm:us-east-1:123456789012: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 があります。

別の例として、リソースや設定を複数のスタック間で共有したいとします。この例では、VPC のサブネットを作成し、その ID を同じ AWS アカウント とリージョンで他のスタックと使用するためにエクスポートしたことを想定します。別のスタックでは、Amazon EC2 インスタンスを記述するときに、サブネット ID のエクスポートされた値を参照します。Export 出力フィールドと Fn::ImportValue組み込み関数の詳細な使用例については、別の CloudFormation スタックのリソース出力を参照する を参照してください。

スタックのエクスポートは、アカウントおよびリージョンごとに一意である必要があります。そのため、この場合は、AWS::StackName 擬似パラメータを使用してエクスポート用のプレフィックスを作成できます。スタック名もアカウントおよびリージョンごとに一意であることが必要なため、この疑似パラメータをプレフィックスとして使用すると、一意のエクスポート名を持つ可能性が高くなるだけではなく、値をエクスポートするスタック全体の再利用可能なアプローチも促進されます。また、任意のプレフィックスを使用することも可能です。

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

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

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

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

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

yum install -y aws-cfn-bootstrap

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

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

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

テンプレートオーサリングに YAML または JSON を使用する

CloudFormation は、テンプレート用に YAML 形式と JSON 形式の両方をサポートしています。それぞれの形式に利点があり、どちらを選択するかは特定のニーズに応じて異なります。

次の場合は YAML を使用します。

次の場合は JSON を使用します。

YAML には可読性があり、コメントをサポートすることから、手動でのテンプレートオーサリングに推奨されるのが一般的です。YAML は、インデントベースの構造がリソース階層の視覚化に役立つ、複雑なテンプレートに対して特に有用です。JSON は、自動化されたワークフローや、JSON 入力を期待する API を使用する場合に有利になり得ます。また、特定の構造を厳守する必要がある場合にも役に立ちます。どちらの形式を選択するかにかかわらず、適切に構造化され、文書化されて、保守が可能なテンプレートの作成に焦点を当ててください。YAML を使用する場合は、アンカーやエイリアスといった機能を活用して反復作業を減らし、保守性を向上させます。

包括的なタグ付け戦略を実装する

CloudFormation テンプレートによって作成されるすべてのリソースに対する一貫的なタグ付け戦略を実装します。タグは、リソースの編成、コスト配分、アクセスコントロール、自動化に役立ちます。環境、所有者、コストセンター、アプリケーション、目的に関するタグを含めることを検討してください。

AWS::CloudFormation::Stack リソースの Tags プロパティを使用して、スタック内でサポートされているすべてのリソースにタグを適用します。多数のリソースタイプで使用できる TagSpecifications プロパティを使用して、リソースの作成時にタグを適用することも可能です。

タグ付けの詳細については、「リソースタグ」を参照してください。

高度な変換にテンプレートマクロを活用する

CloudFormation マクロを使用すると、検索/置換オペレーションといったシンプルなアクションから、追加のリソースを生成する複雑な変換まで、さまざまなカスタム処理をテンプレートで実行できます。マクロを使用して CloudFormation テンプレートの機能を拡張し、組織全体に再利用可能なパターンを実装します。

AWS Serverless Application Model は、サーバーレスアプリケーションの開発を簡素化するマクロの例です。組織固有のパターンと要件に合わせたカスタムマクロの作成を検討してください。

テンプレートでのマクロの使用に関する詳細については、「CloudFormation マクロの概要」を参照してください。

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

スタックを起動した後、CloudFormation コンソール、API、AWS CLI を使用して、スタック内のリソースを更新します。スタックのリソースを CloudFormation 以外の方法で変更しないでください。変更するとスタックのテンプレートとスタックリソースの現在の状態の間で不一致が起こり、スタックの更新または削除でエラーが発生する場合があります。これをドリフトと呼びます。CloudFormation テンプレート外でリソースが変更され、その後にスタックを更新すると、リソースに直接行われた変更は破棄され、リソース設定はテンプレートの設定に戻ります。

ドリフトの詳細については、「ドリフトとは」を参照してください。

スタックの更新に関する詳細は、「スタックの更新」を参照してください。

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

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

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

スタックポリシーを使用してリソースを保護する

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

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

AWS CloudTrail を使用して CloudFormation 呼び出しをログに記録する

AWS CloudTrail は、AWS アカウントで CloudFormation API コールを実行するすべてのユーザーを追跡します。API 呼び出しは、CloudFormation API、CloudFormation コンソール、バックエンドコンソール、または CloudFormation AWS AWS CLI コマンドの使用時にログに記録されます。ログ記録を有効にして Amazon S3 バケットを指定し、ログを保存します。こうすることで、必要ならばアカウントで誰がどのような CloudFormation 呼び出しを行ったかを監査できます。

詳細については、「AWS CloudFormation による AWS CloudTrail API コールのログ記録」を参照してください。

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

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

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

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

ドリフト検出を定期的に使用する

CloudFormation のドリフト検出機能を定期的に使用して、CloudFormation の管理外で変更されたリソースを特定します。ドリフトの検出と解決は、Infrastructure as Code アプローチの整合性を維持するために役立ち、デプロイされたリソースの状態をテンプレートが正確に反映することを確実にします。

自動ドリフト検出を運用手順の一環として実装することを検討してください。Amazon EventBridge ルールによってトリガーされる AWS Lambda 関数を使用してドリフトを定期的にチェックし、不一致が検出されたときにチームに通知できます。

詳細については、「ドリフト検出を使用してスタックとリソースへのアンマネージド型設定変更を検出する」を参照してください。

自動復旧のためのロールバックトリガーを設定する

ロールバックトリガーを使用して、スタックの作成や更新オペレーション中に CloudFormation が監視する必要のある Amazon CloudWatch アラームを指定します。指定されたアラームのいずれかが ALARM 状態になると、CloudFormation がスタックオペレーション全体を自動的にロールバックして、インフラストラクチャが安定した状態を維持できるようにします。

アプリケーションのエラー率、システムリソースの使用率、またはアプリケーションやインフラストラクチャの正常性を示すカスタムビジネスメトリクスなどの重要なメトリクスに対するロールバックトリガーを設定します。

ロールバックトリガーの詳細については、「アラーム違反時にスタックをロールバックする」を参照してください。

効果的なスタックリファクタリング戦略を実装する

インフラストラクチャが進化するにつれて、メンテナンス性を向上させ、複雑性を軽減して、変化する要件に適応するために CloudFormation スタックをリファクタリングする必要が生じる場合があります。スタックリファクタリングには、外部動作と機能を維持しながらテンプレートとリソースを再構成することが含まれます。スタックリファクタリングは、以下のように CloudFormation と使用すると効果的です。

CloudFormation スタックのリファクタリングに関する詳細については、「スタックリファクタリング」を参照してください。

ライフサイクル管理に CloudFormation Hooks を使用する

CloudFormation Hooks は、プロビジョニングする前に AWS リソースの設定をプロアクティブに検査するコードを提供し、複雑な検証チェックを実行します。Hooks は、リソース、スタック、変更セットが組織のセキュリティ、運用、コスト最適化のニーズに準拠しているかどうかをチェックします。設定方法に応じて、Hooks はリソースのプロビジョニング前、またはオペレーションを失敗させて全体を停止する前に警告を発します。違反と警告は、非準拠のデプロイに対する可視性を提供するために Amazon CloudWatch のログに記録されます。

Hooks に関するこれらのベストプラクティスの詳細については、「AWS CloudFormation Hooks concepts」を参照してください。

CloudFormation リソースに対する Hooks の活用方法の詳細については、「What are AWS CloudFormation Hooks?」を参照してください。

IaC ジェネレーターを使用して既存のリソースからテンプレートを作成する

CloudFormation IaC (Infrastructure as Code) ジェネレーターは、既存の AWS リソースからの CloudFormation テンプレートの作成に役立ちます。この機能は、既存のインフラストラクチャをレプリケートする、手動で作成されたリソースを文書化する、またはこれまで管理されていなかったリソースを CloudFormation で管理する必要がある場合に特に便利です。IaC ジェネレーターは、以下のような CloudFormation テンプレートの作成に役立ちます

IaC ジェネレーターの詳細については、「IaC ジェネレーターを使用して既存のリソースからテンプレートを生成する」を参照してください。

ビジュアルテンプレートの設計に AWS Infrastructure Composer を使用する

AWS Infrastructure Composer は、ドラッグアンドドロップ形式のインターフェイスを使用して CloudFormation テンプレートを作成、視覚化、変更できるようにするビジュアル設計ツールです。これは、CloudFormation を次のように使用する場合に特に有益です。

Infrastructure Composer の詳細については、「What is AWS Infrastructure Composer?」を参照してください。

複雑なインフラストラクチャに AWS Cloud Development Kit (AWS CDK) を使用することを検討する

複雑なインフラストラクチャ要件については、TypeScript、Python、Java、.NET などの使い慣れたプログラミング言語を使用してクラウドリソースを定義するために CDK を使用してすることを検討してください。AWS CDK はコードから CloudFormation テンプレートを生成するため、希望する言語の抽象化とプログラミングコンストラクトを使用しながら CloudFormation のすべての機能を活用できます。

AWS CDK は、ベストプラクティスをカプセル化し、一般的なインフラストラクチャパターンの定義を簡素化する高レベルのコンストラクトを提供します。そのため、ベストプラクティスへの準拠を確実にしながら、インフラストラクチャの定義に必要なコードの量を大幅に削減することができます。

CDK の詳細については、「AWS Cloud Development Kit (AWS CDK)」を参照してください。

IAM を使用したアクセス制御

IAM は AWS のユーザーとそのアクセス許可を管理できる AWS サービスです。IAM と CloudFormation を使用して、スタックテンプレートの表示、スタックの作成、スタックの削除など、ユーザーが実行できる CloudFormation アクションを指定できます。さらに、CloudFormation スタックを管理するには、そのスタックのリソースに対するアクセス許可が必要です。例えば、ユーザーが CloudFormation を使用して Amazon EC2 インスタンスを、起動、更新、終了する場合、そのユーザーは関連する Amazon EC2 アクションを呼び出すアクセス許可を持っている必要があります。

ほとんどの場合、ユーザーはテンプレート内のすべてのリソースを管理するためにフルアクセスを必要とします。CloudFormation は、ユーザーに代わってこれらのリソースを作成、変更、削除するための呼び出しを行います。ユーザーと CloudFormation サービスの間でアクセス許可を分割するには、サービスロールを使用します。CloudFormation は、ユーザーのポリシーの代わりにサービスロールのポリシーを使用して呼び出しを行います。詳細については、「AWS CloudFormation サービスロール」を参照してください。

最小特権の原則を適用する

CloudFormation のサービスロールや、テンプレートから作成されたリソースの IAM ロールを設定するときは、常に最小特権の原則を適用します。意図される機能に必要な許可のみを付与し、ワイルドカード許可の使用はできる限り避けるようにしてください。

IAM Access Analyzer を使用して、CloudFormation のサービスロールに付与された許可を確認し、削除できる未使用の許可を特定します。IAM ポリシーは定期的に見直して更新し、セキュリティ要件に適合していることを確認してください。

機密性の高いパラメータをセキュア化する

パスワード、API キー、その他のシークレットなどの機密情報については、テンプレートに直接埋め込む代わりに AWS Secrets Manager Parameter Store または AWS Systems Manager を使用します。スタックオペレーション中にこれらの値をセキュアに取得するには、テンプレートで動的参照を使用します。

テンプレートでパラメータを使用するときは、機密性の高いパラメータの NoEcho プロパティを true に設定して、パラメータの値がコンソール、API 応答、または CLI 出力に表示されないようにします。値をログに記録する可能性のあるその他サービスやリソースにこうした値が渡される場合は、NoEcho を使っても値がログに記録されてしまうことに注意してください。

CloudFormation での AWS Systems Manager Parameter Store の使用に関する詳細については、「AWS Systems Manager Parameter Store からプレーンテキスト値を取得する」を参照してください。

NoEcho プロパティの使用に関する詳細については、「CloudFormation テンプレートの Parameters 構文」を参照してください。

CloudFormation での AWS Secrets Manager の使用に関する詳細については、「Create AWS Secrets Manager secrets in AWS CloudFormation」を参照してください。

AWS CloudFormation Guard を使用してポリシーをコードとして実装する

AWS CloudFormation Guard (cfn-guard) は、CloudFormation テンプレートのルールを定義して適用できるようにするオープンソースの Policy-as-Code ツールです。cfn-guard を使用して、テンプレートが組織のポリシー、セキュリティベストプラクティス、ガバナンス要件に準拠することを確認します。

CI/CD パイプラインに cfn-guard を統合して、テンプレートをポリシールールに照らして自動検証してからデプロイします。これは、非準拠のリソースが環境にデプロイされるのを防ぎ、ポリシー違反に関する早期フィードバックを開発者に提供します。

Guard の詳細については、「What is AWS CloudFormation Guard?」を参照してください。