これは AWS CDK v2 開発者ガイドです。古い CDK v1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

を使用したクラウドインフラストラクチャの開発とデプロイのベストプラクティス AWS CDK

を使用すると AWS CDK、デベロッパーまたは管理者は、サポートされているプログラミング言語を使用してクラウドインフラストラクチャを定義できます。CDK アプリケーションは、API、データベース、モニタリングリソースなどの論理ユニットに整理し、オプションで自動デプロイ用のパイプラインを用意する必要があります。論理ユニットは、以下を含むコンストラクトとして実装する必要があります。

スタックは、これらの論理ユニットのデプロイモデルを定義します。CDK の概念の詳細な概要については、「」を参照してくださいの開始方法 AWS CDK。

AWS CDK は、顧客や社内チームのニーズ、および複雑なクラウドアプリケーションのデプロイや継続的なメンテナンス中に発生することが多い障害パターンを慎重に考慮したものです。多くの場合、障害は、設定の変更など、完全にテストされていないアプリケーションへのout-of-band「」変更に関連していることがわかりました。したがって、ビジネスロジックだけでなく、インフラストラクチャと設定でもアプリケーション全体がコードで定義されているモデル AWS CDK を中心に開発しました。そうすれば、提案された変更を慎重に見直し、本番環境に似た環境で包括的にさまざまな度合いでテストし、問題が発生した場合は完全にロールバックできます。

デプロイ時に、 は以下を含むクラウドアセンブリを AWS CDK 合成します。

CDK を使用すると、アプリケーションのメインバージョン管理ブランチのすべてのコミットは、アプリケーションの完全で一貫性のあるデプロイ可能なバージョンを表すことができます。その後、アプリケーションは変更が行われるたびに自動的にデプロイできます。

の背後にある哲学は、推奨されるベストプラクティス AWS CDK につながります。ベストプラクティスは 4 つのカテゴリに分かれています。

組織のベストプラクティス

AWS CDK 導入の初期段階では、組織を成功させるためのセットアップ方法を検討することが重要です。CDK を採用する際に、エキスパートのチームがトレーニングを行い、残りの会社を指示することがベストプラクティスです。このチームのサイズは、小規模な会社の 1 人または 2 人から、大規模な企業でフルエッジの Cloud Center of Excellence (CCoE) までさまざまです。このチームは、社内のクラウドインフラストラクチャの標準とポリシーを設定するだけでなく、デベロッパーのトレーニングと参加も担当します。

CCoE は、クラウドインフラストラクチャに使用するプログラミング言語に関するガイダンスを提供する場合があります。詳細は組織によって異なりますが、適切なポリシーを採用することで、デベロッパーは会社のクラウドインフラストラクチャを理解して維持できます。

CCoE は、 内の組織単位を定義する「ランディングゾーン」も作成します AWS。ランディングゾーンは、ベストプラクティスの設計図に基づいて、事前設定され、安全でスケーラブルなマルチアカウント AWS 環境です。ランディングゾーンを構成するサービスを結び付けるには、 を使用できます。これはAWS Control Tower、単一のユーザーインターフェイスからマルチアカウントシステム全体を設定および管理します。

開発チームは、必要に応じて独自のアカウントを使用してテストを行い、これらのアカウントに新しいリソースをデプロイできる必要があります。個々のデベロッパーは、これらのリソースを独自の開発ワークステーションの拡張機能として扱うことができます。CDK Pipelines を使用すると、 AWS CDK アプリケーションを CI/CD アカウントを介してテスト、統合、実稼働環境 (それぞれ独自の AWS リージョンまたはアカウントに分離) にデプロイできます。これは、デベロッパーのコードを組織の正規リポジトリにマージすることによって行われます。

コーディングのベストプラクティス

このセクションでは、 AWS CDK コードを整理するためのベストプラクティスを紹介します。次の図は、チームとそのチームのコードリポジトリ、パッケージ、アプリケーション、コンストラクトライブラリの関係を示しています。

