AWS CDK で使用する環境をブートストラップする - AWS クラウド開発キット (AWS CDK) v2

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

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

AWS CDK で使用する環境をブートストラップする

AWS 環境をブートストラップして、 AWS クラウド開発キット (AWS CDK) スタックのデプロイに備えます。

環境をブートストラップする方法

AWS CDK コマンドラインインターフェイス (AWS CDK CLI) または任意の AWS CloudFormation デプロイツールを使用して、環境をブートストラップできます。

CDK CLI を使用する

CDK CLI の cdk bootstrap コマンドを使用して、環境をブートストラップできます。これは、ブートストラップに大幅な変更が必要ない場合に推奨される方法です。

任意の作業ディレクトリからのブートストラップ

作業ディレクトリからブートストラップするには、ブートストラップする環境をコマンドライン引数として指定します。以下に例を示します。

$ cdk bootstrap <aws://123456789012/us-east-1>
ヒント

AWS アカウント番号がない場合は、 AWS マネジメントコンソールから取得できます。次の AWS CLI コマンドを使用して、アカウント番号を含むデフォルトのアカウント情報を表示することもできます。

$ aws sts get-caller-identity

config および credentials ファイルに名前付き AWS プロファイルがある場合は、 --profileオプションを使用して特定のプロファイルのアカウント情報を取得します。以下に例を示します。

$ aws sts get-caller-identity --profile <prod>

デフォルトのリージョンを表示するには、aws configure get コマンドを使用します。

$ aws configure get region $ aws configure get region --profile <prod>

引数を指定する場合、aws:// プレフィックスは任意です。以下は有効になります。

$ cdk bootstrap <123456789012/us-east-1>

複数の環境を同時にブートストラップするには、複数の引数を指定します。

$ cdk bootstrap <aws://123456789012/us-east-1> <aws://123456789012/us-east-2>
CDK プロジェクトの親ディレクトリからのブートストラップ

cdk.json ファイルを含む CDK プロジェクトの親ディレクトリから cdk bootstrap を実行できます。環境を引数として指定しない場合、CDK CLI は、config および credentials ファイルまたは CDK スタックに指定された環境情報などのデフォルトのソースから環境情報を取得します。

CDK プロジェクトの親ディレクトリからブートストラップする場合、コマンドライン引数から提供される環境が他のソースよりも優先されます。

config および credentials ファイルで指定された環境をブートストラップするには、--profile オプションを使用します。

$ cdk bootstrap --profile <prod>

cdk bootstrap コマンドおよびサポートされているオプションの詳細については、「cdk ブートストラップ」を参照してください。

任意の AWS CloudFormation ツールを使用する

ブートストラップテンプレートaws-cdk-cli GitHub リポジトリからコピーするか、cdk bootstrap --show-template コマンドを使用してテンプレートを取得できます。次に、任意の AWS CloudFormation ツールを使用してテンプレートを環境にデプロイします。

この方法では、 AWS CloudFormation StackSets または AWS Control Tower を使用できます。 AWS CloudFormation コンソールまたは コマンドラインインターフェイス (AWS CLI) AWS を使用することもできます。デプロイする前なら、テンプレートには変更を加えることができます。この方法はより柔軟であり、大規模なデプロイに適しています。

以下は、--show-template オプションを使用してブートストラップテンプレートを取得し、ローカルマシンに保存する方法の例です。

macOS/Linux
$ cdk bootstrap --show-template > bootstrap-template.yaml
Windows

Windows では、テンプレートのエンコーディングを保持するために、PowerShell を使用する必要があります。

powershell "cdk bootstrap --show-template | Out-File -encoding utf8 bootstrap-template.yaml"
注記

CDK 通知が AWS CloudFormation テンプレート出力に表示されている場合は、 コマンドで --no-noticesオプションを指定します。

CDK CLI を使用してこのテンプレートをデプロイするには、以下を実行します。

$ cdk bootstrap --template <bootstrap-template.yaml>

CLI AWS を使用してテンプレートをデプロイする例を次に示します。

