これは AWS CDK v2 デベロッパーガイドです。古い v1 CDK は 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、アプリケーションのメインバージョン管理ブランチのすべてのコミットは、アプリケーションの完全で一貫性のあるデプロイ可能なバージョンを表すことができます。その後、アプリケーションは変更が行われるたびに自動的にデプロイされます。

の背後にある哲学は、4 つの広範なカテゴリに分けられた推奨ベストプラクティス AWS CDK につながります。

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

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 つのリポジトリに配置するのが理にかなっている場合があります。

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

リポジトリの境界を越えてパッケージを使用するには、NPM、、 PyPiまたは Maven Central に似ていますが、組織内部のプライベートパッケージリポジトリが必要です。また、パッケージを構築、テスト、プライベートパッケージリポジトリに発行するリリースプロセスも必要です。CodeArtifact は、最も人気のあるプログラミング言語のパッケージをホストできます。

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

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

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

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

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

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

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

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

コンストラクトでモデル化し、スタックでデプロイする

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

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

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

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

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

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

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

すべての環境でビルド時にユニットテストのフルスイートを一貫して実行するには、合成中のネットワークルックアップを回避し、すべての本番稼働段階をコードでモデル化します。（これらのベストプラクティスについては、後で説明します）。1 回のコミットで常に同じ生成されたテンプレートが表示される場合は、作成したユニットテストを信頼して、生成されたテンプレートが想定どおりに表示されることを確認できます。詳細については、「テスト AWS CDK アプリケーション」を参照してください。

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

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

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

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

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

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

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

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

合成時に決定を下す

AWS CloudFormation ではデプロイ時に (Conditions、、および を使用してParameters) 決定を行うことができますが{ Fn::If }、 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 請求が迅速に保存される可能性があります。

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

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

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

非決定的な動作を避ける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アプリの今後の実行で同じ値が使用されるようにする必要があります。Toolkit CDKにはコンテキストキャッシュを管理するコマンドが含まれているため、必要に応じて特定のエントリを更新できます。詳細については、「コンテキスト値と AWS CDK」を参照してください。

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

がロールとセキュリティグループ AWS CDK を管理できるようにする

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

amzn-s3-demo-bucket.grantRead(myLambda)

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

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

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

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

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

すべてを測定する

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