AWS CDK v1 から AWS CDK v2 への移行 - AWS Cloud Development Kit (AWS CDK) v2

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

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

AWS CDK v1 から AWS CDK v2 への移行

のバージョン 2 AWS Cloud Development Kit (AWS CDK) は、任意のプログラミング言語でインフラストラクチャをコードとして簡単に記述できるように設計されています。このトピックでは、 の v1 と v2 の間の変更について説明します AWS CDK。

ヒント

AWS CDK v1 でデプロイされたスタックを特定するには、awscdk-v1-stack-finder ユーティリティを使用します。

AWS CDK v1 から v2 CDK への主な変更点は次のとおりです。

  • AWS CDK v2 は、コアライブラリを含む AWS コンストラクトライブラリの安定した部分を 1 つのパッケージ に統合しますaws-cdk-lib。デベロッパーは、使用する個々の AWS サービスに追加のパッケージをインストールする必要はありません。この単一パッケージアプローチは、さまざまなCDKライブラリパッケージのバージョンを同期する必要もないことも意味します。

    で利用可能な正確なリソースを表す L1 (Cfn XXXX) コンストラクトは AWS CloudFormation、常に安定していると見なされ、 に含まれますaws-cdk-lib

  • コミュニティと協力して新しい L2 または L3 コンストラクト を開発している実験モジュールは、 には含まれていませんaws-cdk-lib。代わりに、個々のパッケージとして配布されます。実験パッケージの名前にはalpha、サフィックスとセマンティックバージョン番号が付きます。セマンティックバージョン番号は、互換性がある AWS コンストラクトライブラリの最初のバージョンと一致し、alphaサフィックスが付いています。コンストラクトは安定して指定されたaws-cdk-lib後、 に移動し、メインコンストラクトライブラリが厳密なセマンティックバージョニングに従うことを許可します。

    安定性はサービスレベルで指定されます。例えば、この書き込みで L1 コンストラクトのみを持つ Amazon の 1 つ以上の L2 コンストラクトの作成を開始すると、それらはまず という名前のモジュールに表示されます@aws-cdk/aws-appflow-alpha。 AppFlow L1 次に、新しいコンストラクトaws-cdk-libが顧客の基本的なニーズを満たすと、 に移行します。

    モジュールが安定していると指定され、 に組み込まれるとaws-cdk-lib、次の箇条書きで説明するBetaN」規則を使用して新しい APIsが追加されます。

    各実験モジュールの新しいバージョンは、 のリリースごとにリリースされます AWS CDK。ただし、ほとんどの場合、同期しておく必要はありません。aws-cdk-lib または実験的なモジュールは、いつでもアップグレードできます。ただし、2 つ以上の関連する実験モジュールが相互に依存している場合、それらは同じバージョンである必要があります。

  • 新機能が追加されている安定したモジュールの場合、新しい APIs (完全に新しいコンストラクトでも、既存のコンストラクトの新しいメソッドやプロパティでも) Beta1 作業の進行中にサフィックスを受け取ります。(重大な変更が必要な場合Beta3、、 Beta2などに続きます。) が安定しているとAPI指定されると、サフィックスAPIのない のバージョンが追加されます。その後、最新の (ベータ版か最終版かにかかわらず) を除くすべてのメソッドが廃止されます。

    例えば、コンストラクトgrantPower()に新しいメソッドを追加すると、最初は と表示されますgrantPowerBeta1()。重大な変更が必要な場合 (新しい必須パラメータやプロパティなど)grantPowerBeta2()、メソッドの次のバージョンには という名前が付けられます。作業が完了し、 APIが確定されると、 メソッド grantPower() (サフィックスなし) が追加され、BetaN メソッドは廃止されます。

    すべてのベータ版は、次のメジャーバージョン (3.0) リリースまで コンストラクトライブラリにAPIs残り、署名は変更されません。非推奨の警告が表示されるので、APIできるだけ早く の最終バージョンに移動する必要があります。ただし、今後の AWS CDK 2.x リリースではアプリケーションが破損することはありません。

  • Construct クラスは、関連するタイプとともに、 から別のライブラリ AWS CDK に抽出されています。これは、コンストラクトプログラミングモデルを他のドメインに適用する取り組みをサポートするために行われます。独自のコンストラクトを記述する場合、または関連する を使用する場合はAPIs、constructsモジュールを依存関係として宣言し、インポートにわずかな変更を加える必要があります。CDK アプリケーションのライフサイクルへのフックなど、高度な機能を使用している場合は、さらに変更が必要になる場合があります。詳細については、「」を参照してくださいRFC

  • AWS CDK v1.x とそのコンストラクトライブラリの非推奨のプロパティ、メソッド、タイプは v2 CDK から完全に削除されましたAPI。サポートされているほとんどの言語では、v1.x で警告APIsが表示されるため、代替 に既に移行している可能性がありますAPIs。v1.x で廃止された の完全なリストAPIsは、 で入手できます GitHub。 CDK

  • AWS CDK v1.x の機能フラグによってゲートされた動作は、v2 CDK ではデフォルトで有効になっています。以前の機能フラグは不要になり、ほとんどの場合、サポートされません。非常に特定の状況でも v1 CDK の動作に戻すことができるものもあります。詳細については、「機能フラグの更新」を参照してください。

  • CDK v2 では、デプロイ先の環境を最新のブートストラップスタックを使用してブートストラップする必要があります。レガシーブートストラップスタック (v1 のデフォルト) はサポートされなくなりました。CDK v2 では、最新のスタックの新しいバージョンがさらに必要になります。既存の環境をアップグレードするには、それらをリブートストラップします。最新のブートストラップスタックを使用するために、機能フラグや環境変数を設定する必要がなくなりました。