macOS/Linux
aws cloudformation create-stack \ --stack-name CDKToolkit \ --template-body file://<path/to/>bootstrap-template.yaml \ --capabilities CAPABILITY_NAMED_IAM \ --region <us-west-1>
Windows
aws cloudformation create-stack ^ --stack-name CDKToolkit ^ --template-body file://<path/to/>bootstrap-template.yaml ^ --capabilities CAPABILITY_NAMED_IAM ^ --region <us-west-1>

CloudFormation StackSets を使用して複数の環境をブートストラップする方法については、 クラウドオペレーションと移行ブログのCloudFormation StackSets を使用した AWS CDK の複数の AWS アカウントのブートストラップ」を参照してください。 AWS

環境をブートストラップするタイミング

AWS 環境にデプロイする前に、各環境をブートストラップする必要があります。使用する予定の各環境を事前にブートストラップすることをおすすめします。これは、CDK アプリケーションを環境に実際にデプロイする前に実行できます。環境を事前にブートストラップすることで、Amazon S3 バケット名の競合やブートストラップされていない環境に CDK アプリをデプロイするなどの潜在的な将来の問題を防止できます。

環境を複数回ブートストラップしても問題ありません。環境がすでにブートストラップされている場合、必要に応じてブートストラップスタックがアップグレードされます。該当しない場合は、何も起こりません。

ブートストラップされていない環境に CDK スタックをデプロイしようとすると、以下のようなエラーが表示されます。

$ cdk deploy ✨ Synthesis time: 2.02s ❌ Deployment failed: Error: BootstrapExampleStack: 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)
ブートストラップスタックを更新する

CDK チームは定期的にブートストラップテンプレートを新しいバージョンに更新します。この場合、ブートストラップスタックを更新することをおすすめします。ブートストラッププロセスをカスタマイズしていない場合は、最初に環境をブートストラップするために実行したのと同じ手順に従って、ブートストラップスタックを更新できます。詳細については、「ブートストラップテンプレートのバージョン履歴」を参照してください。

ブートストラップ中に作成されたデフォルトのリソース

ブートストラップ中に作成された IAM ロール

デフォルトでは、ブートストラップは環境に次の AWS Identity and Access Management (IAM) ロールをプロビジョニングします。

  • CloudFormationExecutionRole

  • DeploymentActionRole

  • FilePublishingRole

  • ImagePublishingRole

  • LookupRole

CloudFormationExecutionRole

この IAM ロールは、ユーザーに代わってスタックデプロイを実行するアクセス許可を CloudFormation に付与する CloudFormation サービスロールです。このロールは、スタックのデプロイなど、アカウントで AWS API コールを実行するアクセス許可を CloudFormation に付与します。

サービスロールを使用することで、サービスロールにプロビジョニングされたアクセス許可によって、CloudFormation リソースに対して実行できるアクションが決まります。このサービスロールがない場合、CDK CLI で提供するセキュリティ認証情報によって、CloudFormation が実行できることが決まります。

DeploymentActionRole

この IAM ロールは、環境へのデプロイを実行するアクセス許可を付与します。これは、デプロイ中に CDK CLI によって引き受けられます。

ロールをデプロイに使用すると、ロールを別のアカウントの ID AWS が引き受けることができるため、クロスアカウントデプロイを実行できます。

FilePublishingRole

この IAM ロールは、アセットのアップロードや削除など、ブートストラップされた Amazon Simple Storage Service (Amazon S3) バケットに対してアクションを実行するアクセス許可を付与します。これは、デプロイ中に CDK CLI によって引き受けられます。

ImagePublishingRole

この IAM ロールは、ブートストラップされた Amazon Elastic Container Registry (Amazon ECR) リポジトリに対してアクションを実行するアクセス許可を付与します。これは、デプロイ中に CDK CLI によって引き受けられます。

LookupRole

この IAM ロールは、 AWS 環境からコンテキスト値を検索するreadOnlyアクセス許可を付与します。テンプレート合成やデプロイなどのタスクを実行する場合、CDK CLI によって引き受けられます。

ブートストラップ中に作成されたリソース IDs

