これは AWS CDK v2 開発者ガイドです。旧版の CDK v1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。
AWS CDK CLI リファレンス
AWS Cloud Development Kit (AWS CDK) コマンドラインインターフェイス (AWS CDK CLI) は、CDK Toolkit とも呼ばれ、AWS CDK アプリを操作するための主要なツールです。アプリを実行し、定義したアプリケーションモデルを調べ、AWS CDK によって生成された AWS CloudFormation テンプレートを作成してデプロイします。また、AWS CDK プロジェクトの作成や操作に役立つ他の機能も提供します。このトピックでは、CDK CLI の一般的なユースケースについて説明します。
CDK CLI は Node Package Manager と共にインストールされます。ほとんどの場合、グローバルにインストールすることが推奨されます。
npm install -g aws-cdk # install latest version npm install -g aws-cdk@X.YY.Z # install specific version
ヒント
AWS CDK の複数のバージョンを定期的に使用する場合は、個々の CDK プロジェクトに CDK CLI の一致するバージョンをインストールすることを検討してください。これを行うには、npm install コマンドから -g を省略します。次に、npx aws-cdk を使用してこれを呼び出します。これにより、ローカルバージョンが存在する場合はローカルバージョンが実行され、存在しない場合はグローバルバージョンに戻ります。
CDK CLI コマンド
すべての CDK CLI コマンドは cdk で始まり、サブコマンド (list、synthesize、deploy など) が続きます。一部のサブコマンドには、同等の短いバージョン (ls、synth など) があります。オプションと引数は、任意の順序でサブコマンドの後に続きます。
すべてのサブコマンド、オプション、因数の説明については、「AWS CDK CLI コマンドリファレンス」を参照してください。
オプションとその値を指定する
コマンドラインオプションは、2 つのハイフン (--) で始まります。よく使用されるオプションの中には、1 つのハイフンで始まる 1 文字のシノニムを持つものがあります (たとえば、--app には -a というシノニムがあります)。CDK CLI コマンドでは、オプションの順序は重要ではありません。
すべてのオプションは値を受け入れ、値はオプション名の後に記述する必要があります。値は、スペースまたは等号記号 (=) で名前と区切ることができます。以下の 2 つのオプションは同じ意味になります。
--toolkit-stack-name MyBootstrapStack --toolkit-stack-name=MyBootstrapStack
一部のオプションはフラグ (ブール値) です。値として true または false を指定できます。値を指定しない場合、値は true と見なされます。また、オプション名に no- を付け、false を暗示することもできます。
# sets staging flag to true --staging --staging=true --staging true # sets staging flag to false --no-staging --staging=false --staging false
いくつかのオプション、具体的には --context、--parameters、--plugin、--tags、--trust というオプションでは、複数の値を指定するために複数回指定することができます。これらは、CDK CLI のヘルプでは [array] 型として記載されています。例:
cdk bootstrap --tags costCenter=0123 --tags responsibleParty=jdoe
組み込みヘルプ
CDK CLI には統合ヘルプが用意されています。以下を実行することで、ユーティリティに関する一般的なヘルプと、提供されているサブコマンドのリストを確認できます。
cdk --help
たとえば deploy など、特定のサブコマンドのヘルプを表示するには、--help フラグの前に指定します。
cdk deploy --help
cdk version を発行すると、CDK CLI のバージョンが表示されます。サポートをリクエストするときは、この情報を入力します。
バージョンのレポート
AWS CDK の使用方法を把握するために、AWS CDK アプリケーションで使用されるコンストラクトは、
AWS::CDK::Metadata として識別されるリソースを使用して収集および報告されます。詳細については、「AWS CDK 使用状況データのレポート作成の設定」を参照してください。
AWS による認証
環境や利用可能な AWS アクセスに応じて、AWS リソースへのプログラムによるアクセスを設定する方法は異なります。
認証方法を選択し、CDK CLI 用に設定するには、「AWS CDK CLI のセキュリティ認証情報を設定する」を参照してください。
ローカルで開発していて、雇用主から認証方法が与えられていない新規ユーザーには、AWS IAM Identity Center を設定することをお勧めします。この方法には、設定を簡単に行ったり、AWS アクセスポータルに定期的にサインインしたりするための AWS CLI をインストールすることも含まれます。この方法を選択した場合、「AWS SDK とツールのリファレンスガイド」の「IAM Identity Center 認証」の手順を完了したあと、環境には次の要素が含まれている必要があります。
-
アプリケーションを実行する前に AWS アクセスポータルセッションを開始するために使用する AWS CLI。
-
AWS CDK から参照できる設定値のセットを含む
[default]プロファイルがある共有 AWS 設定ファイル。このファイルの場所を確認するには、「AWS SDK とツールのリファレンスガイド」の「共有ファイルの場所」を参照してください。 -
共有
configファイルはリージョン設定を設定します。これにより、AWS CDK と CDK CLI が AWS リクエストで使用するデフォルトの AWS リージョンが設定されます。 -
CDK CLI は、リクエストを AWS に送信する前に、プロファイルの SSO トークンプロバイダー設定を使用して認証情報を取得します。IAM Identity Center 許可セットに接続された IAM ロールである
sso_role_name値により、アプリケーションで使用されている AWS サービスにアクセスできます。次のサンプル
configファイルは、SSO トークンプロバイダー設定で設定されたデフォルトプロファイルを示しています。プロファイルのsso_session設定は、指定されたsso-sessionセクションを参照します。sso-sessionセクションには、AWS アクセスポータルセッションを開始するための設定が含まれています。[default] sso_session = <my-sso> sso_account_id = <111122223333> sso_role_name = <SampleRole> region = <us-east-1> output = <json> [sso-session <my-sso>] sso_region = <us-east-1> sso_start_url = <https://provided-domain.awsapps.com/start> sso_registration_scopes = sso:account:access
AWS アクセスポータルセッションを開始する
AWS サービスにアクセスする前に、CDK CLI が IAM Identity Center 認証を使用して認証情報を解決するためのアクティブな AWS アクセスポータルセッションが必要です。設定したセッションの長さによっては、アクセスが最終的に期限切れになり、CDK CLI で認証エラーが発生します。AWS アクセスポータルにサインインするには、AWS CLI で次のコマンドを実行します。
aws sso login
SSO トークンプロバイダー設定でデフォルトのプロファイルではなく名前付きプロファイルを使用している場合、コマンドは aws sso login --profile <NAME> です。--profile オプションまたは AWS_PROFILE 環境変数を使用して cdk コマンドを実行する場合は、このプロファイルも指定します。
既にアクティブなセッションがあるかどうかをテストするには、次の AWS CLI コマンドを実行します。
aws sts get-caller-identity
このコマンドへの応答により、共有 config ファイルに設定されている IAM Identity Center アカウントとアクセス許可のセットが報告されます。
注記
既にアクティブな AWS アクセスポータルセッションがあって aws sso login を実行している場合は、認証情報を入力するように要求されません。
サインインプロセス中に、データへのアクセスを AWS CLI に許可するように求められる場合があります。AWS CLI は SDK for Python 上に構築されているため、アクセス許可メッセージには 名前 botocore のさまざまなバリエーションが含まれる場合があります。
リージョンおよびその他の設定を指定する
CDK CLI は、デプロイ先の AWS リージョンと、AWS で認証する方法を把握している必要があります。これは、デプロイ操作および合成中のコンテキスト値の取得に必要です。アカウントとリージョンは、一緒に環境を構成します。
リージョンは、環境変数または設定ファイルで指定できます。これらは、AWS CLI やさまざまな AWS SDK などの他の AWS ツールで使用されるのと同じ変数とファイルです。CDK CLI は、この情報を次の順序で検索します。
-
AWS_DEFAULT_REGION環境変数。 -
標準 AWS
configファイルで定義され、cdkコマンドの--profileオプションを使用して指定された名前付きプロファイル。 -
標準 AWS
configファイルの[default]セクション。
[default] セクションで AWS 認証とリージョンを指定するだけでなく、1 つ以上の [profile <NAME>] セクションを追加することもできます。ここでは、<NAME> はプロファイルの名前を指します。名前付きプロファイルの詳細については、「AWS SDK とツールのリファレンスガイド」の「共有設定ファイルと認証情報ファイル」を参照してください。
標準 AWS config ファイルは、~/.aws/config (macOS /Linux) または %USERPROFILE%\.aws\config (Windows) に配置されます。詳細および代替の場所については、「AWS SDK およびツールリファレンスガイド」の「共有設定ファイルと共有認証情報ファイルの場所」を参照してください
スタックの env プロパティを使用して AWS CDK アプリで指定する環境は、合成中に使用されます。これは環境固有の AWS CloudFormation テンプレートを生成するために使用されます。デプロイ中は、前述の方法のいずれかで指定されたアカウントまたはリージョンを上書きします。詳細については、「AWS CDK の環境」を参照してください。
注記
AWS CDK は、AWS コマンドラインインターフェイス を含む他の AWS ツールや SDK と同じソースファイルの認証情報を使用します。ただし、AWS CDK の動作はこれらのツールとは多少異なる場合があります。AWS SDK for JavaScript を内部で使用します。AWS SDK for JavaScript の認証情報の設定の詳細については、「認証情報の設定」を参照してください。
任意に --role-arn (または -r) オプションを使用して、デプロイに使用する IAM ロールの ARN を指定できます。このロールは、使用する AWS アカウントによって引き受け可能である必要があります。
アプリケーションコマンドを指定する
CDK CLI の多くの機能では、1 つ以上の AWS CloudFormation テンプレートを合成する必要があり、その場合はアプリケーションの実行が必要です。AWS CDK は、さまざまな言語で記述されたプログラムをサポートしています。そのため、アプリケーションの実行に必要な正確なコマンドを指定するための設定オプションを使用します。このオプションは 2 つの方法で指定できます。
まず、最も一般的なのは、ファイル cdk.json 内の app キーを使用して指定することです。これは AWS CDK プロジェクトのメインディレクトリにあります。CDK CLI は、cdk init で新しいプロジェクトを作成する際に、適切なコマンドを提供します。たとえば、新規の TypeScript プロジェクトの cdk.json は以下のようになります。
{ "app": "npx ts-node bin/hello-cdk.ts" }
CDK CLI は、アプリの実行を試みる際は、現在の作業ディレクトリで cdk.json を検索します。このため、CDK CLI コマンドを実行するために、プロジェクトのメインディレクトリでシェルを開いたままにしておくとよいでしょう。
CDK CLI は、./cdk.json で見つからない場合、~/.cdk.json (つまりホームディレクトリ) でもアプリケーションキーを検索します。通常同じ言語で CDK コードを扱っている場合、アプリコマンドをここに追加しておくと便利です。
他のディレクトリにある場合、または cdk.json のコマンド以外のコマンドを使用してアプリを実行する場合は、--app (または -a) オプションを使用して指定します。
cdk --app "npx ts-node bin/hello-cdk.ts" ls
デプロイ時に、cdk.out のような合成されたクラウドアセンブリを含むディレクトリを、--app の値として指定することもできます。指定されたスタックはこのディレクトリからデプロイされます。アプリは合成されません。
スタックを指定する
多くの CDK CLI コマンド (例: cdk deploy) は、アプリケーション内で定義されたスタックに対して動作します。アプリケーションに含まれているスタックが 1 つだけの場合、スタックを明示的に指定しなくても、CDK CLI はそのスタックを対象とみなします。
それ以外の場合は、作業対象のスタックを指定する必要があります。これは、コマンドライン上で目的のスタックを ID ごとに個別に指定することで行えます。ID は、スタックをインスタンス化するときに 2 番目の引数で指定された値であることを思い出してください。
cdk synth PipelineStack LambdaStack
ワイルドカードを使用して、パターンに一致する ID を指定することもできます。
-
?は、任意の 1 文字にマッチします -
*は任意の数の文字にマッチします (*単独ではすべてのスタックにマッチします) -
**階層内のすべてにマッチします
--all オプションを使用してすべてのスタックを指定することもできます。
アプリケーションが CDK Pipelines を使用している場合、CDK CLI はスタックとステージを階層として理解します。また、--all オプションと * ワイルドカードは最上位スタックのみに一致します。すべてのスタックにマッチするには、** を使用します。また、特定の階層以下のすべてのスタックを示す場合にも、** を使用します。
ワイルドカードを使用する場合は、パターンを引用符で囲むか、\ でワイルドカードをエスケープします。そうしないと、シェルが現在のディレクトリ内のファイルの名前にパターンを展開しようとする可能性があります。良くても期待どおりには動作せず、最悪の場合は、意図していないスタックをデプロイしてしまう恐れがあります。Windows では cmd.exe がワイルドカードを展開しないため、厳密には必要ではありませんが、それでもなおこれは良い習慣です。
cdk synth "*Stack" # PipelineStack, LambdaStack, etc. cdk synth 'Stack?' # StackA, StackB, Stack1, etc. cdk synth \* # All stacks in the app, or all top-level stacks in a CDK Pipelines app cdk synth '**' # All stacks in a CDK Pipelines app cdk synth 'PipelineStack/Prod/**' # All stacks in Prod stage in a CDK Pipelines app
注記
スタックを指定する順序は、必ずしも処理される順序ではありません。CDK CLI は、スタックを処理する順序を決定する際に、スタック間の依存関係を考慮します。例えば、あるスタックが別のスタックによって生成された値 (2 番目のスタックで定義されたリソースの ARN など) を使用しているとします。この場合、この依存関係のため、2 番目のスタックは最初のスタックの前に合成されます。スタックの
addDependency()
メソッドを使用して、スタック間に依存関係を手動で追加できます。
AWS 環境のブートストラップ
CDK を使用してスタックをデプロイするには、特別な専用 AWS CDK リソースをプロビジョニングする必要があります。cdk bootstrap コマンドは、必要なリソースを作成します。これらの専用リソースを必要とするスタックをデプロイする場合にのみ、ブートストラップが必要です。詳細については、「AWS CDK ブートストラップ」を参照してください。
cdk bootstrap
ここに示すように、引数なしで発行された場合、cdk bootstrap コマンドは現在のアプリケーションを合成し、スタックがデプロイされる環境をブートストラップします。環境に依存しないスタックがアプリケーションに含まれ、環境を明示的に指定しない場合、デフォルトのアカウントとリージョンがブートストラップされるか、--profile を使用して指定された環境がブートストラップされます。
アプリケーションの外部では、ブートストラップする環境を明示的に指定する必要があります。また、アプリケーションまたはローカル AWS プロファイルで指定されていない環境をブートストラップする場合にも、同様の手順を踏む必要があります。認証情報は、指定されたアカウントとリージョンに対して設定する必要があります (~/.aws/credentials など)。必要な認証情報を含むプロファイルを指定できます。
cdk bootstrap <ACCOUNT-NUMBER>/<REGION> # e.g. cdk bootstrap 1111111111/us-east-1 cdk bootstrap --profile test 1111111111/us-east-1
重要
このようなスタックをデプロイする各環境 (アカウントとリージョンの組み合わせ) は、個別にブートストラップする必要があります。
AWS CDK がブートストラップされたリソースに保管したものに対して、AWS の料金が発生する場合があります。さらに、--bootstrap-customer-key を使用している場合、AWS KMS キーが作成され、これも環境ごとに料金が発生します。
注記
ブートストラップテンプレートの以前のバージョンでは、デフォルトで KMS キーが作成されました。料金が発生しないようにするには、--no-bootstrap-customer-key を使用してブートストラップを再起動します。
注記
CDK CLI v2 は、CDK v1 でデフォルトで使用されているレガシーテンプレートと呼ばれる元のブートストラップテンプレートをサポートしていません。
重要
最新のブートストラップテンプレートは、--trust リストで任意の AWS アカウントに --cloudformation-execution-policies が暗示するアクセス許可を効果的に付与します。デフォルトでは、ブートストラップされたアカウントに任意のリソースへの読み取りおよび書き込みのアクセス許可が拡張されます。使い慣れたポリシーおよび信頼されたアカウントを使用してブートストラップスタックを設定することを確認してください。
新しいエイリアスの作成
新しいアプリケーションを作成するには、そのアプリケーション用のディレクトリを作成し、ディレクトリ内で cdk init を実行します。
mkdir my-cdk-app cd my-cdk-app cdk init <TEMPLATE> --language <LANGUAGE>
サポートされている言語 (<LANGUAGE>) は次のとおりです。
| コード | 言語 |
|---|---|
|
|
TypeScript |
|
|
JavaScript |
|
|
Python (パイソン) |
|
|
Java |
|
|
C# |
|
|
Go |
<TEMPLATE> はオプションのテンプレートです。目的のテンプレートがアプリケーション (デフォルト) の場合は、省略することができます。使用可能なテンプレートは次のとおりです。
| テンプレート | 説明 |
|---|---|
|
|
空の AWS CDK アプリを作成します。 |
|
|
Amazon SQS キューと Amazon SNS トピックを含むスタックを使用して AWS CDK アプリを作成します。 |
テンプレートは、プロジェクトフォルダの名前を使用して、新しいアプリケーション内のファイルやクラスの名前を生成します。
スタックを一覧表示する
AWS CDK アプリ内のスタックの ID のリストを表示するには、以下の同じ意味を持つコマンドのいずれかを入力します。
cdk list cdk ls
アプリケーションに CDK Pipelines スタックが含まれている場合、CDK CLI はパイプライン階層内の場所に応じてスタック名をパスとして表示します。(例: PipelineStack、PipelineStack/Prod、PipelineStack/Prod/MyService。)
アプリケーションに多くのスタックが含まれている場合は、一覧表示するスタックのスタック ID の全部または一部を指定できます。詳細については、「スタックを指定する」を参照してください。
--long フラグを追加して、スタック名とその環境 (AWS アカウントとリージョン) など、スタックに関する詳細情報を表示します。
スタックを合成する
cdk synthesize コマンド (ほぼ常に synth と省略) は、アプリで定義されたスタックを CloudFormation テンプレートに合成します。
cdk synth # if app contains only one stack cdk synth MyStack cdk synth Stack1 Stack2 cdk synth "*" # all stacks in app
注記
CDK CLI は実際にアプリケーションを実行し、ほとんどの操作 (スタックのデプロイ時や比較時など) の前に新しいテンプレートを合成します。これらのテンプレートは、デフォルトで cdk.out ディレクトリに保存されます。cdk synth コマンドは、1 つ以上の指定されたスタックに対して生成されたテンプレートを単に出力します。
使用可能なすべてのオプションについては、cdk synth --help を参照してください。最も頻繁に使用されるオプションのいくつかについて、次のセクションで説明します。
コンテキスト値を指定する
--context または -c オプションを使用して、ランタイムコンテキスト値を CDK アプリケーションに渡します。
# specify a single context value cdk synth --context key=value MyStack # specify multiple context values (any number) cdk synth --context key1=value1 --context key2=value2 MyStack
複数のスタックをデプロイする場合、指定されたコンテキスト値は通常、それらすべてに渡されます。必要に応じて、スタック名をコンテキスト値にプレフィックスすることで、スタックごとに異なる値を指定できます。
# different context values for each stack cdk synth --context Stack1:key=value Stack2:key=value Stack1 Stack2
表示形式を指定する
デフォルトでは、合成されたテンプレートは YAML 形式で表示されます。--json フラグを追加して、代わりに JSON 形式で表示します。
cdk synth --json MyStack
出力ディレクトリを指定する
--output (-o) オプションを追加して、合成されたテンプレートを cdk.out 以外のディレクトリに書き込みます。
cdk synth --output=~/templates
スタックをデプロイする
cdk deploy サブコマンドは、1 つ以上の指定されたスタックを AWS アカウントにデプロイします。
cdk deploy # if app contains only one stack cdk deploy MyStack cdk deploy Stack1 Stack2 cdk deploy "*" # all stacks in app
注記
CDK CLI は、デプロイを行う前に、アプリを実行して、新しい AWS CloudFormation テンプレートを合成します。したがって、cdk synth で使用できるほとんどのコマンドラインオプション (--context など) は、cdk deploy でも使用できます。
使用可能なすべてのオプションについては、cdk deploy --help を参照してください。以下のセクションでは、最も有用なオプションをいくつか説明します。
合成をスキップする
cdk deploy コマンドは通常、デプロイ前にアプリのスタックを合成し、デプロイにアプリの最新バージョンが反映されていることを確認します。前回の cdk synth 以降にコードを変更していないことがわかっている場合は、デプロイ時に冗長な合成の手順を抑えることができます。これを行うには、--app オプションでプロジェクトの cdk.out ディレクトリを指定します。
cdk deploy --app cdk.out StackOne StackTwo
ロールバックを無効にする
AWS CloudFormation には変更をロールバックする機能があるため、デプロイはアトミックになります。つまり、全体として成功するか失敗するかのいずれかになることを意味します。AWS CDK は AWS CloudFormation テンプレートを合成してデプロイするため、この機能を継承しています。
ロールバックは、リソースが常に一貫した状態であることを確認するため、本番稼働スタックにとって不可欠です。ただし、インフラストラクチャの開発中は、ある程度の障害が発生することは避けられず、失敗したデプロイをロールバックすることは、流れを損なう可能性があります。
このため、CDK CLI では、cdk deploy コマンドに --no-rollback を追加してロールバックを無効にすることができます。このフラグがあると、失敗したデプロイもロールバックされません。代わりに、障害が発生したリソースの前にデプロイされたリソースはそのまま残り、次のデプロイは障害が発生したリソースから始まります。デプロイを待つ時間が大幅に短縮され、インフラストラクチャの開発により多くの時間をかけられるようになります。
ホットスワップ
AWS CloudFormation の変更セットを生成してデプロイする代わりに、AWS リソースの直接更新を試みるには、cdk deploy に --hotswap フラグを使用します。ホットスワップが不可能な場合、デプロイは AWS CloudFormation デプロイに戻ります。
現在、ホットスワップは Lambda 関数、Step Functions ステートマシン、Amazon ECS コンテナイメージをサポートしています。また、--hotswap フラグはロールバックを無効にします (つまり,暗黙的に --no-rollback を指定します)。
重要
ホットスワップは、本番稼働環境のデプロイにはお勧めしません。
ウォッチモード
CDK CLI のウォッチモード (cdk deploy --watch または略して cdk watch) は、CDK アプリのソースファイルとアセットの変更を継続的にモニタリングします。変更が検出されると、指定されたスタックのデプロイがすぐに実行されます。
デフォルトでは、これらのデプロイは --hotswap フラグを使用します。フラグは、Lambda 関数への変更のデプロイを高速追跡します。また、インフラストラクチャの設定を変更した場合も、AWS CloudFormation を通したデプロイにフォールバックします。cdk watch が常に AWS CloudFormation のフルデプロイを実行するようにするには、--no-hotswap フラグを cdk watch に追加します。
cdk watch がデプロイを既に実行している間に変更が加えられた場合、それらは 1 つのデプロイにまとめられ、進行中のデプロイが完了次第開始されます。
ウォッチモードでは、モニタリングするファイルを決定するために、プロジェクトの cdk.json にある "watch" キーを使用します。デフォルトでは、これらのファイルはアプリケーションファイルおよびアセットですが、"watch" キーの "include" および "exclude" エントリを変更することで変更できます。cdk.json ファイルの内容の例を以下に示します。
{ "app": "mvn -e -q compile exec:java", "watch": { "include": "src/main/**", "exclude": "target/*" } }
cdk watch は cdk.json から "build" コマンドを実行して、合成前にアプリケーションを構築します。デプロイで Lambda コード (または CDK アプリにない他のもの) を構築またはパッケージ化するためのコマンドが必要な場合は、ここに追加します。
Git スタイルのワイルドカードは、* と ** の両方とも、"watch" キーと "build" キーで使用できます。各パスは、cdk.json の親ディレクトリに対して解釈されます。include のデフォルト値は **/* です。これはプロジェクトのルートディレクトリ内のすべてのファイルとディレクトリを意味します。exclude はオプションです。
重要
本番稼働環境のデプロイでは、監視モードはおすすめしません。
AWS CloudFormation パラメータを指定する
CDK CLI は、デプロイ時の AWS CloudFormation パラメータの指定をサポートしています。これらは、--parameters フラグの後のコマンドラインで指定できます。
cdk deploy MyStack --parameters uploadBucketName=UploadBucket
複数のパラメータを定義するには、複数の --parameters フラグを使用します。
cdk deploy MyStack --parameters uploadBucketName=UpBucket --parameters downloadBucketName=DownBucket
複数のスタックをデプロイする場合は、各スタックの各パラメータに異なる値を指定できます。そうするためには、パラメータの名前にスタック名とコロンをプレフィックスします。そうしなかった場合、すべてのスタックに同じ値が渡されます。
cdk deploy MyStack YourStack --parameters MyStack:uploadBucketName=UploadBucket --parameters YourStack:uploadBucketName=UpBucket
デフォルトでは、AWS CDK は以前のデプロイのパラメータの値を保持し、明示的に指定されていない場合は後のデプロイで使用します。すべてのパラメータを指定する必要がある場合は、--no-previous-parameters フラグを使用します。
出力ファイルを指定する
スタックが AWS CloudFormation 出力を宣言した場合、これらは通常デプロイの終了時に画面に表示されます。JSON 形式でファイルに書き込むには、--outputs-file フラグを使用します。
cdk deploy --outputs-file outputs.json MyStack
セキュリティ関連の変更を承認する
セキュリティ体制に影響する意図しない変更から保護するために、CDK CLI はセキュリティ関連の変更をデプロイする前に承認を求めるプロンプトを表示します。承認が必要な変更のレベルを指定することができます。
cdk deploy --require-approval <LEVEL>
<LEVEL> の値は次のいずれかを指定できます。
| 言葉 | 意味 |
|---|---|
|
|
承認は不要 |
|
|
IAM またはセキュリティグループ関連の変更には承認が必要です |
|
|
IAM ステートメントまたはトラフィックルールが追加されたときは承認が必要です。削除に承認は必要ありません。 |
設定は、cdk.json ファイルで設定することもできます。
{ "app": "...", "requireApproval": "never" }
スタックの比較
cdk diff コマンドは、アプリで定義されているスタックの最新バージョン (およびその依存関係) を、既にデプロイされているバージョン、または保存された AWS CloudFormation テンプレートと比較し、変更のリストを表示します。
Stack HelloCdkStack IAM Statement Changes ┌───┬──────────────────────────────┬────────┬──────────────────────────────┬──────────────────────────────┬───────────┐ │ │ Resource │ Effect │ Action │ Principal │ Condition │ ├───┼──────────────────────────────┼────────┼──────────────────────────────┼──────────────────────────────┼───────────┤ │ + │ ${Custom::S3AutoDeleteObject │ Allow │ sts:AssumeRole │ Service:lambda.amazonaws.com │ │ │ │ sCustomResourceProvider/Role │ │ │ │ │ │ │ .Arn} │ │ │ │ │ ├───┼──────────────────────────────┼────────┼──────────────────────────────┼──────────────────────────────┼───────────┤ │ + │ ${MyFirstBucket.Arn} │ Allow │ s3:DeleteObject* │ {aws}:${Custom::S3AutoDeleteOb │ │ │ │ ${MyFirstBucket.Arn}/* │ │ s3:GetBucket* │ jectsCustomResourceProvider/ │ │ │ │ │ │ s3:GetObject* │ Role.Arn} │ │ │ │ │ │ s3:List* │ │ │ └───┴──────────────────────────────┴────────┴──────────────────────────────┴──────────────────────────────┴───────────┘ IAM Policy Changes ┌───┬────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────┐ │ │ Resource │ Managed Policy ARN │ ├───┼────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────┤ │ + │ ${Custom::S3AutoDeleteObjectsCustomResourceProvider/Ro │ {"Fn::Sub":"arn:${{aws}::Partition}:iam::aws:policy/serv │ │ │ le} │ ice-role/AWSLambdaBasicExecutionRole"} │ └───┴────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────┘ (NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299) Parameters [+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/S3Bucket AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392S3BucketBF7A7F3F: {"Type":"String","Description":"S3 bucket for asset \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""} [+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/S3VersionKey AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392S3VersionKeyFAF93626: {"Type":"String","Description":"S3 key for asset version \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""} [+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/ArtifactHash AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392ArtifactHashE56CD69A: {"Type":"String","Description":"Artifact hash for asset \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""} Resources [+] {aws}::S3::BucketPolicy MyFirstBucket/Policy MyFirstBucketPolicy3243DEFD [+] Custom::S3AutoDeleteObjects MyFirstBucket/AutoDeleteObjectsCustomResource MyFirstBucketAutoDeleteObjectsCustomResourceC52FCF6E [+] {aws}::IAM::Role Custom::S3AutoDeleteObjectsCustomResourceProvider/Role CustomS3AutoDeleteObjectsCustomResourceProviderRole3B1BD092 [+] {aws}::Lambda::Function Custom::S3AutoDeleteObjectsCustomResourceProvider/Handler CustomS3AutoDeleteObjectsCustomResourceProviderHandler9D90184F [~] {aws}::S3::Bucket MyFirstBucket MyFirstBucketB8884501 ├─ [~] DeletionPolicy │ ├─ [-] Retain │ └─ [+] Delete └─ [~] UpdateReplacePolicy ├─ [-] Retain └─ [+] Delete
アプリのスタックを既存のデプロイと比較するには、以下を実行します。
cdk diff MyStack
アプリのスタックを保存された CloudFormation テンプレートと比較するには、以下を実行します。
cdk diff --template ~/stacks/MyStack.old MyStack
スタックへの既存リソースのインポート
cdk import コマンドを使用して、特定の AWS CDK スタックの CloudFormation の管理下にリソースを持ち込むことができます。これは、AWS CDK に移行する場合や、スタック間でリソースを移動する場合、または論理 ID を変更する場合に便利です。cdk import は「CloudFormation リソースインポート」を使用します。ここでインポートできるリソースのリストを参照してください。
既存のリソースを AWS CDK スタックにインポートするには、以下のステップに従います。
-
リソースが他の CloudFormation スタックによって現在管理されていないことを確認します。管理されている場合は、まずリソースが現在存在するスタックで、削除ポリシーを
RemovalPolicy.RETAINに設定し、デプロイを実行します。次に、スタックからリソースを削除し、別のデプロイを実行します。このプロセスにより、リソースが CloudFormation によって管理されなくなり、削除されなくなります。 -
cdk diffを実行して、リソースをインポートする AWS CDK スタックに保留中の変更がないことを確認します。「インポート」オペレーションで許可される変更は、インポートする新しいリソースの追加のみです。 -
スタックにインポートするリソースのコンストラクトを追加します。たとえば、Amazon S3 バケットをインポートする場合は、
new s3.Bucket(this, 'ImportedS3Bucket', {});のようなものを追加します。他のリソースに変更を加えないでください。また、リソースが現在持っている状態を定義に正確にモデル化することも確認する必要があります。バケットの例では、AWS KMS キー、ライフサイクルポリシー、その他バケットに関連するものすべてを含めるようにしてください。そうしないと、その後の更新操作が期待どおりに動作しない可能性があります。
物理バケット名を含めるかどうかを選択できます。通常、リソースを複数回デプロイしやすくするために、AWS CDK リソース定義にはリソース名を含めないことをおすすめします。
-
cdk import <STACKNAME>を実行します。 -
リソース名がモデルにない場合、CLI はインポートするリソースの実際の名前を渡すようにプロンプトを表示します。その後、インポートが開始されます。
-
cdk importが成功を報告すると、リソースは AWS CDK と CloudFormation によって管理されるようになります。AWS CDK アプリ内のリソースプロパティに加えたその後の変更は、次のデプロイでコンストラクト設定が適用されます。 -
AWS CDK アプリのリソース定義がリソースの現在の状態と一致することを確認するには、CloudFormation ドリフト検出操作を開始します。
この機能は現在、ネストされたスタックへのリソースのインポートをサポートしていません。
設定 (cdk.json)
多くの CDK CLI コマンドラインフラグのデフォルト値は、プロジェクトの cdk.json ファイルまたはユーザーディレクトリの .cdk.json ファイルに保存できます。以下は、サポートされている設定のアルファベット順のリファレンスです。
| キー | メモ | CDK CLI オプション |
|---|---|---|
|
|
CDK アプリケーションを実行するコマンド。 |
|
|
|
|
|
|
|
Amazon S3 デプロイバケットの暗号化に使用される AWS KMS キーの ID を上書きします。 |
|
|
|
合成前に CDK アプリケーションをコンパイルまたは構築するコマンド。 |
|
|
|
|
|
|
|
コンテキスト値と AWS CDK を参照してください。設定ファイルのコンテキスト値は、 |
|
|
|
|
|
|
|
新しいプロジェクトの初期化に使用される言語。 |
|
|
|
|
|
|
|
|
|
|
|
合成されたクラウドアセンブリが出力されるディレクトリの名前 (デフォルト |
|
|
|
デプロイされたスタックからの AWS CloudFormation 出力が書き込まれるファイル ( |
|
|
|
|
|
|
|
CDK を拡張するパッケージ名またはローカルパスを指定する JSON 配列 |
|
|
|
リージョンとアカウントの認証情報の指定に使用されるデフォルト AWS プロファイルの名前。 |
|
|
|
|
|
|
|
セキュリティ変更のデフォルトの承認レベル。「セキュリティ関連の変更を承認する」を参照してください。 |
|
|
|
|
|
|
|
|
|
|
|
スタックのタグ (キーと値のペア) を含む |
|
|
|
Lambda 関数やコンテナイメージなどのアセットのデプロイに使用される Amazon S3 バケットの名前 (「AWS 環境のブートストラップ」を参照)。 |
|
|
|
ブートストラップスタックの名前 (「AWS 環境のブートストラップ」を参照)。 |
|
|
|
|
|
|
|
変更時にプロジェクトの再構築をトリガーする (またはトリガーしない) ファイルを示す、 |
|