重要

最新のブートストラップテンプレートは、 が暗示するアクセス許可--cloudformation-execution-policies--trustリスト内の任意の AWS アカウントに効果的に付与します。デフォルトでは、これにより、ブートストラップされたアカウントの任意のリソースに対する読み取りと書き込みのアクセス許可が拡張されます。ブートストラップスタックには、使い慣れたポリシーと信頼できるアカウントを設定してください。

新しい前提条件

AWS CDK v2 の要件のほとんどは AWS CDK v1.x の要件と同じです。その他の要件を以下に示します。

  • TypeScript デベロッパーの場合は、 TypeScript 3.8 以降が必要です。

  • v2 で使用するには、新しいバージョンの CDK Toolkit CDK が必要です。v2 CDK が一般公開されたので、 ツールキットのインストール時のデフォルトバージョンは v2 CDK です。CDK v1 プロジェクトとの下位互換性があるため、v1 CDK プロジェクトを作成しない限り、以前のバージョンをインストールしたままにする必要はありません。アップグレードするには、 を発行しますnpm install -g aws-cdk

AWS CDK v2 デベロッパープレビューからのアップグレード

CDK v2 デベロッパープレビューを使用している場合、プロジェクトには AWS CDK、 などのリリース候補バージョンの への依存関係があります2.0.0-rc1。これらを に更新し2.0.0、プロジェクトにインストールされているモジュールを更新します。

TypeScript

npm install 、、または yarn install

JavaScript

npm install 、、または yarn install

Python
python -m pip install -r requirements.txt
Java
mvn package
C#
dotnet restore
Go
go get

依存関係を更新したら、 を発行npm update -g aws-cdkして CDK Toolkit をリリースバージョンに更新します。

AWS CDK v1 から v2 CDK への移行

アプリケーションを AWS CDK v2 に移行するには、まず の機能フラグを更新しますcdk.json。次に、アプリケーションの依存関係を更新し、記述されているプログラミング言語の必要に応じてインポートします。

最近の v1 への更新

古いバージョンの AWS CDK v1 から最新バージョンの v2 に 1 ステップでアップグレードしているお客様が多数います。そうすることは間違いありませんが、数年にわたる変更 (残念ながら、すべてに現在実施されている進化テストの量が同じではない可能性があります) をアップグレードするだけでなく、新しいデフォルトと別のコード組織でバージョンをまたいでアップグレードすることになります。

最も安全なアップグレードエクスペリエンスを実現し、予期しない変更の原因をより簡単に診断するには、次の 2 つのステップを分離することをお勧めします。まず最新の v1 バージョンにアップグレードしてから、後で v2 に切り替えることです。

機能フラグの更新

次の v1 機能フラグが存在するcdk.json場合は、 から削除します。これらはすべて AWS CDK v2 でデフォルトでアクティブになっているためです。インフラストラクチャにとって古い影響が重要な場合は、ソースコードを変更する必要があります。詳細については、 のフラグのリストを参照してください GitHub

  • @aws-cdk/core:enableStackNameDuplicates

  • aws-cdk:enableDiffNoFail

  • @aws-cdk/aws-ecr-assets:dockerIgnoreSupport

  • @aws-cdk/aws-secretsmanager:parseOwnedSecretName

  • @aws-cdk/aws-kms:defaultKeyPolicies

  • @aws-cdk/aws-s3:grantWriteWithoutAcl

  • @aws-cdk/aws-efs:defaultEncryptionAtRest