デフォルトのブートストラップテンプレートをデプロイすると、ブートストラップのリソースの ID は、cdk-<qualifier>-<description>-<account-ID>-<Region> という構造を用いて作成されます。

  • 修飾子hnb659fds などの、9 文字の一意の文字列値。実際の値に意味はありません。

  • 説明 – リソースの簡単な説明。例えば、container-assets

  • アカウント ID – 環境の AWS アカウント ID。

  • Region – 環境の AWS リージョン。

ブートストラップ中に作成された Amazon S3 ステージングバケットの物理 ID の例を次に示します。 cdk-hnb659fds-assets-012345678910-us-west-1

環境のブートストラップに使用するアクセス許可

AWS 環境をブートストラップする場合、ブートストラップを実行する IAM ID には、少なくとも次のアクセス許可が必要です。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*", "ecr:*", "ssm:*", "s3:*", "iam:*" ], "Resource": "*" } ] }

時間の経過とともに、作成されるリソースや必要なアクセス許可を含むブートストラップスタックが変わる可能性があります。今後の変更では、環境のブートストラップに必要なアクセス許可を変更する必要がある場合があります。

ブートストラップをカスタマイズする

デフォルトのブートストラップテンプレートがニーズに合わない場合は、次の方法で環境へのリソースのブートストラップをカスタマイズできます。

  • cdk bootstrap コマンドでコマンドラインオプションを使用する — この方法は、コマンドラインオプションでサポートされる、小規模で具体的な変更を行うのに最適です。

  • デフォルトのブートストラップテンプレートを変更してデプロイする – この方法は、複雑な変更を行う場合や、ブートストラップ中にプロビジョニングされたリソースの設定を完全に制御したい場合に最適です。

ブートストラップのカスタマイズの詳細については、AWS 「CDK ブートストラップのカスタマイズ」を参照してください。

CDK Pipelines を使用したブートストラップ

CDK Pipelines を使用して別のアカウントの環境にデプロイしている場合、以下のようなメッセージが表示されます。

Policy contains a statement with one or more invalid principals

このエラーメッセージは、他の環境に適切な IAM ロールが存在しないことを意味します。最も可能性の高い原因は、環境がブートストラップされていないことです。環境をブートストラップして、再試行してください。

ブートストラップスタックの削除からの保護

ブートストラップスタックが削除されると、CDK デプロイをサポートするために環境に最初にプロビジョニングされた AWS リソースも削除されます。これにより、パイプラインの動作が停止します。これが起きると、復旧のための一般的なソリューションはありません。

環境がブートストラップされた後は、環境のブートストラップスタックの削除と再作成は行わないでください。代わりに、cdk bootstrap コマンドを再度実行して、ブートストラップスタックを新しいバージョンに更新してみてください。

ブートストラップスタックが誤って削除されないように保護するには、終了保護を有効にする --termination-protection オプションに cdk bootstrap コマンドを指定することをおすすめします。新規または既存のブートストラップスタックで終了保護を有効にすることができます。終了保護を有効にする手順については、「ブートストラップスタックの終了保護を有効にする」を参照してください。

ブートストラップテンプレートのバージョン履歴

ブートストラップテンプレートはバージョニングされ、 AWS CDK 自体とともに時間の経過とともに進化します。独自のブートストラップテンプレートを指定する場合は、正規のデフォルトテンプレートを使用して最新の状態を維持します。テンプレートがすべての CDK 機能と引き続き連携するようにする必要があります。

注記

以前のバージョンのブートストラップテンプレートでは、デフォルトでブートストラップされた各環境に AWS KMS キーが作成されました。KMS キーによる料金を回避するには、--no-bootstrap-customer-key を使用しつつこれらの環境を再起動します。現在のデフォルトは KMS キーなしになっているため、これらの料金は発生しません。

このセクションには、各バージョンで行われた変更の一覧が表示されます。

[テンプレートのバージョン] AWS CDK バージョン 変更

1

1.40.0

バケット、キー、リポジトリ、ロールを含むテンプレートの初期バージョン。

2

1.45.0

アセット発行ロールをファイル発行ロールとイメージ発行ロールに分割。

3