最初はシンプルに開始し、必要な場合にのみ複雑さを追加します。

ベストプラクティスのほとんどは、できるだけシンプルに保つことですが、よりシンプルではありません。要件がより複雑なソリューションを必要とする場合にのみ、複雑さを追加します。では AWS CDK、新しい要件をサポートするために、必要に応じてコードをリファクタリングできます。考えられるすべてのシナリオを事前に設計する必要はありません。

AWS Well-Architected フレームワークへの準拠

AWS Well-Architected フレームワークは、コンポーネントを、要件に対してまとめて提供するコード、設定、および AWS リソースとして定義します。コンポーネントは、多くの場合、技術所有権の単位であり、他のコンポーネントから切り離されます。ワークロードという用語は、一緒にビジネス価値をもたらす一連のコンポーネントを識別するために使用されます。ワークロードは通常、ビジネスリーダーとテクノロジーリーダーがコミュニケーションする詳細のレベルです。

Well-Architected Framework. AWS CDK apps AWS で定義されているように、 AWS CDK アプリケーションはコンポーネントにマッピングされます。 Well-Architected クラウドアプリケーションのベストプラクティスを調整および提供するためのメカニズムです。また、 などのアーティファクトリポジトリを使用して、コンポーネントを再利用可能なコードライブラリとして作成して共有することもできます AWS CodeArtifact。

すべてのアプリケーションは、1 つのリポジトリ内の 1 つのパッケージから開始します。

1 つのパッケージは AWS CDK アプリケーションのエントリポイントです。ここでは、アプリケーションのさまざまな論理ユニットをデプロイする方法と場所を定義します。また、CI/CD パイプラインを定義してアプリケーションをデプロイします。アプリケーションのコンストラクトは、ソリューションの論理単位を定義します。

複数のアプリケーションで使用するコンストラクトには、追加のパッケージを使用します。（共有コンストラクトには独自のライフサイクルとテスト戦略も必要です）。同じリポジトリ内のパッケージ間の依存関係は、リポジトリのビルドツールによって管理されます。

