これは v2 AWS CDK デベロッパーガイドです。古い CDKv1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS CDK でクラウドインフラストラクチャを開発およびデプロイするためのベストプラクティス
AWS CDK を使用すると、開発者または管理者は、サポートされているプログラミング言語を使用してクラウドインフラストラクチャを定義できます。CDK アプリケーションは、API、データベース、モニタリングリソースなどの論理単位に整理し、オプションで自動デプロイ用のパイプラインを用意する必要があります。論理単位は、以下を含むコンストラクトとして実装する必要があります。
-
インフラストラクチャ (Amazon S3 バケット、Amazon RDS データベース、Amazon VPC ネットワークなど)
-
ランタイムコード (AWS Lambda 関数など)
-
設定コード
スタックは、これらの論理ユニットのデプロイモデルを定義します。CDK の背後にあるコンセプトについての詳細は、「AWS CDK の開始方法」を参照してください。
AWS CDK は、お客様や内部チームのニーズと、複雑なクラウドアプリケーションのデプロイや継続的なメンテナンス中に頻繁に発生する障害パターンへの慎重な考慮を反映しています。多くの場合、障害は、設定変更などが十分にテストされていないアプリケーションに対する「アウトオブバンド」な変更に関連していることがわかっています。そのため、ビジネスロジックだけでなく、インフラストラクチャや設定を含めたアプリケーション全体がコードで定義されるモデルを中心として AWS CDK を開発しました。そうすることで、提案された変更を慎重に検討し、本番環境に似た環境でさまざまな程度に包括的にテストし、問題が発生した場合は完全にロールバックできます。