1.46.0

アセットコンシューマーに復号アクセス許可を追加できるように FileAssetKeyArn エクスポートを追加。

4

1.61.0

AWS KMS アクセス許可は Amazon S3 経由で暗黙的になり、 が不要になりましたFileAssetKeyArnCdkBootstrapVersion SSM パラメータを追加し、スタック名を知らなくてもブートストラップスタックのバージョン検証が可能に。

5

1.87.0

デプロイロールが SSM パラメータを読み取り可能に。

6

1.108.0

デプロイロールとは別にルックアップロールを追加。

6

1.109.0

デプロイ、ファイル発行、およびイメージ発行ロールに aws-cdk:bootstrap-role タグをアタッチ。

7

1.110.0

デプロイロールがターゲットアカウントのバケットを直接読み取れないように変更。(ただし、このロールは実質的に管理者であり、いつでも AWS CloudFormation アクセス許可を使用してバケットを読み取り可能にできます)。

8

1.114.0

ルックアップロールにターゲット環境への完全な読み取り専用アクセス許可を付与し、aws-cdk:bootstrap-role タグも追加。

9

2.1.0

一般的に参照される暗号化 SCP によって Amazon S3 アセットのアップロードが拒否される問題を修正。

10

2.4.0

Amazon ECR ScanOnPush がデフォルトで有効。

11

2.18.0

再ブートストラップ後も維持されるように、Lambda が Amazon ECR リポジトリからプルすることを許可するポリシーを追加。

12

2.20.0

実験的な cdk import のサポートを追加。

13

2.25.0

ブートストラップで作成された Amazon ECR リポジトリ内のコンテナイメージを不変に設定。

14

2.34.0

イメージスキャンをサポートしていないリージョンでのブートストラップを可能にするために、リポジトリレベルでの Amazon ECR イメージスキャンをデフォルトで無効化。

15

2.60.0

KMS キーへのタグ付けを禁止。

16

2.69.0

Security Hub の検出結果 KMS.2 に対処。

17

2.72.0

Security Hub の検出結果 ECR.3 に対処。

18

2.80.0

全てのパーティションで動作せず、推奨もされないため、バージョン 16 での変更を取り消し。

19

2.106.1

