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

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

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

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

AWS 環境をブートストラップして、AWS Cloud Development Kit (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

AWS config および credentials ファイルに名前付きプロファイルがある場合は、--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 コマンドラインインターフェイス (AWS CLI) を使用することもできます。デプロイする前なら、テンプレートには変更を加えることができます。この方法はより柔軟であり、大規模なデプロイに適しています。

以下は、--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"
注記

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

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

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

AWS CLI を使用してテンプレートをデプロイする場合の例を以下に示します。

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 を使用して複数の環境をブートストラップする方法については、「AWS クラウド運用および移行ブログ」の「CloudFormation StackSets を使用する AWS CDK のための複数の 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 によって引き受けられます。

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

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 によって引き受けられます。

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

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

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

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

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

  • リージョン – 環境の 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 を介して暗黙的に設定されるようになり、FileAssetKeyArn が不要になりました。CdkBootstrapVersion 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

ssm:GetParameters アクションを AWS CloudFormation デプロイ IAM ロールに追加。詳細については、「#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」を参照してください。

レガシーから最新のブートストラップテンプレートへのアップグレード

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

機能 レガシー (v1 のみ) 最新 (v1 および v2)

クロスアカウントデプロイ

許可されていません

許可

AWS CloudFormation のアクセス許可

現在のユーザーのアクセス許可を使用してデプロイします (AWS プロファイル、環境変数などによって決まります)

ブートストラップスタックがプロビジョニングされたときに指定されたアクセス許可を使用してデプロイします (--trust など)

バージョニング

使用可能なブートストラップスタックのバージョンは 1 つだけです

ブートストラップスタックはバージョン管理されています。新しいリソースは将来のバージョンに追加でき、AWS CDK アプリには最小バージョンが必要になる場合があります。

リソース*

Amazon S3 バケット

  • Amazon S3 バケット

  • AWS KMS キー

  • IAM ロール

  • Amazon ECR リポジトリ

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

AWSKMS キー

IAM ロール

Amazon ECR リポジトリ

リソース名

自動的に生成される

確定的

バケットの暗号化

デフォルトキー。

デフォルトで AWS 管理キーになります。カスタマー管理キーを使用するようにカスタマイズできます。

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

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

Security Hub の検出結果への対応

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

[KMS.2] IAM プリンシパルは、すべての KMS キーで復号アクションを許可する IAM インラインポリシーを使用しないでください

デプロイロール (DeploymentActionRole) は、暗号化されたデータを読み取るアクセス許可を付与します。これは、CDK Pipelines でのクロスアカウントデプロイに必要です。このロールのポリシーは、すべてのデータにアクセス許可を付与しません。Amazon S3 と AWS KMS から暗号化されたデータを読み取るアクセス許可を付与するのは、それらのリソースがバケットまたはキーポリシーを通じてデータを許可する場合のみです。

以下は、ブートストラップテンプレートからのデプロイロール内のこれら 2 つのステートメントのスニペットです。

DeploymentActionRole: Type: AWS::IAM::Role Properties: ... Policies: - PolicyDocument: Statement: ... - Sid: PipelineCrossAccountArtifactsBucket Effect: Allow Action: - s3:GetObject* - s3:GetBucket* - s3:List* - s3:Abort* - s3:DeleteObject* - s3:PutObject* Resource: "*" Condition: StringNotEquals: s3:ResourceAccount: Ref: AWS::AccountId - Sid: PipelineCrossAccountArtifactsKey Effect: Allow Action: - kms:Decrypt - kms:DescribeKey - kms:Encrypt - kms:ReEncrypt* - kms:GenerateDataKey* Resource: "*" Condition: StringEquals: kms:ViaService: Fn::Sub: s3.${AWS::Region}.amazonaws.com ...
Security Hub がこれにフラグを付けるのはなぜですか?

ポリシーには、Resource: *Condition 節を組み合わせたものが含まれています。Security Hub は * ワイルドカードにフラグを付けます。このワイルドカードが使用されるのは、アカウントがブートストラップされた時点では、CodePipeline アーティファクトバケット用に CDK Pipelines によって作成される AWS KMS キーがまだ存在しないため、ブートストラップテンプレート内で ARN による参照ができないためです。さらに、Security Hub は、このフラグを提起する際に Condition 節を考慮しません。この Condition は、Resource: * を AWS KMS キーと同じ AWS アカウントから行われたリクエストに制限します。これらのリクエストは、AWS KMS キーと同じ AWS リージョン内の Amazon S3 から送信する必要があります。

この検出結果を修正する必要がありますか?

ブートストラップテンプレートの AWS KMS キーを過度に許容するように変更しない限り、デプロイロールは必要以上のアクセスを許可しません。したがって、この検出結果を修正する必要はありません。

この検出結果を修正する場合はどうすればよいですか?

この検出結果の修正方法は、クロスアカウントデプロイに CDK Pipelines を使用するかどうかによって異なります。

Security Hub の検出結果を修正し、クロスアカウントデプロイに CDK Pipelines を使用するには
  1. まだデプロイしていない場合は、cdk bootstrap コマンドを使用して CDK ブートストラップスタックをデプロイします。

  2. まだ作成していない場合は、CDK Pipeline を作成してデプロイします。手順については、「CDK Pipelines を使用した継続的インテグレーションと継続的デリバリー (CI/CD)」を参照してください。

  3. CodePipeline アーティファクトバケットの AWS KMS キーの ARN を取得します。このリソースはパイプラインの作成時に作成されます。

  4. CDK ブートストラップテンプレートのコピーを取得して変更します。AWS CDK CLI を使用した例を以下に示します。

    $ cdk bootstrap --show-template > bootstrap-template.yaml
  5. PipelineCrossAccountArtifactsKey ステートメントの Resource: * を ARN 値に置き換えて、テンプレートを変更します。

  6. テンプレートをデプロイしてブートストラップスタックを更新します。CDK CLI を使用した例を以下に示します。

    $ cdk bootstrap aws://<account-id>/<region> --template bootstrap-template.yaml
CDK Pipelines をクロスアカウントデプロイに使用していない場合に Security Hub の検出結果を修正するには
  1. CDK ブートストラップテンプレートのコピーを取得して変更します。CDK CLI を使用した例を以下に示します。

    $ cdk bootstrap --show-template > bootstrap-template.yaml
  2. テンプレートから PipelineCrossAccountArtifactsBucket および PipelineCrossAccountArtifactsKey ステートメントを削除します。

  3. テンプレートをデプロイしてブートストラップスタックを更新します。CDK CLI を使用した例を以下に示します。

    $ cdk bootstrap aws://<account-id>/<region> --template bootstrap-template.yaml

考慮事項

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