これは AWS CDK v2 デベロッパーガイドです。旧版の CDK v1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS CDK を使用してクラウドインフラストラクチャを開発およびデプロイするためのベストプラクティス
AWS CDK を使用すると、開発者または管理者は、サポートされているプログラミング言語を使用してクラウドインフラストラクチャを定義できます。CDK アプリケーションは、API、データベース、モニタリングリソースなどの論理単位に整理し、オプションで自動デプロイ用のパイプラインを用意する必要があります。論理単位は、以下を含むコンストラクトとして実装する必要があります。
+ インフラストラクチャ (Amazon S3 バケット、Amazon RDS データベース、Amazon VPC ネットワークなど)
+ ランタイムコード ( AWS Lambda 関数など)
+ 設定コード
スタックは、これらの論理ユニットのデプロイモデルを定義します。CDK の概念の詳細については、[AWS 「CDK の開始方法](getting-started.md)」を参照してください。
AWS CDK は、顧客や内部チームのニーズと、複雑なクラウドアプリケーションのデプロイと継続的なメンテナンス中に頻繁に発生する障害パターンを慎重に検討することを反映しています。多くの場合、障害は、設定変更などが十分にテストされていないアプリケーションに対する「アウトオブバンド」な変更に関連していることがわかっています。したがって、アプリケーション全体がビジネスロジックだけでなく、インフラストラクチャと設定もコードで定義されているモデルを中心に AWS CDK を開発しました。そうすることで、提案された変更を慎重に検討し、本番環境に似た環境でさまざまな程度に包括的にテストし、問題が発生した場合は完全にロールバックできます。
![\[インフラストラクチャ、アプリケーション、ソースコード、設定、デプロイを表すソフトウェア開発ライフサイクルアイコン。\]](http://docs.aws.amazon.com/ja_jp/cdk/v2/guide/images/all-in-one.jpg)
デプロイ時に、 AWS CDK は以下を含むクラウドアセンブリを合成します。
+ すべてのターゲット環境のインフラストラクチャを記述する AWS CloudFormation テンプレート
+ ランタイムコードとそのサポートファイルを含むファイルアセット
CDK を使用すると、アプリケーションのメインバージョン管理ブランチのすべてのコミットが、完全で一貫性があり、デプロイ可能なアプリケーションのバージョンを表すことができます。その後、変更が行われるたびにアプリケーションは自動的にデプロイされます。
AWS CDK の背後にある哲学は、推奨されるベストプラクティスにつながります。ベストプラクティスは、4 つの広範なカテゴリに分かれています。
+ [組織のベストプラクティス](#best-practices-organization)
+ [コーディングのベストプラクティス](#best-practices-code)
+ [ベストプラクティスを構築する](#best-practices-constructs)
+ [アプリケーションのベストプラクティス](#best-practices-apps)
**ヒント**
また、CDK で定義されたインフラストラクチャに該当する場合は、[AWS CloudFormation のベストプラクティス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html)と、使用する個々の AWS サービスのベストプラクティスも考慮してください。
## 組織のベストプラクティス
AWS CDK 導入の初期段階では、成功のために組織をセットアップする方法を考慮することが重要です。CDK を採用する際に、社内の他のメンバーをトレーニングし、指導する責任を担う専門家チームを編成することがベストプラクティスです。このチームの規模は、小規模企業の 1～2 人から、大規模企業の本格的な Cloud Center of Excellence (CCoE) までさまざまです。このチームは、社内でクラウドインフラストラクチャの標準とポリシーを設定し、開発者のトレーニングと指導を担当します。
CCoE は、クラウドインフラストラクチャに使用するプログラミング言語に関するガイダンスを提供する場合があります。詳細については組織によって異なりますが、適切なポリシーにより、開発者は会社のクラウドインフラストラクチャを理解し、維持できます。
CCoE は、組織単位を定義する「ランディングゾーン」も作成します AWS。ランディングゾーンは、ベストプラクティスの設計図に基づいて事前設定された、安全でスケーラブルなマルチアカウント AWS 環境です。ランディングゾーンを構成するサービスを結合するには、[AWS Control Tower](https://aws.amazon.com/controltower/) を使用します。これにより、単一のユーザーインターフェイスからマルチアカウントシステム全体を設定および管理できます。
開発チームは、必要に応じて独自のアカウントを使用して、これらのアカウントに新しいリソースをテストおよびデプロイできることが必要です。個々の開発者は、これらのリソースを独自の開発ワークステーションの拡張機能として扱うことができます。[CDK Pipelines](cdk-pipeline.md) を使用すると、 AWS CDK アプリケーションを CI/CD アカウント経由でテスト、統合、本番環境 (それぞれ独自の AWS リージョンまたはアカウントで分離) にデプロイできます。これは、開発者のコードを組織の正規リポジトリにマージすることで行われます。
![\[CI/CD パイプラインを介した開発者アカウントから複数のターゲットアカウントへのデプロイプロセスを示す図。\]](http://docs.aws.amazon.com/ja_jp/cdk/v2/guide/images/best-practice-deploy-to-multiple-accounts.png)
## テストのベストプラクティス
このセクションでは、 AWS CDK コードを整理するためのベストプラクティスを示します。以下の図は、チームとそのチームのコードリポジトリ、パッケージ、アプリケーション、コンストラクトライブラリとの関係を示しています。
![\[チームのコードの編成を示す図: リポジトリ、パッケージ、CDK アプリ、またはコンストラクトライブラリ。\]](http://docs.aws.amazon.com/ja_jp/cdk/v2/guide/images/code-organization.jpg)
**シンプルに開始し、必要な場合にのみ複雑さを追加する**
ほとんどのベストプラクティスの指針となる原則は、物事をできるだけシンプルにすることですが、それ以上シンプルにすることではありません。要件によってより複雑なソリューションが必要となる場合のみ、複雑さを追加します。 AWS CDK を使用すると、新しい要件をサポートするために、必要に応じてコードをリファクタリングできます。考えられるすべてのシナリオを事前に設計する必要はありません。
** AWS Well-Architected フレームワークに合わせる**
[AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/) フレームワークは、*コンポーネント*を、要件に対して一緒に提供するコード、設定、 AWS リソースとして定義します。コンポーネントは多くの場合、技術的所有権の単位であり、他のコンポーネントとは切り離されています。*ワークロード*は、ビジネス価値を実現する一連のコンポーネントを特定するために使用します。ワークロードの詳細レベルは通常、ビジネスリーダーとテクノロジーリーダーが話し合いで決定します。
AWS CDK アプリケーションは、 AWS Well-Architected Framework で定義されているコンポーネントにマッピングされます。 AWS CDK アプリケーションは、 Well-Architected クラウドアプリケーションのベストプラクティスを体系化して提供するためのメカニズムです。 AWS CodeArtifact などのアーティファクトリポジトリを使用して、再利用可能なコードライブラリとしてコンポーネントを作成および共有することもできます。
**すべてのアプリケーションは、1 つのリポジトリ内の 1 つのパッケージで始まります。**
1 つのパッケージは AWS CDK アプリのエントリポイントです。ここでは、アプリケーションのさまざまな論理ユニットをデプロイする方法と場所を定義します。また、アプリケーションをデプロイする CI/CD パイプラインも定義します。アプリの コンストラクトは、ソリューションの論理単位を定義します。
複数のアプリケーションで使用するコンストラクトには、追加のパッケージを使用します。(共有コンストラクトには、独自のライフサイクル戦略とテスト戦略も必要です)。同じリポジトリ内のパッケージ間の依存関係は、リポジトリのビルドツールによって管理されます。
複数のアプリケーションを同じリポジトリに配置することは、特に自動デプロイパイプラインを使用する場合、可能ですがおすすめしません。そうすることは、デプロイ中の変更の「影響範囲」の増加につながります。リポジトリに複数のアプリケーションがある場合、1 つのアプリケーションに変更を加えることにより、他のアプリケーションのデプロイまで (変更されていなくても) トリガーされます。さらに、あるアプリケーションが中断されると、他のアプリケーションまでデプロイされなくなります。
**コードライフサイクルまたはチームの所有権に基づいてコードをリポジトリに移動する**
パッケージが複数のアプリケーションで使用を開始したら、独自のリポジトリに移動します。これにより、パッケージを使用するアプリケーションビルドシステムでパッケージを参照でき、アプリケーションのライフサイクルとは無関係にケイデンスで更新することもできます。ただし、最初は、すべての共有コンストラクトを 1 つのリポジトリに配置するのが理にかなっている場合があります。
また、異なるチームが作業している場合は、パッケージを独自のリポジトリに移動してください。これにより、アクセスコントロールを適用できます。
リポジトリの境界を越えてパッケージを使用するには、NPM、PyPI、Maven Central に似たプライベートパッケージリポジトリを、組織の内部に持つ必要があります。また、パッケージを構築し、テストし、プライベートパッケージリポジトリに公開するリリースプロセスも必要です。[CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/) は、最も一般的なプログラミング言語のパッケージをホストできます。
パッケージリポジトリ内のパッケージへの依存関係は、TypeScript や JavaScript アプリケーションの場合は NPM など、使用する言語のパッケージマネージャーによって管理されます。パッケージマネージャーは、ビルドが繰り返し可能であることを確認するのに役立ちます。これは、アプリケーションが依存するすべてのパッケージの特定のバージョンを記録することによって行われます。また、これらの依存関係を制御された方法でアップグレードすることもできます。
共有パッケージには別のテスト戦略が必要です。1 つのアプリケーションの場合、アプリケーションをテスト環境にデプロイし、変わらず動作することを確認するだけで十分かもしれません。しかし、共有パッケージは、あたかも一般に公開されているかのように、利用側アプリケーションとは独立してテストする必要があります。(組織は、実際に一部の共有パッケージを公開することを選択する場合があります)。
コンストラクトは、任意に単純にも複雑にもすることができることを念頭に置いてください。`Bucket` がコンストラクトであるように、`CameraShopWebsite` もまたコンストラクトである場合があります。
**インフラストラクチャとランタイムコードが同じパッケージにライブ**
インフラストラクチャをデプロイするための AWS CloudFormation テンプレートの生成に加えて、 AWS CDK は Lambda 関数や Docker イメージなどのランタイムアセットをバンドルし、インフラストラクチャと一緒にデプロイします。これにより、インフラストラクチャを定義するコードとランタイムロジックを実装するコードを 1 つのコンストラクトにまとめることができます。そうするのがベストプラクティスになります。これら 2 種類のコードは、別々のリポジトリに置く必要も、別々のパッケージに置く必要もありません。
2 種類のコードを一緒に進化させるには、インフラストラクチャやロジックなどの機能を完全に記述する自己完結型コンストラクトを使用できます。自己完結型コンストラクトを使用すると、2 種類のコードを個別にテストし、プロジェクト間でコードを共有して再利用し、すべてのコードを同期してバージョン化できます。
## ベストプラクティスのコンストラクト
このセクションでは、コンストラクトを開発するためのベストプラクティスについて説明します。コンストラクトは、リソースをカプセル化した、再利用可能で組み合わせ可能なモジュールです。これらは AWS CDK アプリの構成要素です。
**コンストラクトを使用したモデル、スタックを使用したデプロイ**
スタックはデプロイの単位です。スタック内のすべてのものが一緒にデプロイされます。したがって、アプリケーションの上位レベルの論理ユニットを複数の AWS リソースから構築する場合は、各論理ユニットを[スタック](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.Stack.html)としてではなく[コンストラクト](https://docs.aws.amazon.com/cdk/api/v2/docs/constructs.Construct.html)として表現します。スタックは、さまざまなデプロイシナリオに対してコンストラクトをどのように構成し、接続するかを説明するためにのみ使用します。
たとえば、論理ユニットの 1 つがウェブサイトである場合、それを構成するコンストラクト (Amazon S3 バケット、API ゲートウェイ、Lambda 関数、Amazon RDS テーブルなど) を 1 つの高レベルのコンストラクトに構成する必要があります。次に、そのコンストラクトをデプロイする 1 つ以上のスタックでインスタンス化する必要があります。
構築用のコンストラクトとデプロイ用のスタックを使用することで、インフラストラクチャの再利用の可能性が向上し、デプロイ方法の柔軟性が向上します。
**環境変数ではなくプロパティとメソッドを使用して を設定する**
コンストラクトやスタック内で環境変数を参照することは、一般的なアンチパターンとされています コンストラクトとスタックの両方は、コード内で完全な設定が可能となるように、プロパティオブジェクトを受け入れる必要があります。そうしないと、コードが実行されるマシンに依存関係が生じ、追跡および管理が必要な設定情報がさらに増えることになります。
一般的に、環境変数ルックアップは AWS CDK アプリの最上位レベルに制限する必要があります。また、開発環境で実行するために必要な情報を渡す際にも使用する必要があります。詳細については、[AWS 「CDK の環境](environments.md)」を参照してください。
**インフラストラクチャのユニットテスト**
すべての環境でビルド時にユニットテストのフルスイートを一貫して実行するには、合成中のネットワークルックアップを避け、コード内のすべての本番稼働段階をモデル化します。(これらのベストプラクティスについては、後で説明します)。1 つのコミットから常に同じテンプレートが生成されるのであれば、自分が作成したユニットテストを信頼して、生成されたテンプレートが想定どおりの形になっていることを確認できます 詳細については、[AWS 「CDK アプリケーションのテスト](testing.md)」を参照してください。
**ステートフルリソースの論理 ID を変更しない**
リソースの論理 ID を変更すると、リソースは次回のデプロイ時に新しいリソースに置き換えられます。データベースや S3 バケットなどのステートフルリソース、または Amazon VPC などの永続的なインフラストラクチャの場合、これは通常望ましくない結果となります。ID が変更される可能性のある AWS CDK コードのリファクタリングには注意してください。ステートフルリソースの論理 ID が静的なままであることをアサートするユニットテストを作成してください。論理 ID は、コンストラクトをインスタンス化するときに指定した `id` と、コンストラクトツリー内のコンストラクトの位置から派生します。詳細については、「[論理 ID](identifiers.md#identifiers-logical-ids)」を参照してください。
**コンストラクトのみではコンプライアンスを満たせない**
多くのエンタープライズのお客様は、L2 コンストラクト (組み込みの正常なデフォルトとベストプラクティスを持つ個々の AWS リソースを表す「厳選された」コンストラクト) 用の独自のラッパーを記述しています。これらのラッパーは、静的暗号化や特定の IAM ポリシーなどのセキュリティのベストプラクティスを適用します。たとえば、通常の Amazon S3 `Bucket` コンストラクトの代わりにアプリケーションで使用する `MyCompanyBucket` を作成できます。このパターンは、ソフトウェア開発ライフサイクルの早い段階でセキュリティに関する指針を明確化するのに役立ちますが、これを唯一の強制手段として頼ることは避けてください。
代わりに、[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)や[アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)などの AWS 機能を使用して、組織レベルでセキュリティガードレールを適用します。[Aspects や CloudFormation Guard などの AWS CDK](aspects.md) またはツールを使用して、デプロイ前にインフラストラクチャ要素のセキュリティプロパティについてアサーションを行います。 [CloudFormation ](https://github.com/aws-cloudformation/cloudformation-guard) AWS CDK は、最善を尽くすために使用します。
最後に、独自の「L2\$1」コンストラクトを記述すると、開発者がソリューションコンストラクトや [AWS Construct ](https://docs.aws.amazon.com/solutions/latest/constructs/welcome.html)Hub のサードパーティーコンストラクトなどの AWS CDK パッケージを利用できなくなる可能性があることに注意してください。これらのパッケージは通常、標準の AWS CDK コンストラクト上に構築されており、ラッパーコンストラクトを使用することはできません。
## 統合に関するベストプラクティス
このセクションでは、 AWS CDK アプリケーションを記述し、コンストラクトを組み合わせて AWS リソースの接続方法を定義する方法について説明します。
**合成時に意思決定を行う**
AWS CloudFormation ではデプロイ時に (`Conditions`、、および を使用して`Parameters`) 決定を行うことができますが`{ Fn::If }`、 AWS CDK ではこれらのメカニズムにある程度アクセスできますが、使用しないことをお勧めします。使用できる値の種類や、その値に対して実行できる操作の種類は、汎用プログラミング言語で利用可能なものと比べると限られています。
代わりに、プログラミング言語の `if`ステートメントやその他の機能を使用して、 AWS CDK アプリケーションでインスタンス化するコンストラクトなど、すべての決定を行います。たとえば、リストを反復処理し、リスト内の各項目の値を持つコンストラクトをインスタンス化する一般的な CDK イディオムは、 AWS CloudFormation 式を使用するだけでは不可能です。
Treat 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 パラメータストアに書き込んで、アプリケーションがそこから読み取れるようにすることもできます。
必要な場所が別の AWS CDK スタックである場合は、さらに簡単です。1 つのスタックでリソースを定義し、別のスタックでそのリソースを使用する必要があると仮定すると、以下のようになります。
+ 2 つのスタックが同じ AWS CDK アプリにある場合は、2 つのスタック間で参照を渡します。例えば、リソースのコンストラクトへの参照を定義スタック (`this.stack.uploadBucket = amzn-s3-demo-bucket`) の属性として保存します。次に、その属性をリソースを必要とするスタックのコンストラクターに渡します。
+ 2 つのスタックが異なる AWS CDK アプリケーションにある場合は、静的`from`メソッドを使用して、ARN、名前、またはその他の属性に基づいて外部で定義されたリソースを使用します。(たとえば、DynamoDB テーブルに `Table.fromArn()` を使用します)。`CfnOutput` コンストラクトを使用して、 の出力で ARN またはその他の必要な値を出力するか`cdk deploy`、 AWS マネジメントコンソールを確認します。または、2 番目のアプリケーションは、最初のアプリケーションによって生成された CloudFormation テンプレートを読み取って、`Outputs` セクションからその値を取得することもできます。
**削除ポリシーとログ保持を定義する**
AWS CDK は、作成したものをすべて保持するポリシーをデフォルトで設定することで、データが失われないようにします。たとえば、データを含むリソース (Amazon S3 バケットやデータベーステーブルなど) のデフォルトの削除ポリシーは、スタックから削除されたときにリソースを削除しないことです。代わりに、リソースはスタックから切り離された状態になります。同様に、CDK のデフォルトは、すべてのログを永遠に保持することです。実稼働環境では、これらのデフォルトにより、実際には必要のない大量のデータと、対応する AWS 請求がすぐに保存される可能性があります。
本番稼働用のリソースごとに、これらのポリシーをどうするかは慎重に検討し、適切に指定してください。[アスペクトと AWS CDK](aspects.md) を使用して、スタックの削除ポリシーとログ記録ポリシーを検証します。
**デプロイ要件に従ってアプリケーションを複数のスタックに分割する**
アプリケーションが必要とするスタックの数には、確固たるルールはありません。通常は、デプロイパターンに基づいて決定します。以下のガイドラインに留意してください。
+ 通常、同じスタックにできるだけ多くのリソースを保持する方が簡単です。そのため、分離したいことが分かっている場合を除いて、リソースはまとめて保持します。
+ ステートフルリソース (データベースなど) は、ステートレスリソースとは別のスタックに保持することを検討してください。そうすることで、ステートフルスタックに対し終了保護を有効にできます。これにより、データ損失のリスクなしにステートレススタックの複数のコピーを自由に破壊または作成できます。
+ ステートフルリソースは、コンストラクトの名前の変更に敏感です。名前を変更すると、リソースが置き換えられます。したがって、移動または名前変更される可能性が高いコンストラクト内にステートフルリソースをネストしないでください (キャッシュのように、失われても状態を再構築できる場合を除きます)。これは、ステートフルリソースを独自のスタックに配置するもう 1 つの大きな理由です。
**非決定的な動作を避けるため`cdk.context.json`にコミットする**
決定論は、 AWS CDK のデプロイを成功させるための鍵です。 AWS CDK アプリは、特定の環境にデプロイされるたびに基本的に同じ結果になります。
AWS CDK アプリは汎用プログラミング言語で記述されるため、任意のコードを実行し、任意のライブラリを使用し、任意のネットワーク呼び出しを行うことができます。例えば、 AWS SDK を使用して、アプリの合成中に AWS アカウントからいくつかの情報を取得できます。そうすることで、認証情報のセットアップ要件が追加され、レイテンシーが増加し、`cdk synth` を実行するたびに、たとえわずかでも障害が発生する可能性があることを認識してください。
合成中に AWS アカウントまたはリソースを変更しないでください。アプリケーションの合成に副作用があってはなりません。インフラストラクチャの変更は、 AWS CloudFormation テンプレートが生成された後のデプロイフェーズでのみ行う必要があります。これにより、問題が発生した場合、 AWS CloudFormation は自動的に変更をロールバックできます。 AWS CDK フレームワーク内で簡単に変更できない変更を行うには、[カスタムリソース](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources-readme.html)を使用してデプロイ時に任意のコードを実行します。
厳密に読み取り専用の呼び出しでも、必ずしも安全とは限りません。ネットワークの呼び出しによって返される値が変更された場合にどうなるかを考慮してください。インフラストラクチャのどの部分に影響しますか? 既にデプロイされたリソースはどうなりますか? 以下は、値が突然変化して問題が発生する可能性がある 2 つの状況の例です。
+ 指定したリージョンで使用可能なすべてのアベイラビリティーゾーンに Amazon VPC をプロビジョニングし、デプロイ日に AZ の数が 2 つであった場合、IP スペースは半分に分割されます。が翌日に新しいアベイラビリティーゾーン AWS を起動した場合、その次のデプロイでは IP スペースを 3 つに分割しようとするため、すべてのサブネットを再作成する必要があります。Amazon EC2 インスタンスはまだ実行中であるため、これはおそらく不可能であり、手動でクリーンアップすることが必要になります。
+ 最新の Amazon Linux マシンイメージをクエリして Amazon EC2 インスタンスをデプロイし、翌日に新しいイメージがリリースされた場合、後続のデプロイによって新しい AMI が取得され、すべてのインスタンスが置き換えられます。これは想定した動作ではおそらくないでしょう。
これらの状況は、デプロイが成功してから数か月または数年後に AWSサイドチェンジが発生する可能性があるため、悪意がある可能性があります。デプロイが突然「理由もなく」失敗し、何をしたか、なぜそうしたかはとうの昔に忘れてしまっています。
幸い、 AWS CDK には、非決定的な値のスナップショットを記録する*コンテキストプロバイダー*と呼ばれるメカニズムが含まれています。これにより、将来の合成操作でも、最初にデプロイしたときとまったく同じテンプレートを生成できます。新しいテンプレートには、*ユーザー*がコードに加えた変更以外に変更はありません。コンストラクトの `.fromLookup()` メソッドを使用すると、呼び出しの結果は `cdk.context.json` にキャッシュされます。CDK アプリの今後の実行で同じ値が使用されるように、これを残りのコードとともにバージョン管理にコミットする必要があります。CDK Toolkit にはコンテキストキャッシュを管理するコマンドが含まれているため、必要に応じて特定のエントリを更新できます。詳細については、[「コンテキスト値」と AWS 「CDK](context.md)」を参照してください。
ネイティブ CDK コンテキストプロバイダーがない値 ( AWS または他の場所から) が必要な場合は、別のスクリプトを作成することをお勧めします。スクリプトは値を取得してファイルに書き込み、CDK アプリケーションでそのファイルを読み取る必要があります。スクリプトは、通常のビルドプロセスの一部としてではなく、保存された値を更新する場合のみ実行します。
** AWS CDK がロールとセキュリティグループを管理できるようにする**
AWS CDK コンストラクトライブラリの `grants`プロパティとその便利なメソッドを使用すると、最小限のスコープのアクセス許可を使用して、あるリソースへのアクセスを別のリソースに付与する AWS Identity and Access Management ロールを作成できます。たとえば、次のようなクエリを考えてみます。
```
amzn-s3-demo-bucket.grants.read(myLambda)
```
この 1 行は、Lambda 関数のロールにポリシーを追加します (これはユーザー用にも作成されます)。このロールとそのポリシーは、CloudFormation で記述すれば十数行にもなるものを、書く必要をなくしてくれます。 AWS CDK は、関数がバケットから読み取るために必要な最小限のアクセス許可のみを付与します。
開発者がセキュリティチームによって作成された事前定義されたロールを常に使用する必要がある場合、 AWS CDK コーディングははるかに複雑になります。チームは、アプリケーションの設計方法における柔軟性を大幅に失う可能性があります。より良い代替策は、[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)と[アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)を使用して、開発者がガードレール内に留まるようにすることです。
**コード内のすべての本番稼働段階をモデル化する**
従来の AWS CloudFormation シナリオでは、パラメータ化された単一のアーティファクトを生成して、それらの環境に固有の設定値を適用した後にさまざまなターゲット環境にデプロイできるようにすることが目標です。CDK では、その設定をソースコードに組み込むことができ、またそうすることが必要です。本番環境用のスタックを作成し、他のステージごとに個別のスタックを作成します。次に、各スタックの設定値をコードに入れます。ソース管理にチェックインしたくない機密性の高い値については、リソースの名前または ARN を使用して、[Secrets Manager](https://aws.amazon.com/secrets-manager/) や [Systems Manager](https://aws.amazon.com/systems-manager/) などのパラメータストアサービスを使用します。
アプリケーションを合成すると、`cdk.out` フォルダに作成されたクラウドアセンブリには、環境ごとに個別のテンプレートが含まれます。ビルド全体は確定的です。アプリケーションにout-of-bandの変更はなく、特定のコミットによって常にまったく同じ AWS CloudFormation テンプレートとそれに付随するアセットが生成されます。これにより、ユニットテストの信頼性が向上します。
**すべてを測定する**
人間の介入なしで完全な継続的デプロイの目標を達成するには、高度な自動化が必要です。この自動化を可能にするには、大量のモニタリングが必要になります。デプロイされたリソースのすべてのアスペクトを測定するには、メトリクス、アラーム、ダッシュボードを作成します。CPU 使用量やディスク容量などの測定は決して停止しないでください。また、ビジネスメトリクスを記録し、これらの測定値を使用して、ロールバックなどのデプロイの決定を自動化します。 AWS CDK の L2 コンストラクトのほとんどには、 [https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_dynamodb.Table.html](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_dynamodb.Table.html) クラスの メソッドなど、メトリクスの作成に役立つ便利な`metricUserErrors()`メソッドがあります。