AccessControl プロパティがテンプレートから削除されたバージョン 18 での変更を取り消し。(#27964)

20

2.119.0

AWS CloudFormation デプロイ IAM ロールにssm:GetParametersアクションを追加します。詳細については、「#28336」を参照してください。.

21

2.149.0

ファイル発行ロールに条件を追加。

22

2.160.0

ブートストラップ IAM ロールの信頼ポリシーに sts:TagSession のアクセス許可を追加。

23

2.161.0

デプロイ IAM ロールの信頼ポリシーに cloudformation:RollbackStack および cloudformation:ContinueUpdateRollback のアクセス許可を追加。これにより、cdk rollback コマンドのアクセス許可を提供。

24

2.165.0

ブートストラップバケット内の最新以外のオブジェクトを保持する日数を 365 日から 30 日に変更します。新しい cdk gc コマンドではブートストラップバケット内のオブジェクトを削除する機能が導入されるため、この新しい動作により、削除されたオブジェクトは 365 日ではなく 30 日間ブートストラップバケットに残るようになります。この変更の詳細については、「aws-cdk PR #31949」を参照してください。

25

2.165.0

未完了のマルチパートアップロードを削除するためのサポートをブートストラップバケットに追加します。未完了のマルチパートアップロードは 1 日後に削除されます。この変更の詳細については、「aws-cdk PR #31956」を参照してください。

26

2.1002.0

2 つの削除関連ポリシーを (UpdateReplacePolicy および DeletionPolicyFileAssetsBucketEncryptionKey) リソースに追加します。これらのポリシーにより、ブートストラップスタックが更新または削除されたときに、古い AWS KMS キーリソースが適切に削除されます。この変更の詳細については、「aws-cdk-cli PR #100」を参照してください。

27

2.1003.0

コンテナイメージを取得するための特定のアクセス許可を Amazon EMR Serverless に付与するために、新しい Amazon ECR リソースポリシーを追加します。この変更の詳細については、「aws-cdk-cli PR #112」を参照してください。

28

2.1015.0

スタックリファクタリングアクションを実行するアクセス許可をデプロイロールに追加し、TagSession アクセス許可をすべてのロールに追加します。この変更の詳細については、aws-cdk-cli「PR #471」を参照してください。

29

2.1026.0

ExternalId を提供するすべての AssumeRole 呼び出しは、無効になっていない限り、デフォルトで拒否されます。この変更の詳細については、aws-cdk-cli「PR #811」を参照してください。

30

2.1034.0

CloudFormation の早期検証エラーを正確に表示できるように、デプロイロールにスタックイベントを記述するアクセス許可を追加します。この変更の詳細については、aws-cdk-cli「PR #970」を参照してください。

[#bootstrapping-template] == レガシーから最新のブートストラップテンプレートへのアップグレード

AWS CDK v1 は、レガシーとモダンの 2 つのブートストラップテンプレートをサポートしました。CDK v2 は、最新のテンプレートのみをサポートします。参考として、これら 2 つのテンプレートの大まかな違いを以下に示します。

[cols"1h,1,1", options"header"]

| 機能 | レガシー (v1 のみ) | モダン (v1 および v2)

|クロスアカウントデプロイ |許可なし |許可

|AWS CloudFormation のアクセス許可 |現在のユーザーのアクセス許可を使用してデプロイします ( AWS プロファイル、環境変数などによって決まります) |ブートストラップスタックがプロビジョニングされたときに指定されたアクセス許可を使用してデプロイします (たとえば、 を使用--trust)

|バージョニング | 利用可能なブートストラップスタックのバージョンは 1 つだけ | ブートストラップスタックはバージョニングされています。将来のバージョンで新しいリソースを追加でき、 AWS CDK アプリには最小バージョンが必要になる場合があります

|リソース* |Amazon S3 バケット a|

  • Amazon S3 バケット

  • AWS KMS キー

  • IAM ロール

  • Amazon ECR リポジトリ

  • バージョニングの SSM パラメータ

|AWS KMS キー |IAM ロール |Amazon ECR リポジトリ

|リソースの命名 |自動生成 |決定論的

|バケット暗号化 |デフォルトキー |AWS マネージドキー。カスタマー管理キーを使用するようにカスタマイズできます。

*クロスアカウントデプロイに CDK Pipelines を使用していない場合に Security Hub の検出結果を修正するには

:::: + . Obtain a copy of the CDK bootstrap template to modify it. The following is an example, using the CDK CLI: + [source,bash,subs="verbatim,attributes"] ---- $ cdk bootstrap --show-template bootstrap-template.yaml ---- . Delete the PipelineCrossAccountArtifactsBucket and PipelineCrossAccountArtifactsKey statements from the template. . Deploy the template to update your bootstrap stack. The following is an example, using the CDK CLI: + [source,bash,subs="verbatim,attributes"] ---- $ cdk bootstrap aws://account-id/region --template bootstrap-template.yaml ----

[#bootstrapping-env-considerations] == 考慮事項

ブートストラップは環境内のリソースをプロビジョニングするため、これらのリソースを AWS CDK で使用すると AWS 料金が発生する可能性があります。

* 必要に応じてブートストラップテンプレートに追加リソースを追加します。

レガシーテンプレートを使用してブートストラップされた環境は、再起動によって CDK v2 の最新のテンプレートを使用するようにアップグレードする必要があります。レガシーバケットを削除する前に、環境にすべての AWS CDK アプリケーションを少なくとも 1 回再デプロイします。

[#bootstrapping-securityhub] == Security Hub の検出結果に対処する

AWS Security Hub を使用している場合は、 AWS CDK ブートストラッププロセスによって作成された一部のリソースで結果が報告される場合があります。Security Hub の検出結果は、精度と安全性を再確認する必要があるリソース設定を見つけるのに役立ちます。これらの特定のリソース設定は AWS Security で確認済みであり、セキュリティ上の問題にはならないと確信しています。

[#bootstrapping-securityhub-kms2] [KMS.2] IAM プリンシパルは、すべての KMS キーで復号アクションを許可する IAM インラインポリシーを持つべきではありません:: + デプロイロール (DeploymentActionRole) は、暗号化されたデータを読み取るアクセス許可を付与します。これは、CDK Pipelines を使用したクロスアカウントデプロイに必要です。このロールのポリシーは、すべてのデータにアクセス許可を付与しません。Amazon S3 および AWS KMS から暗号化されたデータを読み取るアクセス許可を付与するのは、それらのリソースがバケットまたはキーポリシーを通じて許可する場合のみです。+ ブートストラップテンプレートからのデプロイロール内のこれら 2 つのステートメントのスニペットを次に示します。 + [ソース、yaml、subs"逐語的に、attributes"] ---- DeploymentActionRole: タイプ: AWS:IAM::Role プロパティ: ... ポリシー: - PolicyDocument: ステートメント: ... - 中: PipelineCrossAccountArtifactsBucket の効果: アクションを許可する: - s3:GetObject* - s3:GetBucket* - s3:List* - s3:Abort* - s3:DeleteObject* - s3:PutObject* リソース: 「」条件: StringNotEquals: s3:ResourceAccount: Ref: AWS:AccountId - Sid: PipelineCrossAccountArtifactsKey 効果: アクションを許可する: - kms:Decrypt - kms:DescribeKey - kms:Encrypt - kms:ReEncrypt - kms:GenerateDataKey* リソース: 「」条件: StringEquals: kms:ViaService: Fn::Sub: s3.${AWS::Region}.amazonaws.com ... ---- + [#bootstrapping-securityhub-kms2-why] *Security Hub がこれにフラグを付ける理由::: + ポリシーには、 ConditionResource: *句を組み合わせた が含まれます。Security Hub は * ワイルドカードにフラグを付けます。このワイルドカードは、アカウントがブートストラップされた時点で、CodePipeline AWS アーティファクトバケットの CDK Pipelines によって作成された KMS キーがまだ存在しないため、ARN によってブートストラップテンプレートで参照できないために使用されます。さらに、Security Hub は、このフラグを提起する際に Condition 節を考慮しません。これにより、KMS AWS キーの同じ AWS アカウントから行われたResource: リクエストConditionに制限されます。これらのリクエストは、KMS キーと同じ AWS リージョンの Amazon S3 AWS から送信する必要があります。+ [#bootstrapping-securityhub-kms2-decide] *この検出結果を修正する必要がありますか?

::: + ブートストラップテンプレートの AWS KMS キーを過度に許容するように変更していない限り、デプロイロールは必要以上のアクセスを許可しません。したがって、この検出結果を修正する必要はありません。+ [#bootstrapping-securityhub-kms2-fix] この検出結果を修正するにはどうすればよいですか?:: + この検出結果の修正方法は、クロスアカウントデプロイに CDK Pipelines を使用するかどうかによって異なります。+ Security Hub の検出結果を修正し、クロスアカウントデプロイに CDK Pipelines を使用するには:::: + 。まだ行っていない場合は、 cdk bootstrap コマンドを使用して CDK ブートストラップスタックをデプロイします。まだ作成していない場合は、CDK Pipeline を作成してデプロイします。手順については、「CDK Pipelines を使用した継続的な統合と配信 (CI/CD)」を参照してください。CodePipeline アーティファクトバケットの AWS KMS キー ARN を取得します。このリソースは、パイプラインの作成時に作成されます。CDK ブートストラップテンプレートのコピーを取得して変更します。 AWS CDK CLI を使用した例を次に示します。+ [source,bash,subs"verbatim,attributes"] ---- $ cdk bootstrap --show-template bootstrap-template.yaml ---- 。Resource: PipelineCrossAccountArtifactsKey ステートメントを ARN 値に置き換えて、テンプレートを変更します。テンプレートをデプロイしてブートストラップスタックを更新します。CDK CLI を使用した例: + [source,bash,subs"verbatim,attributes"] ---- $ cdk bootstrap aws://account-id/region --template bootstrap-template.yaml ---- +