特定の v1 動作に戻すfalseために、数個の AWS CDK v1 機能フラグを に設定することができます。完全なリファレンスについては、v1 の動作に戻す「」または GitHub 「」のリストを参照してください。

どちらのタイプのフラグでも、 cdk diff コマンドを使用して合成されたテンプレートの変更を検査し、これらのフラグのいずれかの変更がインフラストラクチャに影響するかどうかを確認します。

CDK ツールキットの互換性

CDK v2 には、 CDKツールキットの v2 以降が必要です。このバージョンは v1 CDK アプリケーションと下位互換性があります。したがって、グローバルにインストールされた 1 つのバージョンの CDK Toolkit を、v1 と v2 のどちらを使用するかにかかわらず、すべての AWS CDK プロジェクトで使用できます。例外として、CDKToolkit v2 は v2 CDK プロジェクトのみを作成します。

v1 プロジェクトと v2 CDKプロジェクトの両方を作成する必要がある場合は、CDKToolkit v2 をグローバルにインストールしないでください。(既にインストールされている場合は削除します: )npm remove -g aws-cdk。Toolkit を呼び出すにはCDK、 npxを使用して、必要に応じて CDK Toolkit の v1 または v2 を実行します。

npx aws-cdk@1.x init app --language typescript npx aws-cdk@2.x init app --language typescript
ヒント

コマンドラインエイリアスを設定して、 cdkおよび cdk1 コマンドを使用して目的のバージョンの CDK Toolkit を呼び出すことができます。

macOS/Linux
alias cdk1="npx aws-cdk@1.x" alias cdk="npx aws-cdk@2.x"
Windows
doskey cdk1=npx aws-cdk@1.x $* doskey cdk=npx aws-cdk@2.x $*

依存関係とインポートの更新

アプリケーションの依存関係を更新し、新しいパッケージをインストールします。最後に、コードのインポートを更新します。

TypeScript
アプリケーション

CDK アプリの場合は、package.json次のように更新します。v1 スタイルの個々の安定したモジュールへの依存関係を削除し、アプリケーションaws-cdk-libに必要な最低バージョンの を確立します (ここでは 2.0.0)。

実験コンストラクトは、 で終わる名前alphaとアルファバージョン番号を持つ個別の独立したバージョニングパッケージで提供されます。アルファバージョン番号は、互換性aws-cdk-libがある の最初のリリースに対応します。ここでは、 aws-codestarを v2.0.0-alpha.1 に固定しました。

{ "dependencies": { "aws-cdk-lib": "^2.0.0", "@aws-cdk/aws-codestar-alpha": "2.0.0-alpha.1", "constructs": "^10.0.0" } }
ライブラリの構築

コンストラクトライブラリaws-cdk-libの場合は、アプリケーションに必要な最低バージョンの を確立し (ここでは 2.0.0)package.json、次のように更新します。

は、ピア依存関係と dev 依存関係の両方としてaws-cdk-lib表示されることに注意してください。

{ "peerDependencies": { "aws-cdk-lib": "^2.0.0", "constructs": "^10.0.0" }, "devDependencies": { "aws-cdk-lib": "^2.0.0", "constructs": "^10.0.0", "typescript": "~3.9.0" } }
注記

v2 互換ライブラリをリリースするときは、ライブラリのバージョン番号にメジャーバージョンバンプを実行する必要があります。これは、ライブラリコンシューマーにとって重大な変更であるためです。1 つのライブラリで CDK v1 と v2 の両方をサポートすることはできません。引き続き v1 を使用しているお客様をサポートするには、以前のリリースを並行して維持するか、v2 用の新しいパッケージを作成します。

AWS CDK v1 のお客様のサポートを継続する期間は、お客様次第です。2022 年 6 月 CDK 1 日にメンテナンスを開始し、2023 年 6 月 1 end-of-life 日に到達する v1 自体のライフサイクルからキューを取ることができます。詳細については、AWS CDK 「メンテナンスポリシー」を参照してください。

ライブラリとアプリケーションの両方

npm install または を実行して、新しい依存関係をインストールしますyarn install

インポートを変更して、新しいconstructsモジュールConstructからインポートしたり、 Appや などのコアタイプを の最上位レベルStackからインポートしたりaws-cdk-lib、 の名前空間から使用するサービスの安定した ライブラリモジュールを構築したりできますaws-cdk-lib