これは可能ですが、特に自動デプロイパイプラインを使用する場合は、複数のアプリケーションを同じリポジトリに配置することはお勧めしません。これにより、デプロイ中の変更の「ブラスト半径」が増加します。リポジトリに複数のアプリケーションがある場合、1 つのアプリケーションを変更すると、他のアプリケーションのデプロイがトリガーされます (他のアプリケーションが変更されていない場合でも）。さらに、1 つのアプリケーションに障害が発生すると、他のアプリケーションがデプロイされなくなります。

コードライフサイクルまたはチームの所有権に基づいてコードをリポジトリに移動する

パッケージが複数のアプリケーションで使用され始めたら、パッケージを独自のリポジトリに移動します。これにより、パッケージを使用するアプリケーション構築システムでパッケージを参照できます。また、アプリケーションライフサイクルとは無関係に定期的に更新することもできます。ただし、最初は、すべての共有コンストラクトを 1 つのリポジトリに配置するのが理にかなっている場合があります。

また、さまざまなチームが作業している場合は、パッケージを独自のリポジトリに移動します。これにより、アクセスコントロールを実施できます。

リポジトリの境界を越えてパッケージを使用するには、プライベートパッケージリポジトリが必要です。これは NPM、、 PyPiまたは Maven Central に似ていますが、組織内部にあります。また、パッケージをビルド、テスト、プライベートパッケージリポジトリに公開するリリースプロセスも必要です。CodeArtifact は、最も一般的なプログラミング言語のパッケージをホストできます。

パッケージリポジトリ内のパッケージへの依存関係は、 TypeScript や JavaScript アプリケーションの NPM など、言語のパッケージマネージャーによって管理されます。パッケージマネージャーは、ビルドが繰り返し可能であることを確認するのに役立ちます。これは、アプリケーションが依存するすべてのパッケージの特定のバージョンを記録することによって行われます。また、これらの依存関係を制御された方法でアップグレードすることもできます。

共有パッケージには別のテスト戦略が必要です。1 つのアプリケーションでは、テスト環境にアプリケーションをデプロイし、それでも動作することを確認するのに十分かもしれません。ただし、共有パッケージは、一般公開されているかのように、消費するアプリケーションとは独立してテストする必要があります。（組織によっては、実際に一部の共有パッケージを一般公開することを選択する場合があります）。

コンストラクトは任意に単純でも複雑でもかまいません。Bucket はコンストラクトですが、 CameraShopWebsiteはコンストラクトでもあります。

同じパッケージ内のインフラストラクチャとランタイムコードのライブ

は、インフラストラクチャをデプロイするための AWS CloudFormation テンプレートを生成するだけでなく、Lambda 関数や Docker イメージなどのランタイムアセット AWS CDK もバンドルし、インフラストラクチャと一緒にデプロイします。これにより、インフラストラクチャを定義するコードと、ランタイムロジックを実装するコードを 1 つのコンストラクトにまとめることができます。これはベストプラクティスです。これら 2 種類のコードは、別々のリポジトリに置く必要も、別々のパッケージに置く必要もありません。

2 種類のコードを進化させるには、インフラストラクチャやロジックなど、機能を完全に記述した自己完結型のコンストラクトを使用できます。自己完結型のコンストラクトを使用すると、2 種類のコードを個別にテストし、プロジェクト間でコードを共有して再利用し、すべてのコードを同期してバージョン管理できます。

構築のベストプラクティス

このセクションでは、コンストラクトを開発するためのベストプラクティスについて説明します。コンストラクトは、リソースをカプセル化する再利用可能な組み合わせ可能なモジュールです。これらは AWS CDK アプリケーションの構成要素です。

コンストラクト付きのモデル、スタック付きのデプロイ

スタックはデプロイの単位であり、スタック内のすべてが一緒にデプロイされます。したがって、複数の AWS リソースからアプリケーションの上位レベルの論理ユニットを構築する場合は、各論理ユニットを としてではなくConstruct、 として表しますStack。スタックは、さまざまなデプロイシナリオでコンストラクトをどのように構成し、接続するかを説明する場合にのみ使用します。

例えば、論理単位の 1 つがウェブサイトである場合、それを構成するコンストラクト (Amazon S3 バケット、API Gateway、Lambda 関数、Amazon RDS テーブルなど) は 1 つの高レベルのコンストラクトに構成する必要があります。次に、そのコンストラクトをデプロイ用の 1 つ以上のスタックでインスタンス化する必要があります。

構築用の コンストラクトとデプロイ用の スタックを使用することで、インフラストラクチャの再利用の可能性を高め、デプロイ方法をより柔軟にすることができます。

環境変数ではなく、プロパティとメソッドを使用して を設定する

コンストラクトとスタック内の環境変数ルックアップは、一般的なアンチパターンです。コンストラクトとスタックの両方がプロパティオブジェクトを受け入れて、完全な設定をコード内で完全に行えるようにする必要があります。そうしないと、コードが実行されるマシンへの依存関係が導入され、追跡と管理が必要な設定情報がさらに多く作成されます。

一般に、環境変数の検索は AWS CDK アプリの最上位レベルに制限する必要があります。また、開発環境で実行するために必要な情報を渡すためにも使用する必要があります。詳細については、「環境」を参照してください。

インフラストラクチャのユニットテスト

すべての環境で構築時にユニットテストの完全なスイートを常に実行するには、合成中のネットワークルックアップを避け、コード内のすべての本番ステージをモデル化します。（これらのベストプラクティスについては、後で説明します）。1 つのコミットで常に同じ生成されたテンプレートが生成された場合は、作成したユニットテストを信頼して、生成されたテンプレートが期待どおりに表示されることを確認できます。詳細については、「コンストラクトのテスト」を参照してください。

ステートフルリソースの論理 ID を変更しない

リソースの論理 ID を変更すると、リソースは次のデプロイ時に新しいものに置き換えられます。データベースや S3 バケットなどのステートフルリソース、または Amazon VPC などの永続的なインフラストラクチャの場合、これはほとんど必要ありません。ID が変更される原因となる AWS CDK コードのリファクタリングには注意してください。ステートフルリソースの論理 IDs が静的のままであることをアサートする書き込みユニットテスト。論理 ID は、コンストラクトをインスタンス化するときにid指定した と、コンストラクトツリー内のコンストラクトの位置から導出されます。詳細については、「論理 IDs」を参照してください。

コンストラクトがコンプライアンスに十分ではない

多くのエンタープライズのお客様は、L2 コンストラクト (組み込みのデフォルトとベストプラクティスで個々の AWS リソースを表す「キュレートされた」コンストラクト) の独自のラッパーを記述しています。これらのラッパーは、静的暗号化や特定の IAM ポリシーなどのセキュリティのベストプラクティスを適用します。例えば、通常の Amazon S3 Bucketコンストラクトの代わりにアプリケーションMyCompanyBucketで使用する を作成できます。 Amazon S3 このパターンは、ソフトウェア開発ライフサイクルの早い段階でセキュリティガイダンスを表示するのに便利ですが、唯一の強制手段としてそれに依存しないでください。

代わりに、サービスコントロールポリシーやアクセス許可の境界などの AWS 機能を使用して、組織レベルでセキュリティガードレールを適用します。側面 または CloudFormation Guard などのツールを使用して、デプロイ前にインフラストラクチャ要素のセキュリティプロパティに関するアサーションを行います。最適な動作 AWS CDK のために を使用します。

最後に、独自の「L2+」コンストラクトを作成すると、デベロッパーが Construct Hub のAWS ソリューションコンストラクトやサードパーティーコンストラクトなどの AWS CDK パッケージを利用できなくなる可能性があることに注意してください。これらのパッケージは通常、標準 AWS CDK コンストラクトに基づいて構築され、ラッパーコンストラクトを使用することはできません。

アプリケーションのベストプラクティス

このセクションでは、 コンストラクトを組み合わせてリソースの接続方法 AWS を定義し、 AWS CDK アプリケーションを作成する方法について説明します。

合成時に決定を行う

AWS CloudFormation ではデプロイ時に決定を行うことができますが (Conditions、{ Fn::If }、および を使用Parameters）、 AWS CDK ではこれらのメカニズムにいくつかアクセスできますが、使用しないことをお勧めします。使用できる値のタイプと、それらに対して実行できるオペレーションのタイプは、汎用プログラミング言語で利用できるものと比較して制限されます。

代わりに、プログラミング言語のifステートメントやその他の機能を使用して、 AWS CDK アプリケーションでインスタンス化するコンストラクトなど、すべての決定を試みます。例えば、リストを反復処理し、リスト内の各項目の値を含むコンストラクトをインスタンス化する一般的な CDK イディオムは、 AWS CloudFormation 式を使用するだけでは不可能です。

言語ターゲット AWS CloudFormation としてではなく、 が堅牢なクラウドデプロイ AWS CDK に使用する実装の詳細として扱います。 TypeScript または Python で AWS CloudFormation テンプレートを記述するのではなく、デプロイ CloudFormation に が使用する CDK コードを記述します。

物理名ではなく、生成されたリソース名を使用する

名前は欠陥リソースです。各名前は 1 回だけ使用できます。したがって、テーブル名またはバケット名をインフラストラクチャとアプリケーションにハードコーディングする場合、そのインフラストラクチャを同じアカウントに 2 回デプロイすることはできません。（ここで説明する名前は、Amazon S3 バケットコンストラクトの bucketNameプロパティなどで指定された名前です。）

何が悪いことなのか、リソースを置き換える必要があるリソースを変更することはできません。Amazon DynamoDB テーブルKeySchemaの など、リソースの作成時にのみプロパティを設定できる場合、そのプロパティは変更できません。このプロパティを変更するには、新しいリソースが必要です。ただし、新しいリソースを実際に置き換えるには、同じ名前にする必要があります。ただし、既存のリソースがその名前を使用している間は、同じ名前にすることはできません。

名前をできるだけ少なく指定することをお勧めします。リソース名を省略すると、 AWS CDK は問題を引き起こさない方法でリソース名を生成します。リソースとしてテーブルがあるとします。その後、生成されたテーブル名を環境変数として AWS Lambda 関数に渡すことができます。 AWS CDK アプリケーションで、テーブル名を として参照できますtable.tableName。または、起動時に Amazon EC2 インスタンスで設定ファイルを生成するか、実際のテーブル名を AWS Systems Manager Parameter Store に書き込んで、アプリケーションがそこから読み取ることができるようにすることもできます。

必要な場所が別の AWS CDK スタックの場合は、さらに簡単です。1 つのスタックがリソースを定義し、別のスタックがそのリソースを使用する必要があると仮定すると、以下が適用されます。

削除ポリシーとログの保持を定義する

は、作成したすべてを保持するポリシーをデフォルトで保持することで、データが失われないように AWS CDK 試みます。例えば、データを含むリソース (Amazon S3 バケットやデータベーステーブルなど) のデフォルトの削除ポリシーでは、リソースがスタックから削除されたときにリソースを削除しません。代わりに、リソースはスタックから孤立します。同様に、CDK のデフォルトはすべてのログを永久に保持することです。実稼働環境では、これらのデフォルトにより、実際に必要のない大量のデータと対応する AWS 請求書がすぐに保存される可能性があります。

これらのポリシーを本番稼働用リソースごとに何にするかを慎重に検討し、それに応じて指定します。側面 を使用して、スタックの削除ポリシーとログ記録ポリシーを検証します。

デプロイ要件に従ってアプリケーションを複数のスタックに分離する

アプリケーションが必要とするスタックの数には、ハードかつ高速なルールはありません。通常、デプロイパターンに基づいて決定します。次のガイドラインに注意してください。

非決定的な動作を避けるためcdk.context.jsonにコミットする

AWS CDK デプロイを成功させるには、決定性が重要です。 AWS CDK アプリケーションは、特定の環境にデプロイされるたびに、基本的に同じ結果になります。

AWS CDK アプリケーションは汎用プログラミング言語で記述されるため、任意のコードを実行し、任意のライブラリを使用して、任意のネットワーク呼び出しを行うことができます。例えば、 AWS SDK を使用して、アプリケーションの合成中に AWS アカウントから情報を取得できます。そうすると、認証情報のセットアップ要件が増大し、レイテンシーが増加し、 を実行するたびに障害が発生する可能性は低くなりますcdk synth。

合成中に AWS アカウントやリソースを変更しないでください。アプリを合成しても、副作用はありません。インフラストラクチャへの変更は、 AWS CloudFormation テンプレートの生成後のデプロイフェーズでのみ行う必要があります。これにより、問題が発生した場合、変更を自動的にロールバック AWS CloudFormation できます。 AWS CDK フレームワーク内で簡単に実行できない変更を行うには、カスタムリソースを使用してデプロイ時に任意のコードを実行します。

厳密に読み取り専用呼び出しでも、必ずしも安全ではありません。ネットワーク呼び出しによって返される値が変更された場合の動作を考慮します。これはインフラストラクチャのどの部分に影響しますか？ 既にデプロイされているリソースはどうなりますか？ 以下は、値の急激な変化が問題を引き起こす可能性がある 2 つの状況の例です。

これらの状況は、 AWS側の変更が数か月または数年間正常にデプロイされた後に発生する可能性があるため、無悪になる可能性があります。突然、デプロイが「理由なし」に失敗し、何を行ったか、なぜ忘れたのか。

さいわい、 には、非決定的な値のスナップショットを記録するコンテキストプロバイダーと呼ばれるメカニズム AWS CDK が含まれています。これにより、将来の合成オペレーションで、最初にデプロイしたときとまったく同じテンプレートを生成できます。新しいテンプレートでの変更は、コードで行った変更だけです。コンストラクトの .fromLookup()メソッドを使用すると、呼び出しの結果は にキャッシュされますcdk.context.json。CDK アプリの将来の実行で同じ値が使用されるように、コードを他の部分とともにバージョン管理にコミットする必要があります。CDK Toolkit にはコンテキストキャッシュを管理するコマンドが含まれているため、必要に応じて特定のエントリを更新できます。詳細については、「ランタイムのコンテキスト」を参照してください。

ネイティブ CDK コンテキストプロバイダーがない値 ( AWS または他の場所から) が必要な場合は、別のスクリプトを作成することをお勧めします。スクリプトは値を取得してファイルに書き込み、CDK アプリでそのファイルを読み取る必要があります。スクリプトは、通常のビルドプロセスの一部としてではなく、保存された値を更新する場合にのみ実行します。

にロールとセキュリティグループの AWS CDK 管理を許可する

AWS CDK コンストラクトライブラリのgrant()便利な方法では、最小限のスコープのアクセス許可を使用して、あるリソースへのアクセスを別のリソースに付与する AWS Identity and Access Management ロールを作成できます。例えば、次のような行があるとします。

myBucket.grantRead(myLambda)

この 1 行は、Lambda 関数のロール (ユーザー用にも作成されます) にポリシーを追加します。そのロールとそのポリシーは、 CloudFormation ユーザーが記述する必要のない の 12 行以上です。は、関数がバケットから読み取るために必要な最小限のアクセス許可のみ AWS CDK を付与します。

開発者がセキュリティチームによって作成された事前定義されたロールを常に使用する必要がある場合、 AWS CDK コーディングははるかに複雑になります。チームは、アプリケーションを設計する方法に多くの柔軟性を失う可能性があります。代わりに、サービスコントロールポリシーとアクセス許可の境界を使用して、デベロッパーがガードレール内にとどまるようにすることをお勧めします。

コード内のすべての本番稼働ステージをモデル化する

従来の AWS CloudFormation シナリオでは、特定の環境に固有の設定値を適用した後にさまざまなターゲット環境にデプロイできるように、パラメータ化された単一のアーティファクトを生成することが目的です。CDK では、その設定をソースコードに組み込むことができます。本番環境用のスタックを作成し、他のステージごとに個別のスタックを作成します。次に、各スタックの設定値をコードに入れます。これらのリソースの名前または ARNs を使用して、出典管理にチェックインしたくない機密値には、Secrets Manager や Systems Manager Parameter Store などのサービスを使用します。

アプリケーションを合成すると、 cdk.outフォルダに作成されたクラウドアセンブリには、環境ごとに個別のテンプレートが含まれます。ビルド全体が決定的です。アプリケーションに変更はなく out-of-band、特定のコミットでは常にまったく同じ AWS CloudFormation テンプレートとそれに付随するアセットが生成されます。これにより、ユニットテストの信頼性が向上します。

すべてを測定する

人間の介入なしで完全な継続的デプロイという目標を達成するためには、高レベルの自動化が必要です。この自動化は、大量のモニタリングでのみ可能です。デプロイされたリソースのあらゆる側面を測定するには、メトリクス、アラーム、ダッシュボードを作成します。CPU 使用率やディスク容量などの測定を停止しないでください。また、ビジネスメトリクスを記録し、それらの測定値を使用して、ロールバックなどのデプロイの決定を自動化します。の L2 コンストラクトのほとんど AWS CDK には、dynamodb.Table クラスの metricUserErrors()メソッドなど、メトリクスの作成に役立つ便利なメソッドがあります。