デプロイ時に、AWS CDK は以下を含むクラウドアセンブリを合成します。
-
すべてのターゲット環境のインフラストラクチャを記述する AWS CloudFormation テンプレート
-
ランタイムコードとそのサポートファイルを含むファイルアセット
CDK を使用すると、アプリケーションのメインバージョン管理ブランチのすべてのコミットが、完全で一貫性があり、デプロイ可能なアプリケーションのバージョンを表すことができます。その後、変更が行われるたびにアプリケーションは自動的にデプロイされます。
AWS CDK の背後にある哲学は、推奨されるベストプラクティスにつながります。ベストプラクティスは、4 つの広範なカテゴリに分けられています。
ヒント
また、CDK で定義されたインフラストラクチャに適用できる場合は、AWS CloudFormation のベストプラクティス、および使用する個々の AWS サービスのベストプラクティスについても考慮してください。
組織のベストプラクティス
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 フレームワークで定義されているように、AWS CDK アプリケーションはコンポーネントにマッピングされます。AWS CDK アプリケーションは Well-Architected クラウドアプリケーションのベストプラクティスを体系化して提供するためのメカニズムです。AWS CodeArtifact などのアーティファクトリポジトリを使用して、再利用可能なコードライブラリとしてコンポーネントを作成および共有することもできます。
すべてのアプリケーションは 1 つのリポジトリ内の 1 つのパッケージで始まる
1 つのパッケージが AWS CDK アプリケーションのエントリポイントとなります。ここでは、アプリケーションのさまざまな論理ユニットをデプロイする方法と場所を定義します。また、アプリケーションをデプロイする CI/CD パイプラインも定義します。アプリの コンストラクトは、ソリューションの論理単位を定義します。
複数のアプリケーションで使用するコンストラクトには、追加のパッケージを使用します。(共有コンストラクトには、独自のライフサイクル戦略とテスト戦略も必要です)。同じリポジトリ内のパッケージ間の依存関係は、リポジトリのビルドツールによって管理されます。
複数のアプリケーションを同じリポジトリに配置することは、特に自動デプロイパイプラインを使用する場合、可能ですがおすすめしません。そうすることは、デプロイ中の変更の「影響範囲」の増加につながります。リポジトリに複数のアプリケーションがある場合、1 つのアプリケーションに変更を加えることにより、他のアプリケーションのデプロイまで (変更されていなくても) トリガーされます。さらに、あるアプリケーションが中断されると、他のアプリケーションまでデプロイされなくなります。
コードライフサイクルまたはチームの所有権に基づいてコードをリポジトリに移動する
パッケージが複数のアプリケーションで使用を開始したら、独自のリポジトリに移動します。これにより、パッケージを使用するアプリケーションビルドシステムでパッケージを参照でき、アプリケーションのライフサイクルとは無関係にケイデンスで更新することもできます。ただし、最初は、すべての共有コンストラクトを 1 つのリポジトリに配置するのが理にかなっている場合があります。
また、異なるチームが作業している場合は、パッケージを独自のリポジトリに移動してください。これにより、アクセスコントロールを適用できます。
リポジトリの境界を越えてパッケージを使用するには、NPM、PyPI、Maven Central に似たプライベートパッケージリポジトリを、組織の内部に持つ必要があります。また、パッケージを構築し、テストし、プライベートパッケージリポジトリに公開するリリースプロセスも必要です。CodeArtifact は、最も一般的なプログラミング言語のパッケージをホストできます。
パッケージリポジトリ内のパッケージへの依存関係は、TypeScript や JavaScript アプリケーションの場合は NPM など、使用する言語のパッケージマネージャーによって管理されます。パッケージマネージャーは、ビルドが繰り返し可能であることを確認するのに役立ちます。これは、アプリケーションが依存するすべてのパッケージの特定のバージョンを記録することによって行われます。また、これらの依存関係を制御された方法でアップグレードすることもできます。
共有パッケージには別のテスト戦略が必要です。1 つのアプリケーションの場合、アプリケーションをテスト環境にデプロイし、変わらず動作することを確認するだけで十分かもしれません。しかし、共有パッケージは、あたかも一般に公開されているかのように、利用側アプリケーションとは独立してテストする必要があります。(組織は、実際に一部の共有パッケージを公開することを選択する場合があります)。
コンストラクトは、任意に単純にも複雑にもすることができることを念頭に置いてください。Bucket
がコンストラクトであるように、CameraShopWebsite
もまたコンストラクトである場合があります。
インフラストラクチャコードとランタイムコードが同じパッケージ内に存在する
AWS CDK は、インフラストラクチャをデプロイするための AWS CloudFormation テンプレートを生成するだけでなく、Lambda 関数や Docker イメージなどのランタイムアセットをバンドルして、インフラストラクチャと一緒にデプロイします。これにより、インフラストラクチャを定義するコードとランタイムロジックを実装するコードを 1 つのコンストラクトにまとめることができます。そうするのがベストプラクティスになります。これら 2 種類のコードは、別々のリポジトリに置く必要も、別々のパッケージに置く必要もありません。
2 種類のコードを一緒に進化させるには、インフラストラクチャやロジックなどの機能を完全に記述する自己完結型コンストラクトを使用できます。自己完結型コンストラクトを使用すると、2 種類のコードを個別にテストし、プロジェクト間でコードを共有して再利用し、すべてのコードを同期してバージョン化できます。
ベストプラクティスのコンストラクト
このセクションでは、コンストラクトを開発するためのベストプラクティスについて説明します。コンストラクトは、リソースをカプセル化した、再利用可能で組み合わせ可能なモジュールです。これらは AWS CDK アプリケーションの構成要素です。
コンストラクトでモデル化し、スタックでデプロイする
スタックはデプロイの単位です。スタック内のすべてのものが一緒にデプロイされます。したがって、複数の AWS リソースからアプリケーションの上位レベルの論理ユニットを構築する場合、各論理ユニットは Stack
としてではなく Construct
として表現します。スタックは、さまざまなデプロイシナリオに対してコンストラクトをどのように構成し、接続するかを説明するためにのみ使用します。
たとえば、論理ユニットの 1 つがウェブサイトである場合、それを構成するコンストラクト (Amazon S3 バケット、API ゲートウェイ、Lambda 関数、Amazon RDS テーブルなど) を 1 つの高レベルのコンストラクトに構成する必要があります。次に、そのコンストラクトをデプロイする 1 つ以上のスタックでインスタンス化する必要があります。
構築用のコンストラクトとデプロイ用のスタックを使用することで、インフラストラクチャの再利用の可能性が向上し、デプロイ方法の柔軟性が向上します。
環境変数ではなく、プロパティとメソッドで設定する
コンストラクトやスタック内で環境変数を参照することは、一般的なアンチパターンとされています コンストラクトとスタックの両方は、コード内で完全な設定が可能となるように、プロパティオブジェクトを受け入れる必要があります。そうしないと、コードが実行されるマシンに依存関係が生じ、追跡および管理が必要な設定情報がさらに増えることになります。
一般的に、環境変数の参照は、AWS CDK アプリケーションの最上位レベルに制限する必要があります。また、開発環境で実行するために必要な情報を渡す際にも使用する必要があります。詳細については、「AWS CDK の環境」を参照してください。
インフラストラクチャのユニットテスト
すべての環境でビルド時にユニットテストのフルスイートを一貫して実行するには、合成中のネットワークルックアップを避け、コード内のすべての本番稼働段階をモデル化します。(これらのベストプラクティスについては、後で説明します)。1 つのコミットから常に同じテンプレートが生成されるのであれば、自分が作成したユニットテストを信頼して、生成されたテンプレートが想定どおりの形になっていることを確認できます 詳細については、「AWS CDK アプリケーションのテスト」を参照してください。
ステートフルリソースの論理 ID を変更しない
リソースの論理 ID を変更すると、リソースは次回のデプロイ時に新しいリソースに置き換えられます。データベースや S3 バケットなどのステートフルリソース、または Amazon VPC などの永続的なインフラストラクチャの場合、これは通常望ましくない結果となります。ID が変更される可能性のある AWS CDK コードのリファクタリングには注意してください。ステートフルリソースの論理 ID が静的なままであることをアサートするユニットテストを作成してください。論理 ID は、コンストラクトをインスタンス化するときに指定した id
と、コンストラクトツリー内のコンストラクトの位置から派生します。詳細については、「論理 IDs」を参照してください。
コンストラクトのみではコンプライアンスを満たせない
多くのエンタープライズ顧客は、L2 コンストラクト (適切なデフォルト値とベストプラクティスが組み込まれた個々の AWS リソースを表す「キュレーションされた」コンストラクト) に対して独自のラッパーを作成しています。これらのラッパーは、静的暗号化や特定の IAM ポリシーなどのセキュリティのベストプラクティスを適用します。たとえば、通常の Amazon S3 Bucket
コンストラクトの代わりにアプリケーションで使用する MyCompanyBucket
を作成できます。このパターンは、ソフトウェア開発ライフサイクルの早い段階でセキュリティに関する指針を明確化するのに役立ちますが、これを唯一の強制手段として頼ることは避けてください。
代わりに、サービスコントロールポリシーやアクセス許可の境界などのAWS機能を使用して、組織レベルでセキュリティガードレールを適用します。アスペクトと AWS CDK または CloudFormation Guard
最後に、独自の「L2+」コンストラクトを記述すると、開発者が AWS Solutions Constructs や Construct Hub のサードパーティーコンストラクトなどの AWS CDK パッケージを利用できなくなる可能性があることに注意してください。これらのパッケージは通常、標準 AWS CDK コンストラクト上に構築されており、ラッパーコンストラクトを使用することはできません。
統合に関するベストプラクティス
このセクションでは、AWS CDK アプリケーションを記述する方法と、コンストラクトを組み合わせて AWS リソースの接続方法を定義する方法について説明します。
合成時に判断する
AWS CloudFormation は、デプロイ時に (Conditions
、{ Fn::If
}
、Parameters
を使用して) 判断を行うことができ、AWS CDK はこれらの仕組みの一部を利用できますが、これらの仕組みの使用はおすすめしません。使用できる値の種類や、その値に対して実行できる操作の種類は、汎用プログラミング言語で利用可能なものと比べると限られています。
代わりに、AWS CDK アプリケーション内で、どのコンストラクトをインスタンス化するかなど、すべての決定を、プログラミング言語の if
ステートメントやその他の機能を使用して行うようにしてください。たとえば、リストを繰り返し、リスト内の各項目の値を使用してコンストラクトをインスタンス化する一般的な 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 つのスタックでリソースを定義し、別のスタックでそのリソースを使用する必要があると仮定すると、以下のようになります。
-
2 つのスタックが同じ AWS CDK アプリケーションにある場合は、2 つのスタック間でリファレンスを渡します。たとえば、リソースのコンストラクトへの参照を定義スタック (
this.stack.uploadBucket = amzn-s3-demo-bucket
) の属性として保存します。次に、その属性をリソースを必要とするスタックのコンストラクターに渡します。 -
2 つのスタックが異なる AWS CDK アプリケーションにある場合は、静的
from
メソッドを使用して、ARN、名前、またはその他の属性に基づいて外部で定義されたリソースを使用します。(たとえば、DynamoDB テーブルにTable.fromArn()
を使用します)。CfnOutput
コンストラクトを使用して、cdk deploy
の出力で ARN またはその他の必要な値を印刷するか、AWS Management Console を調べます。または、2 番目のアプリケーションは、最初のアプリケーションによって生成された CloudFormation テンプレートを読み取って、Outputs
セクションからその値を取得することもできます。
削除ポリシーとログの保持を定義する
AWS CDK は、作成したすべてのものを保持するポリシーをデフォルトにすることで、データが失われないようにします。たとえば、データを含むリソース (Amazon S3 バケットやデータベーステーブルなど) のデフォルトの削除ポリシーは、スタックから削除されたときにリソースを削除しないことです。代わりに、リソースはスタックから切り離された状態になります。同様に、CDK のデフォルトは、すべてのログを永遠に保持することです。本番稼働環境では、これらのデフォルトにより、実際には必要のない大量のデータが急速に蓄積され、それに応じて AWS の請求が増大する可能性があります。
本番稼働用のリソースごとに、これらのポリシーをどうするかは慎重に検討し、適切に指定してください。スタック内の削除ポリシーとログ記録ポリシーの検証には アスペクトと AWS CDK を使用します。
デプロイ要件に従いアプリケーションを複数のスタックに分割する
アプリケーションが必要とするスタックの数には、確固たるルールはありません。通常は、デプロイパターンに基づいて決定します。以下のガイドラインに留意してください。
-
通常、同じスタックにできるだけ多くのリソースを保持する方が簡単です。そのため、分離したいことが分かっている場合を除いて、リソースはまとめて保持します。
-
ステートフルリソース (データベースなど) は、ステートレスリソースとは別のスタックに保持することを検討してください。そうすることで、ステートフルスタックに対し終了保護を有効にできます。これにより、データ損失のリスクなしにステートレススタックの複数のコピーを自由に破壊または作成できます。
-
ステートフルリソースは、コンストラクトの名前の変更に敏感です。名前を変更すると、リソースが置き換えられます。したがって、移動または名前変更される可能性が高いコンストラクト内にステートフルリソースをネストしないでください (キャッシュのように、失われても状態を再構築できる場合を除きます)。これは、ステートフルリソースを独自のスタックに配置するもう 1 つの大きな理由です。
非確定的な動作を避けるよう cdk.context.json
をコミットする
AWS CDK のデプロイを成功させるには、確定性が重要です。AWS CDK アプリケーションは、特定の環境にデプロイされるたびに基本的に同じ結果になるはずです。
AWS CDK アプリケーションは汎用プログラミング言語で記述されるため、任意のコードを実行し、任意のライブラリを使用し、任意のネットワーク呼び出しを行うことができます。たとえば、AWS SDK を使用して、アプリの合成中に AWS アカウントからいくつかの情報を取得できます。そうすることで、認証情報のセットアップ要件が追加され、レイテンシーが増加し、cdk synth
を実行するたびに、たとえわずかでも障害が発生する可能性があることを認識してください。
合成中は、AWS アカウントやリソースを変更してはなりません。アプリケーションの合成に副作用があってはなりません。インフラストラクチャの変更は、AWS CloudFormation テンプレートが生成された後のデプロイフェーズでのみ行うべきです。こうすることで、問題が発生した場合でも、AWS CloudFormation は自動的に変更をロールバックできます。AWS CDK フレームワーク内で簡単に変更できない変更を行うには、カスタムリソースを使用して、デプロイ時に任意のコードを実行します。
厳密に読み取り専用の呼び出しでも、必ずしも安全とは限りません。ネットワークの呼び出しによって返される値が変更された場合にどうなるかを考慮してください。インフラストラクチャのどの部分に影響しますか? 既にデプロイされたリソースはどうなりますか? 以下は、値が突然変化して問題が発生する可能性がある 2 つの状況の例です。
-
指定したリージョンで使用可能なすべてのアベイラビリティーゾーンに Amazon VPC をプロビジョニングし、デプロイ日に AZ の数が 2 つであった場合、IP スペースは半分に分割されます。AWS が翌日に新しいアベイラビリティーゾーンを起動した場合、その次のデプロイでは IP スペースを 3 分の 1 に分割しようとするため、すべてのサブネットを再作成する必要があります。Amazon EC2 インスタンスはまだ実行中であるため、これはおそらく不可能であり、手動でクリーンアップすることが必要になります。
-
最新の Amazon Linux マシンイメージをクエリして Amazon EC2 インスタンスをデプロイし、翌日に新しいイメージがリリースされた場合、後続のデプロイによって新しい AMI が取得され、すべてのインスタンスが置き換えられます。これは想定した動作ではおそらくないでしょう。
このような状況は、AWS 側の変更が、デプロイが成功してから数か月または数年後に発生する場合もあるため、有害になり得ます。デプロイが突然「理由もなく」失敗し、何をしたか、なぜそうしたかはとうの昔に忘れてしまっています。
幸い、AWS CDK には、非確定的な値のスナップショットを記録するコンテキストプロバイダーと呼ばれる仕組みが含まれています。これにより、将来の合成操作でも、最初にデプロイしたときとまったく同じテンプレートを生成できます。新しいテンプレートには、ユーザーがコードに加えた変更以外に変更はありません。コンストラクトの .fromLookup()
メソッドを使用すると、呼び出しの結果は cdk.context.json
にキャッシュされます。CDK アプリの今後の実行で同じ値が使用されるように、これを残りのコードとともにバージョン管理にコミットする必要があります。CDK Toolkit にはコンテキストキャッシュを管理するコマンドが含まれているため、必要に応じて特定のエントリを更新できます。詳細については、「コンテキスト値と AWS CDK」を参照してください。
ネイティブな CDK コンテキストプロバイダーが存在しない値 (AWS または他のソースからの値) が必要な場合は、別個のスクリプトを作成することをおすすめします。スクリプトは値を取得してファイルに書き込み、CDK アプリケーションでそのファイルを読み取る必要があります。スクリプトは、通常のビルドプロセスの一部としてではなく、保存された値を更新する場合のみ実行します。
AWS CDK がロールとセキュリティグループを管理できるようにする
AWS CDK コンストラクトライブラリの便利メソッド grant()
を使用すると、最小限のスコープのアクセス許可を使用して、別のリソースへのアクセスを許可する AWS Identity and Access Management ロールを作成できます。たとえば、次のようなクエリを考えてみます。
amzn-s3-demo-bucket.grantRead(myLambda)
この 1 行は、Lambda 関数のロールにポリシーを追加します (これはユーザー用にも作成されます)。このロールとそのポリシーは、CloudFormation で記述すれば十数行にもなるものを、書く必要をなくしてくれます。AWS CDK は、関数がバケットから読み取るために必要な最小限のアクセス許可のみを付与します。
開発者がセキュリティチームによって作成された事前定義されたロールを常に使用する必要がある場合、AWS CDK のコーディングははるかに複雑になります。チームは、アプリケーションの設計方法における柔軟性を大幅に失う可能性があります。より良い代替策は、サービスコントロールポリシーとアクセス許可の境界を使用して、開発者がガードレール内に留まるようにすることです。
すべての本番稼働ステージをコードでモデル化
従来の AWS CloudFormation シナリオでは、環境固有の設定値を適用した後に、さまざまなターゲット環境にデプロイできるようにパラメータ化された単一のアーティファクトを生成することが目標となります。CDK では、その設定をソースコードに組み込むことができ、またそうすることが必要です。本番環境用のスタックを作成し、他のステージごとに個別のスタックを作成します。次に、各スタックの設定値をコードに入れます。ソース管理にチェックインしたくない機密性の高い値については、リソースの名前または ARN を使用して、Secrets Manager
アプリケーションを合成すると、cdk.out
フォルダに作成されたクラウドアセンブリには、環境ごとに個別のテンプレートが含まれます。ビルド全体は確定的です。アプリケーションにアウトオブバンドな変更はなく、特定のコミットによって常にまったく同じ AWS CloudFormation テンプレートと、それに伴うアセットが生成されます。これにより、ユニットテストの信頼性が向上します。
すべてを測定する
人間の介入なしで完全な継続的デプロイの目標を達成するには、高度な自動化が必要です。この自動化を可能にするには、大量のモニタリングが必要になります。デプロイされたリソースのすべてのアスペクトを測定するには、メトリクス、アラーム、ダッシュボードを作成します。CPU 使用量やディスク容量などの測定は決して停止しないでください。また、ビジネスメトリクスを記録し、これらの測定値を使用して、ロールバックなどのデプロイの決定を自動化します。AWS CDK のほとんどの L2 コンストラクトには、dynamodb.Table クラス上の metricUserErrors()
メソッドなど、メトリクスの作成に役立つ便利メソッドがあります。