import { Construct } from 'constructs'; import { App, Stack } from 'aws-cdk-lib'; // core constructs import { aws_s3 as s3 } from 'aws-cdk-lib'; // stable module import * as codestar from '@aws-cdk/aws-codestar-alpha'; // experimental module
JavaScript

package.json 次のように更新します。v1 スタイルの個々の安定したモジュールへの依存関係を削除し、アプリケーションaws-cdk-libに必要な最低バージョンの を確立します (ここでは 2.0.0)。

実験コンストラクトは、 で終わる名前alphaとアルファバージョン番号を持つ個別の独立したバージョニングパッケージで提供されます。アルファバージョン番号は、互換性aws-cdk-libがある の最初のリリースに対応します。ここでは、 aws-codestarを v2.0.0-alpha.1 に固定しました。

{ "dependencies": { "aws-cdk-lib": "^2.0.0", "@aws-cdk/aws-codestar-alpha": "2.0.0-alpha.1", "constructs": "^10.0.0" } }

npm install または を実行して、新しい依存関係をインストールしますyarn install

アプリのインポートを変更して、次の操作を行います。

  • 新しいconstructsモジュールConstructからのインポート

  • App や などのコアタイプを の最上位レベルStackからインポートする aws-cdk-lib

  • で名前空間から AWS コンストラクトライブラリモジュールをインポートする aws-cdk-lib

const { Construct } = require('constructs'); const { App, Stack } = require('aws-cdk-lib'); // core constructs const s3 = require('aws-cdk-lib').aws_s3; // stable module const codestar = require('@aws-cdk/aws-codestar-alpha'); // experimental module
Python

requirements.txt または install_requires 定義をsetup.py次のように更新します。v1 スタイルの個々の安定したモジュールへの依存関係を削除します。

実験コンストラクトは、 で終わる名前alphaとアルファバージョン番号を持つ個別の独立したバージョニングパッケージで提供されます。アルファバージョン番号は、互換性aws-cdk-libがある の最初のリリースに対応します。ここでは、 aws-codestarを v2.0.0alpha1 に固定しました。

install_requires=[ "aws-cdk-lib>=2.0.0", "constructs>=10.0.0", "aws-cdk.aws-codestar-alpha>=2.0.0alpha1", # ... ],
ヒント

を使用して、アプリケーションの仮想環境にインストール済みの AWS CDK モジュールの他のバージョンをアンインストールしますpip uninstall。次に、 で新しい依存関係をインストールしますpython -m pip install -r requirements.txt

アプリのインポートを変更して、次の操作を行います。

  • 新しいconstructsモジュールConstructからのインポート

  • App や などのコアタイプを の最上位レベルStackからインポートする aws_cdk

  • で名前空間から AWS コンストラクトライブラリモジュールをインポートする aws_cdk

from constructs import Construct from aws_cdk import App, Stack # core constructs from aws_cdk import aws_s3 as s3 # stable module import aws_cdk.aws_codestar_alpha as codestar # experimental module # ... class MyConstruct(Construct): # ... class MyStack(Stack): # ... s3.Bucket(...)
Java

pom.xml、安定したモジュールのsoftware.amazon.awscdk依存関係をすべて削除し、 software.constructs ( の場合Construct) と の依存関係に置き換えますsoftware.amazon.awscdk

実験コンストラクトは、 で終わる名前alphaとアルファバージョン番号を持つ個別の独立したバージョニングパッケージで提供されます。アルファバージョン番号は、互換性aws-cdk-libがある の最初のリリースに対応します。ここでは、 aws-codestarを v2.0.0-alpha.1 に固定しました。

<dependency> <groupId>software.amazon.awscdk</groupId> <artifactId>aws-cdk-lib</artifactId> <version>2.0.0</version> </dependency><dependency> <groupId>software.amazon.awscdk</groupId> <artifactId>code-star-alpha</artifactId> <version>2.0.0-alpha.1</version> </dependency> <dependency> <groupId>software.constructs</groupId> <artifactId>constructs</artifactId> <version>10.0.0</version> </dependency>

を実行して、新しい依存関係をインストールしますmvn package

コードを変更して、次の操作を行います。

  • 新しいsoftware.constructsライブラリConstructからのインポート

  • Stack や などのコアクラスを Appからインポートする software.amazon.awscdk

  • からサービスコンストラクトをインポートする software.amazon.awscdk.services

import software.constructs.Construct; import software.amazon.awscdk.Stack; import software.amazon.awscdk.StackProps; import software.amazon.awscdk.App; import software.amazon.awscdk.services.s3.Bucket; import software.amazon.awscdk.services.codestar.alpha.GitHubRepository;
C#

C# CDKアプリケーションの依存関係をアップグレードする最も簡単な方法は、.csprojファイルを手動で編集することです。安定したAmazon.CDK.*パッケージリファレンスをすべて削除し、 Amazon.CDK.Libおよび Constructsパッケージへのリファレンスに置き換えます。

実験コンストラクトは、 で終わる名前alphaとアルファバージョン番号を持つ個別の独立したバージョニングパッケージで提供されます。アルファバージョン番号は、互換性aws-cdk-libがある の最初のリリースに対応します。ここでは、 aws-codestarを v2.0.0-alpha.1 に固定しました。

<PackageReference Include="Amazon.CDK.Lib" Version="2.0.0" /> <PackageReference Include="Amazon.CDK.AWS.Codestar.Alpha" Version="2.0.0-alpha.1" /> <PackageReference Include="Constructs" Version="10.0.0" />

を実行して、新しい依存関係をインストールしますdotnet restore

ソースファイルのインポートを次のように変更します。

using Constructs; // for Construct class using Amazon.CDK; // for core classes like App and Stack using Amazon.CDK.AWS.S3; // for stable constructs like Bucket using Amazon.CDK.Codestar.Alpha; // for experimental constructs
Go

依存関係を最新バージョンに更新し、プロジェクトの .mod ファイルを更新するgo get問題。

デプロイ前に移行したアプリケーションをテストする

スタックをデプロイする前に、 cdk diffを使用してリソースに予期しない変更がないか確認します。論理IDs的 (リソースの置き換えの原因となる) への変更は想定されません

予想される変更には以下が含まれますが、これらに限定されません。

  • CDKMetadata リソースの変更。

  • アセットハッシュを更新しました。

  • 新しいスタイルのスタック合成に関連する変更。アプリケーションが v1 でレガシースタックシンセサイザーを使用した場合に適用されます。(CDK v2 はレガシースタックシンセサイザーをサポートしていません)。

  • CheckBootstrapVersion ルールの追加。

予期しない変更は、通常、 AWS CDK v2 自体へのアップグレードによって引き起こされることはありません。通常、これらは機能フラグによって以前に変更された非推奨の動作の結果です。これは、約 1.85.x よりCDK前のバージョンの からアップグレードする兆候です。同じ変更が最新の v1.x リリースにアップグレードされます。通常、これを解決するには、以下を実行します。

  1. アプリケーションを最新の v1.x リリースにアップグレードする

  2. 機能フラグを削除する

  3. 必要に応じてコードを修正する

  4. デプロイ

  5. v2 へのアップグレード

注記

2 段階アップグレード後にアップグレードしたアプリがデプロイできない場合は、問題を報告します。

アプリケーションにスタックをデプロイする準備ができたら、最初にコピーをデプロイしてテストできるようにすることを検討してください。これを行う最も簡単な方法は、別のリージョンにデプロイすることです。ただし、スタックIDsの を変更することもできます。テスト後、テストコピーは必ず で破棄してくださいcdk destroy

トラブルシューティング

TypeScript 'from' expected インポートの または ';' expected エラー

を TypeScript 3.8 以降にアップグレードします。

「cdk ブートストラップ」を実行する

次のようなエラーが表示される場合:

❌  MyStack failed: Error: MyStack: SSM parameter /cdk-bootstrap/hnb659fds/version not found. Has the environment been bootstrapped? Please run 'cdk bootstrap' (see https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html)
    at CloudFormationDeployments.validateBootstrapStackVersion (.../aws-cdk/lib/api/cloudformation-deployments.ts:323:13)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
MyStack: SSM parameter /cdk-bootstrap/hnb659fds/version not found. Has the environment been bootstrapped? Please run 'cdk bootstrap' (see https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html)

AWS CDK v2 には更新されたブートストラップスタックが必要であり、さらにすべての v2 デプロイにはブートストラップリソースが必要です。(v1 では、ブートストラップなしでシンプルなスタックをデプロイできます。) 詳細については、「AWS CDK ブートストラップ」を参照してください。

v1 スタックの検索

CDK アプリケーションを v1 から v2 に移行するときは、v1 を使用して作成されたデプロイされた AWS CloudFormation スタックを特定できます。これを行うには、次のコマンドを実行します。

npx awscdk-v1-stack-finder

使用の詳細については、awscdk-v1-stack-finder を参照してくださいREADME