これは AWS CDK v2 デベロッパーガイドです。旧版の CDK v1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。 翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS CDK で使用する環境をブートストラップする AWS 環境をブートストラップして、 AWS クラウド開発キット (AWS CDK) スタックのデプロイに備えます。 + 環境の概要については、[AWS 「CDK の環境](environments.md)」を参照してください。 + ブートストラップの概要については、「[AWS CDK ブートストラップ](bootstrapping.md)」を参照してください。 ## 環境をブートストラップする方法 AWS CDK コマンドラインインターフェイス (AWS CDK CLI) または任意の AWS CloudFormation デプロイツールを使用して、環境をブートストラップできます。 **CDK CLI を使用する** CDK CLI の `cdk bootstrap` コマンドを使用して、環境をブートストラップできます。これは、ブートストラップに大幅な変更が必要ない場合に推奨される方法です。 **任意の作業ディレクトリからのブートストラップ** 作業ディレクトリからブートストラップするには、ブートストラップする環境をコマンドライン引数として指定します。以下に例を示します。 ``` $ cdk bootstrap ``` AWS アカウント番号がない場合は、 AWS マネジメントコンソールから取得できます。次の AWS CLI コマンドを使用して、アカウント番号を含むデフォルトのアカウント情報を表示することもできます。 ``` $ aws sts get-caller-identity ``` `config` および `credentials` ファイルに名前付き AWS プロファイルがある場合は、 `--profile`オプションを使用して特定のプロファイルのアカウント情報を取得します。以下に例を示します。 ``` $ aws sts get-caller-identity --profile ``` デフォルトのリージョンを表示するには、`aws configure get` コマンドを使用します。 ``` $ aws configure get region $ aws configure get region --profile ``` 引数を指定する場合、`aws://` プレフィックスは任意です。以下は有効になります。 ``` $ cdk bootstrap <123456789012/us-east-1> ``` 複数の環境を同時にブートストラップするには、複数の引数を指定します。 ``` $ cdk bootstrap ``` **CDK プロジェクトの親ディレクトリからのブートストラップ** `cdk.json` ファイルを含む CDK プロジェクトの親ディレクトリから `cdk bootstrap` を実行できます。環境を引数として指定しない場合、CDK CLI は、`config` および `credentials` ファイルまたは CDK スタックに指定された環境情報などのデフォルトのソースから環境情報を取得します。 CDK プロジェクトの親ディレクトリからブートストラップする場合、コマンドライン引数から提供される環境が他のソースよりも優先されます。 `config` および `credentials` ファイルで指定された環境をブートストラップするには、`--profile` オプションを使用します。 ``` $ cdk bootstrap --profile ``` `cdk bootstrap` コマンドおよびサポートされているオプションの詳細については、「[cdk ブートストラップ](ref-cli-cmd-bootstrap.md)」を参照してください。 **任意の AWS CloudFormation ツールを使用する** [ブートストラップテンプレート](https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml)を *aws-cdk-cli GitHub リポジトリ*からコピーするか、`cdk bootstrap --show-template` コマンドを使用してテンプレートを取得できます。次に、任意の AWS CloudFormation ツールを使用してテンプレートを環境にデプロイします。 この方法では、 AWS CloudFormation StackSets または AWS Control Tower を使用できます。 AWS CloudFormation コンソールまたは コマンドラインインターフェイス (AWS CLI) AWS を使用することもできます。デプロイする前なら、テンプレートには変更を加えることができます。この方法はより柔軟であり、大規模なデプロイに適しています。 以下は、`--show-template` オプションを使用してブートストラップテンプレートを取得し、ローカルマシンに保存する方法の例です。 **Example** ``` $ cdk bootstrap --show-template > bootstrap-template.yaml ``` Windows では、テンプレートのエンコーディングを保持するために、PowerShell を使用する必要があります。 ``` powershell "cdk bootstrap --show-template | Out-File -encoding utf8 bootstrap-template.yaml" ``` CDK 通知が AWS CloudFormation テンプレート出力に表示されている場合は、 コマンドで `--no-notices`オプションを指定します。 CDK CLI を使用してこのテンプレートをデプロイするには、以下を実行します。 ``` $ cdk bootstrap --template ``` CLI AWS を使用してテンプレートをデプロイする例を次に示します。 **Example** ``` aws cloudformation create-stack \ --stack-name CDKToolkit \ --template-body file://bootstrap-template.yaml \ --capabilities CAPABILITY_NAMED_IAM \ --region ``` ``` aws cloudformation create-stack ^ --stack-name CDKToolkit ^ --template-body file://bootstrap-template.yaml ^ --capabilities CAPABILITY_NAMED_IAM ^ --region ``` CloudFormation StackSets を使用して複数の環境をブートストラップする方法については、 クラウドオペレーションと移行ブログの[CloudFormation StackSets を使用した AWS CDK の複数の AWS アカウントのブートストラップ](https://aws.amazon.com/blogs/mt/bootstrapping-multiple-aws-accounts-for-aws-cdk-using-cloudformation-stacksets/)」を参照してください。 * 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 チームは定期的にブートストラップテンプレートを新しいバージョンに更新します。この場合、ブートストラップスタックを更新することをおすすめします。ブートストラッププロセスをカスタマイズしていない場合は、最初に環境をブートストラップするために実行したのと同じ手順に従って、ブートストラップスタックを更新できます。詳細については、「[ブートストラップテンプレートのバージョン履歴](#bootstrap-template-history)」を参照してください。 ## ブートストラップ中に作成されたデフォルトのリソース **ブートストラップ中に作成された 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 環境から[コンテキスト値](context.md)を検索する`readOnly`アクセス許可を付与します。テンプレート合成やデプロイなどのタスクを実行する場合、CDK CLI によって引き受けられます。 **ブートストラップ中に作成されたリソース IDs ** デフォルトのブートストラップテンプレートをデプロイすると、ブートストラップのリソースの ID は、`cdk----` という構造を用いて作成されます。 + **修飾子** – `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 ブートストラップのカスタマイズ](bootstrapping-customizing.md)」を参照してください。 ## CDK Pipelines を使用したブートストラップ CDK Pipelines を使用して別のアカウントの環境にデプロイしている場合、以下のようなメッセージが表示されます。 ``` Policy contains a statement with one or more invalid principals ``` このエラーメッセージは、他の環境に適切な IAM ロールが存在しないことを意味します。最も可能性の高い原因は、環境がブートストラップされていないことです。環境をブートストラップして、再試行してください。 **ブートストラップスタックの削除からの保護** ブートストラップスタックが削除されると、CDK デプロイをサポートするために環境で最初にプロビジョニングされた AWS リソースも削除されます。これにより、パイプラインの動作が停止します。これが起きると、復旧のための一般的なソリューションはありません。 環境がブートストラップされた後は、環境のブートストラップスタックの削除と再作成は行わないでください。代わりに、`cdk bootstrap` コマンドを再度実行して、ブートストラップスタックを新しいバージョンに更新してみてください。 ブートストラップスタックが誤って削除されないように保護するには、終了保護を有効にする `--termination-protection` オプションに `cdk bootstrap` コマンドを指定することをおすすめします。新規または既存のブートストラップスタックで終了保護を有効にすることができます。終了保護を有効にする手順については、[「ブートストラップスタックの終了保護を有効にする」](bootstrapping-customizing.md#bootstrapping-customizing-cli-protection)を参照してください。 ## ブートストラップテンプレートのバージョン履歴 ブートストラップテンプレートはバージョニングされ、 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](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html#kms-2) に対処。 | | **17** | 2.72.0 | Security Hub の検出結果 [ECR.3](https://docs.aws.amazon.com/securityhub/latest/userguide/ecr-controls.html#ecr-3) に対処。 | | **18** | 2.80.0 | 全てのパーティションで動作せず、推奨もされないため、バージョン 16 での変更を取り消し。 | | **19** | 2.106.1 | AccessControl プロパティがテンプレートから削除されたバージョン 18 での変更を取り消し。([\$127964](https://github.com/aws/aws-cdk/issues/27964)) | | **20** | 2.119.0 | AWS CloudFormation デプロイ IAM ロールに`ssm:GetParameters`アクションを追加します。詳細については、[「\$128336」](https://github.com/aws/aws-cdk/pull/28336/files#diff-4fdac38426c4747aa17d515b01af4994d3d2f12c34f7b6655f24328259beb7bf)を参照してください。. | | **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 [\$131949](https://github.com/aws/aws-cdk/pull/31949)」を参照してください。 | | **25** | 2.165.0 | 未完了のマルチパートアップロードを削除するためのサポートをブートストラップバケットに追加します。未完了のマルチパートアップロードは 1 日後に削除されます。この変更の詳細については、「`aws-cdk` PR [\$131956](https://github.com/aws/aws-cdk/pull/31956)」を参照してください。 | | **26** | 2.1002.0 | 2 つの削除関連ポリシーを (`UpdateReplacePolicy` および `DeletionPolicy` を `FileAssetsBucketEncryptionKey`) リソースに追加します。これらのポリシーにより、ブートストラップスタックが更新または削除されたときに、古い AWS KMS キーリソースが適切に削除されます。この変更の詳細については、「`aws-cdk-cli` PR [\$1100](https://github.com/aws/aws-cdk-cli/pull/100)」を参照してください。 | | **27** | 2.1003.0 | コンテナイメージを取得するための特定のアクセス許可を Amazon EMR Serverless に付与するために、新しい Amazon ECR リソースポリシーを追加します。この変更の詳細については、「`aws-cdk-cli` PR [\$1112](https://github.com/aws/aws-cdk-cli/pull/112)」を参照してください。 | | **28** | 2.1015.0 | スタックリファクタリングアクションを実行するアクセス許可をデプロイロールに追加し、TagSession アクセス許可をすべてのロールに追加します。この変更の詳細については、`aws-cdk-cli`「PR [\$1471](https://github.com/aws/aws-cdk-cli/pull/471)」を参照してください。 | | **29** | 2.1026.0 | ExternalId を提供するすべての AssumeRole 呼び出しは、無効になっていない限り、デフォルトで拒否されます。この変更の詳細については、`aws-cdk-cli`「PR [\$1811](https://github.com/aws/aws-cdk-cli/pull/811)」を参照してください。 | | **30** | 2.1034.0 | CloudFormation の早期検証エラーを正確に表示できるように、デプロイロールにスタックイベントを記述するアクセス許可を追加します。この変更の詳細については、`aws-cdk-cli`「PR [\$1970](https://github.com/aws/aws-cdk-cli/pull/970)」を参照してください。 | ## レガシーから最新のブートストラップテンプレートへのアップグレード AWS CDK v1 は、レガシーとモダンの 2 つのブートストラップテンプレートをサポートしました。CDK v2 は、最新のテンプレートのみをサポートします。参考として、これら 2 つのテンプレートの大まかな違いを以下に示します。 | 機能 | レガシー (v1 のみ) | 最新 (v1 および v2) | | --- | --- | --- | | **クロスアカウントデプロイ** | 許可されていません | 許可されています | | ** AWS CloudFormation のアクセス許可** | 現在のユーザーのアクセス許可 ( AWS プロファイル、環境変数などによって決定) を使用してデプロイします。 | ブートストラップスタックがプロビジョニングされたときに指定されたアクセス許可を使用してデプロイします (`--trust` など) | | **バージョニング** | 使用可能なブートストラップスタックのバージョンは 1 つだけです | ブートストラップスタックはバージョニングされています。新しいリソースは将来のバージョンで追加でき、 AWS CDK アプリには最小バージョンが必要になる場合があります。 | | **リソース\$1** | Amazon S3 バケット | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/cdk/v2/guide/bootstrapping-env.html) | | ** AWS KMS キー** | 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 AWS アーティファクトバケットの CDK Pipelines によって作成された KMS キーがまだ存在しないため、ARN によってブートストラップテンプレートで参照できないために使用されます。さらに、Security Hub は、このフラグを提起する際に `Condition` 節を考慮しません。これにより、KMS AWS キーの同じ AWS アカウントから行われた`Resource: *`リクエスト`Condition`に制限されます。これらのリクエストは、KMS キーと同じ AWS リージョンの Amazon S3 AWS から送信する必要があります。 **この検出結果を修正する必要がありますか?** ブートストラップテンプレートの AWS KMS キーを過度に許容するように変更していない限り、*デプロイロール*は必要以上のアクセスを許可しません。したがって、この検出結果を修正する必要はありません。 **この検出結果を修正するにはどうすればよいですか?** この検出結果の修正方法は、クロスアカウントデプロイに CDK Pipelines を使用するかどうかによって異なります。 **Security Hub の検出結果を修正し、クロスアカウントデプロイに CDK Pipelines を使用するには** 1. まだデプロイしていない場合は、`cdk bootstrap` コマンドを使用して CDK ブートストラップスタックをデプロイします。 1. まだ作成していない場合は、CDK Pipeline を作成してデプロイします。手順については、「[CDK Pipelines を使用した継続的インテグレーションと継続的デリバリー (CI/CD)](cdk-pipeline.md)」を参照してください。 1. CodePipeline アーティファクトバケットの AWS KMS キー ARN を取得します。このリソースはパイプラインの作成時に作成されます。 1. CDK ブートストラップテンプレートのコピーを取得して変更します。 AWS CDK CLI を使用した例を次に示します。 ``` $ cdk bootstrap --show-template > bootstrap-template.yaml ``` 1. `PipelineCrossAccountArtifactsKey` ステートメントの `Resource: *` を ARN 値に置き換えて、テンプレートを変更します。 1. テンプレートをデプロイしてブートストラップスタックを更新します。CDK CLI を使用した例を以下に示します。 ``` $ cdk bootstrap aws:/// --template bootstrap-template.yaml ``` **クロスアカウントデプロイに CDK Pipelines を使用していない場合に Security Hub の検出結果を修正するには** 1. CDK ブートストラップテンプレートのコピーを取得して変更します。CDK CLI を使用した例を以下に示します。 ``` $ cdk bootstrap --show-template > bootstrap-template.yaml ``` 1. テンプレートから `PipelineCrossAccountArtifactsBucket` および `PipelineCrossAccountArtifactsKey` ステートメントを削除します。 1. テンプレートをデプロイしてブートストラップスタックを更新します。CDK CLI を使用した例を以下に示します。 ``` $ cdk bootstrap aws:/// --template bootstrap-template.yaml ``` ## 考慮事項 ブートストラップは環境内のリソースをプロビジョニングするため、これらのリソースを AWS CDK で使用すると AWS 料金が発生する可能性があります。 # AWS CDK ブートストラップをカスタマイズする AWS コマンドラインインターフェイス (AWS CDK CLI) を使用するか、AWS CloudFormation ブートストラップテンプレートを変更してデプロイすることで、AWS Cloud Development Kit (AWS CDK) ブートストラップをカスタマイズできます。 ブートストラップの概要については、「[AWS CDK ブートストラップ](bootstrapping.md)」を参照してください。 ## CDK CLI を使用してブートストラップをカスタマイズする CDK CLI を使用してブートストラップをカスタマイズする方法の例を以下に示します。すべての `cdk bootstrap` オプションのリストについては、「[cdk ブーストラップ](ref-cli-cmd-bootstrap.md)」を参照してください。 **Amazon S3 バケットの名前を上書きする** `--bootstrap-bucket-name` オプションを使用して、デフォルトの Amazon S3 バケット名を上書きします。これには、テンプレート合成の変更が必要になる場合があります。詳細については、「[CDK スタック合成をカスタマイズする](configure-synth.md#bootstrapping-custom-synth)」を参照してください。 **Amazon S3 バケットのサーバー側の暗号化キーを変更する** デフォルトでは、ブートストラップスタックの Amazon S3 バケットは、サーバー側の暗号化に AWS 管理キーを使用するように設定されています。既存のカスタマー管理キーを使用するには、`--bootstrap-kms-key-id` オプションを使用し、AWS Key Management Service (AWS KMS) キーの値を指定します。暗号化キーをより詳細に制御したい場合は、カスタマー管理キーを使用するように `--bootstrap-customer-key` を指定します。 **AWS CloudFormation が引き受けるデプロイロールに管理ポリシーをアタッチする** デフォルトでは、スタックは `AdministratorAccess` ポリシーを使用して、完全な管理者アクセス許可でデプロイされます。独自の管理ポリシーを使用するには、`--cloudformation-execution-policies` オプションを使用し、デプロイロールにアタッチする管理ポリシーの ARN を指定します。 複数のポリシーを指定するには、カンマで区切られた 1 つの文字列として渡します。 ``` $ cdk bootstrap --cloudformation-execution-policies "arn:aws:iam::aws:policy/AWSLambda_FullAccess,arn:aws:iam::aws:policy/AWSCodeDeployFullAccess" ``` デプロイの失敗を回避するには、指定したポリシーが、ブートストラップされる環境に実行するデプロイに対して十分であることを確認してください。 **ブートストラップスタック内のリソースの名前に追加される修飾子を変更する** デフォルトでは、`hnb659fds` 修飾子はブートストラップスタック内のリソースの物理 ID に追加されます。この値を変更するには、`--qualifier` オプションを使用します。 この変更は、名前の衝突を避けるために、同じ環境で複数のブートストラップスタックをプロビジョニングする場合に役立ちます。 修飾子の変更は、CDK 自体の自動テスト間の名前の分離を目的としています。CloudFormation 実行ロールに付与された IAM アクセス許可を非常に正確に範囲指定できない限り、1 つのアカウントに 2 つの異なるブートストラップスタックを持つことによるアクセス許可の分離上の利点はありません。したがって、通常、この値を変更する必要はありません。 修飾子を変更するとき、CDK アプリは変更された値をスタックシンセサイザーに渡す必要があります。詳細については、「[CDK スタック合成をカスタマイズする](configure-synth.md#bootstrapping-custom-synth)」を参照してください。 **ブートストラップスタックにタグを追加する** `KEY=VALUE` の形式の `--tags` オプションを使用して、ブートストラップスタックに CloudFormation タグを追加します。 **ブートストラップされる環境にデプロイできる追加の AWS アカウントを指定する** ブートストラップ中の環境にデプロイすることを許可する追加の AWS アカウントを指定するには、`--trust` オプションを使用します。デフォルトでは、ブートストラップを実行するアカウントは常に信頼されます。 このオプションは、別の環境から CDK Pipeline がデプロイする環境をブートストラップする場合に便利です。 このオプションを使用する場合は、`--cloudformation-execution-policies` も指定する必要があります。 信頼されたアカウントを既存のブートストラップスタックに追加するには、以前に提供したアカウントを含め、信頼するすべてのアカウントを指定する必要があります。信頼するアカウントとして新しいアカウントのみを指定した場合、以前に信頼されたアカウントは削除されます。 以下は、2 つのアカウントを信頼する場合の例です。 ``` $ cdk bootstrap aws://123456789012/us-west-2 --trust 234567890123 --trust 987654321098 --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess ⏳ Bootstrapping environment aws://123456789012/us-west-2... Trusted accounts for deployment: 234567890123, 987654321098 Trusted accounts for lookup: (none) Execution policies: arn:aws:iam::aws:policy/AdministratorAccess CDKToolkit: creating CloudFormation changeset... ✅ Environment aws://123456789012/us-west-2 bootstrapped. ``` **ブートストラップする環境内の情報を検索できる追加の AWS アカウントを指定する** `--trust-for-lookup` オプションを使用して、ブートストラップする環境からコンテキスト情報を検索できる AWS アカウントを指定します。このオプションは、実際にそれらのスタックを直接デプロイするアクセス許可をアカウントに付与することなく、環境にデプロイされるスタックを合成するアクセス許可を付与するのに役立ちます。 **ブートストラップスタックの終了保護を有効にする** ブートストラップスタックが削除されると、最初に環境でプロビジョニングされた AWS リソースも削除されます。環境がブートストラップされたら、意図的にブートストラップスタックを削除して再作成しないことをおすすめします。代わりに、`cdk bootstrap` コマンドを再度実行して、ブートストラップスタックを新しいバージョンに更新してみてください。 `--termination-protection` オプションを使用して、ブートストラップスタックの終了保護設定を管理します。終了保護を有効にすることで、ブートストラップスタックとそのリソースが誤って削除されるのを防ぐことができます。これは、CDK Pipelines を使用する場合に特に重要です。なぜなら、ブートストラップスタックを誤って削除した場合、一般的な復旧オプションがないからです。 終了保護を有効にした後、AWS CLI または AWS CloudFormation コンソールを使用して検証できます。 **終了保護を有効化するには** 1. 次のコマンドを実行して、新規または既存のブートストラップスタックで終了保護を有効にします。 ``` $ cdk bootstrap --termination-protection ``` 1. AWS CLI または CloudFormation コンソールを使用して確認します。以下に示しているのは、AWS CLI を使用した例です。ブートストラップスタック名を変更した場合は、`CDKToolkit` をスタック名に置き換えます。 ``` $ aws cloudformation describe-stacks --stack-name --query "Stacks[0].EnableTerminationProtection" true ``` ## デフォルトのブートストラップテンプレートを変更する CDK CLI が提供できる以上のカスタマイズが必要な場合は、必要に応じてブートストラップテンプレートを変更できます。次に、テンプレートをデプロイして環境をブートストラップします。 **デフォルトのブートストラップテンプレートを変更してデプロイするには** 1. `--show-template` オプションを使用して、デフォルトのブートストラップテンプレートを取得します。デフォルトでは、CDK CLI はターミナルウィンドウにテンプレートを出力します。CDK CLI コマンドを変更して、テンプレートをローカルマシンに保存できます。以下に例を示します。 ``` $ cdk bootstrap --show-template > ``` 1. 必要に応じてブートストラップテンプレートを変更します。変更を加える場合は、ブートストラップテンプレート契約に従う必要があります。ブートストラップテンプレート契約の詳細については、「[ブートストラップ契約に従う](#bootstrapping-contract)」を参照してください。 デフォルトテンプレートを使用して `cdk bootstrap` を実行する他のユーザーによって、カスタマイズした内容が誤って上書きされることを防ぐには、`BootstrapVariant` テンプレートパラメータのデフォルト値を変更します。CDK CLI は、現在デプロイされているテンプレートと同じ `BootstrapVariant` を持ち、かつ同じかそれ以上のバージョンを持つテンプレートによってのみ、ブートストラップスタックの上書きを許可します。 1. 任意の AWS CloudFormation のデプロイ方法を使用して、変更されたテンプレートをデプロイします。CDK CLI を使用した例を以下に示します。 ``` $ cdk bootstrap --template ``` ## ブートストラップ契約に従う CDK アプリケーションを適切にデプロイするには、合成中に生成される CloudFormation テンプレートが、ブートストラップ中に作成されるリソースを正しく指定している必要があります。これらのリソースは、一般的に*ブートストラップリソース*と呼ばれます。ブートストラップは、デプロイの実行とアプリケーションアセットの管理に AWS CDK が使用するリソースを AWS 環境に作成します。合成は、アプリケーション内の各 CDK スタックから CloudFormation テンプレートを生成します。これらのテンプレートは、アプリケーションからプロビジョニングされる AWS リソースを定義するだけではありません。これらは、デプロイ中に使用するブートストラップリソースも指定します。 合成中、AWS 環境がどのようにブートストラップされているか、CDK CLI は具体的には把握していません。代わりに CDK CLI は、設定したシンセサイザーに基づいて CloudFormation テンプレートを生成します。そのため、ブートストラップをカスタマイズするときは、合成をカスタマイズする必要があります。合成をカスタマイズする手順については、「[CDK スタック合成をカスタマイズする](configure-synth.md#bootstrapping-custom-synth)」を参照してください。目的は、合成された CloudFormation テンプレートがブートストラップ環境と互換性があることを確認することです。この互換性は、*ブートストラップ契約*と呼ばれます。 スタック合成をカスタマイズする最も簡単な方法は、`Stack` インスタンスの `DefaultStackSynthesizer` クラスを変更することです。このクラスで提供できる以上のカスタマイズが必要な場合は、` [IStackSynthesizer](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.IStackSynthesizer.html) ` を実装するクラスとして独自のシンセサイザーを作成することができます (おそらく `DefaultStackSynthesizer` から派生させることになります)。 ブートストラップをカスタマイズするときは、ブートストラップテンプレートの契約に従って `DefaultStackSynthesizer` との互換性を維持します。ブートストラップテンプレート契約を超えてブートストラップを変更する場合は、独自のシンセサイザーを作成する必要があります。 ### バージョニング ブートストラップテンプレートには、よく知られた名前とテンプレートのバージョンを反映する出力を持つ Amazon EC2 Systems Manager (SSM) パラメータを作成するためのリソースが含まれている必要があります。 ``` Resources: CdkBootstrapVersion: Type: AWS::SSM::Parameter Properties: Type: String Name: Fn::Sub: '/cdk-bootstrap/${Qualifier}/version' Value: 4 Outputs: BootstrapVersion: Value: Fn::GetAtt: [CdkBootstrapVersion, Value] ``` ### ロール `DefaultStackSynthesizer` は、5 つの異なる目的のために 5 つの IAM ロールを必要とします。デフォルトのロールを使用していない場合は、`DefaultStackSynthesizer` オブジェクト内で IAM ロール ARN を指定する必要があります。ロールは以下のとおりです。 + *デプロイロール*は、CDK CLI と AWS CodePipeline によって引き受けられ、環境にデプロイされます。これの `AssumeRolePolicy` は、環境にデプロイできるユーザーを制御します。テンプレートでは、このロールに必要なアクセス許可を確認できます。 + *ルックアップロール*は、環境でコンテキストルックアップを実行するために、CDK CLI によって引き受けられます。これの `AssumeRolePolicy` は、環境にデプロイできるユーザーを制御します。このロールに必要なアクセス許可は、テンプレートで確認できます。 + *ファイル発行ロール*と*イメージ発行ロール*は、環境内にアセットを発行するために、CDK CLI と AWS CodeBuild プロジェクトによって引き受けられます。これらは、それぞれ Amazon S3 バケットと Amazon ECR リポジトリへの書き込みに使用されます。これらのロールには、これらのリソースへの書き込みアクセス許可が必要です。 + *AWS CloudFormation 実行ロール*は AWS CloudFormation に渡され、実際のデプロイを実行します。そのアクセス許可は、デプロイが実行される際に使用されるアクセス許可です。このアクセス許可は、管理ポリシーの ARN を列挙したパラメータとしてスタックに渡されます。 ### Outputs CDK CLI は、ブートストラップスタックに以下の CloudFormation 出力が存在することを必要とします。 + `BucketName` – ファイルアセットバケットの名前。 + `BucketDomainName` – ドメイン名形式のファイルアセットバケット。 + `BootstrapVersion` – ブートストラップスタックの最新バージョン。 ### テンプレート履歴 ブートストラップテンプレートはバージョン管理され、AWS CDK 自体とともに時間の経過とともに進化します。独自のブートストラップテンプレートを指定する場合は、正規のデフォルトテンプレートを使用して最新の状態を維持します。テンプレートがすべての CDK 機能と引き続き連携するようにする必要があります。詳細については、「[ブートストラップテンプレートのバージョン履歴](bootstrapping-env.md#bootstrap-template-history)」を参照してください。 # AWS CDK のアクセス許可の境界を作成して適用する *アクセス許可の境界*は、ユーザーやロールなどの IAM エンティティが持つことができるアクセス許可の上限の設定に使用できる、AWS Identity and Access Management (IAM) の高度な機能です。アクセス許可の境界を使用すると、AWS Cloud Development Kit (AWS CDK) の使用時に IAM エンティティが実行できるアクションを制限できます。 アクセス許可の境界の詳細については、*IAM ユーザーガイド*の「[IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。 ## AWS CDK でアクセス許可の境界を使用するタイミング 組織内の開発者が AWS CDK で特定のアクションを実行することを制限する必要がある場合は、アクセス許可の境界の適用を検討してください。たとえば、開発者に変更されたくない特定のリソースが AWS 環境内にある場合は、アクセス許可の境界を作成して適用できます。 ## AWS CDK でアクセス許可の境界を適用する方法 ### アクセス許可の境界の作成 まず、AWS 管理ポリシーまたはカスタマー管理ポリシーを使用して、IAM エンティティ (ユーザーまたはロール) の境界を設定し、アクセス許可の境界を作成します。このポリシーは、ユーザーやロールのアクセス許可の上限を設定します。アクセス許可の境界の作成手順については、*IAM ユーザーガイド*の「[IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。 アクセス許可の境界は、IAM エンティティが持つことができるアクセス許可の上限を設定しますが、それ自体がアクセス許可を付与することはありません。組織に適したアクセス許可を効果的に制限および付与するには、IAM ポリシーでアクセス許可の境界を使用する必要があります。また、IAM エンティティが設定した境界からエスケープできないようにする必要があります。例については、*IAM ユーザーガイド*の「[アクセス許可の境界を使用した他のユーザーへの責任の委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate)」を参照してください。 ### ブートストラップ時にアクセス許可の境界を適用する アクセス許可の境界を作成したら、ブートストラップ時に適用することで、AWS CDK に対しそれを強制できます。 [`--custom-permissions-boundary`](ref-cli-cmd-bootstrap.md#ref-cli-cmd-bootstrap-options-custom-permissions-boundary) オプションを使用して、適用するアクセス許可の境界の名前を指定します。以下は、`cdk-permissions-boundary` という名前のアクセス許可の境界を適用する場合の例です。 ``` $ cdk bootstrap --custom-permissions-boundary ``` デフォルトでは、CDK はブートストラップテンプレートで定義されている `CloudFormationExecutionRole` IAM ロールを使用して、デプロイを実行するためのアクセス許可を受け取ります。ブートストラップ時にカスタムのアクセス許可の境界を適用すると、そのアクセス許可の境界がこのロールにアタッチされます。これにより、AWS CDK を使用する際に組織内の開発者が実行できるアクセス許可の上限が、アクセス許可の境界により設定されます。このロールの詳細については、「[ブートストラップ中に作成された IAM ロール](bootstrapping-env.md#bootstrapping-env-roles)」を参照してください。 この方法でアクセス許可の境界を適用すると、ブートストラップする特定の環境に適用されます。複数の環境で同じアクセス許可の境界を使用するには、ブートストラップ時にそのアクセス許可の境界を各環境に適用する必要があります。また、環境ごとに異なるアクセス許可の境界を適用することもできます。 ## 詳細 アクセス許可の境界の詳細については、「*AWS セキュリティブログ*」の「[IAM アクセス許可の境界をいつ、どこで使用するか](https://aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/)」を参照してください。 # AWS CDK ブートストラップ問題のトラブルシューティング AWS Cloud Development Kit (AWS CDK) で環境をブートストラップするときによくある問題をトラブルシューティングします。 + ブートストラップの概要については、「[AWS CDK ブートストラップ](bootstrapping.md)」を参照してください。 + ブートストラップの手順については、「[AWS CDK で使用する環境のブートストラップ](bootstrapping-env.md)」を参照してください。 ## デフォルトのテンプレートを使用してブートストラップすると、Amazon S3 バケットの CREATE\$1FAILED エラーが発生します。 デフォルトのブートストラップテンプレートで AWS CDK コマンドラインインターフェイス (CDK CLI) の `cdk bootstrap` コマンドを使用してブートストラップすると、次のエラーが表示されます。 ``` CREATE_FAILED | AWS::S3::Bucket | already exists ``` トラブルシューティングの前に、最新バージョンの CDK CLI を使用していることを確認してください。 + バージョンを確認するには、`cdk --version` を実行します。 + 最新バージョンをインストールするには、`npm install -g aws-cdk` を実行します。 最新バージョンをインストールしたら、環境のブートストラップを再試行してください。それでも同じエラーが表示される場合は、トラブルシューティングを続行します。 ### 一般的な原因 環境をブートストラップすると、AWS CDK はブートストラップリソースの物理 ID を生成します。詳細については、[ブートストラップ中に作成されたリソース ID](bootstrapping-env.md#bootstrapping-env-default-id)」を参照してください。 他のブートストラップリソースとは異なり、Amazon S3 バケット名はグローバルです。つまり、各バケット名は、パーティション内のすべての AWS リージョンにあるすべての AWS アカウントで一意である必要があります。詳細については、「*Amazon S3 ユーザーガイド*」の「[バケットの概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html)」を参照してください。したがって、このエラーの最も一般的な原因は、バケット名として生成された物理 ID がパーティション内のどこかに既に存在することです。これは、アカウント内または別のアカウント内である可能性があります。 バケット名の例を示します: `cdk-hnb659fds-assets-012345678910-us-west-1`。可能性は低いですが、修飾子とアカウント ID が名前の一部であるため、Amazon S3 バケットのこの名前が別の AWS アカウントによって使用されている可能性があります。バケット名はグローバルにスコープされているため、同じパーティション内の別のアカウントで使用されている場合は使用できません。ほとんどの場合、同じ名前のバケットがアカウント内のどこかに存在する可能性があります。これは、ブートストラップしようとしているリージョン、または別のリージョンにある可能性があります。 通常、解決方法は、このバケットをアカウント内で見つけて、そのバケットの操作を決定するか、ブートストラップをカスタマイズして別の名前のブートストラップリソースを作成することです。 ### 解決方法 まず、同じ名前のバケットが AWS アカウント内に存在するかどうかを確認します。有効なアクセス許可を持つ AWS ID を使用して、アカウントの Amazon S3 バケットを検索すると、次の方法でこれを実行できます。 + AWS コマンドラインインターフェイス (AWS CLI) の `aws s3 ls` コマンドを使用して、すべてのバケットのリストを表示します。 + [Amazon S3 コンソール](https://console.aws.amazon.com/s3) を使用して、アカウント内の各リージョンのバケット名を検索します。 同じ名前のバケットが存在する場合は、そのバケットが使用されているかどうかを判断します。使用していない場合は、バケットを削除し、環境を再度ブートストラップすることを検討してください。 同じ名前のバケットが存在し、削除しない場合は、アカウント内のブートストラップスタックに既に関連付けられているかどうかを確認します。複数のリージョンをチェックする必要がある場合があります。Amazon S3 バケット名のリージョンは、必ずしもバケットがそのリージョンにあることを意味するわけではありません。`CDKToolkit` ブートストラップスタックに関連付けられているかどうかを確認するには、リージョンごとに次のいずれかを実行できます。 + AWS CLI の `aws cloudformation describe-stack-resources --stack-name --region ` コマンドを使用して、ブートストラップスタック内のリソースを表示し、バケットが一覧表示されているかどうかを確認します。 + [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation)で、`CDKToolkit` スタックを選択します。次に、**[リソース]** タブで、バケットが存在するかどうかを確認します。 バケットがブートストラップスタックに関連付けられている場合は、ブートストラップスタックがブートストラップしようとしているのと同じリージョンにあるかどうかを確認します。その場合、環境はすでにブートストラップされているため、CDK を使用して環境にアプリケーションをデプロイできるはずです。Amazon S3 バケットが別のリージョンのブートストラップスタックに関連付けられている場合は、何をすべきかを決定する必要があります。解決方法としては、既存の Amazon S3 バケットの名前変更、使用されていない場合の現在の Amazon S3 バケットの削除、作成しようとしている Amazon S3 バケットの新しい名前の使用などがあります。 アカウントで同じ名前の Amazon S3 バケットを見つけることができない場合、別のアカウントに存在する可能性があります。これを解決するには、ブートストラップをカスタマイズして、すべてのブートストラップリソースまたは Amazon S3 バケットに対してのみ新しい名前を作成する必要があります。すべてのブートストラップリソースに新しい名前を作成する場合は、修飾子を変更できます。Amazon S3 バケットのみの新しい名前を作成する場合は、新しいバケット名を指定できます。 ブートストラップをカスタマイズするには、CDK CLI `cdk bootstrap` コマンドでオプションを使用するか、ブートストラップテンプレートを変更します。手順については、「[AWS CDK ブートストラップをカスタマイズする](bootstrapping-customizing.md)」を参照してください。 ブートストラップをカスタマイズする場合は、アプリケーションを適切にデプロイするためには、事前に同じ変更を合成に適用する必要があります。手順については、「[CDK スタック合成をカスタマイズする](configure-synth.md#bootstrapping-custom-synth)」を参照してください。 たとえば、`cdk bootstrap` で新しい修飾子を指定できます。 ``` $ cdk bootstrap --qualifier ``` この変更で作成される Amazon S3 バケット名の例を次に示します: `cdk-abcde0123-assets-012345678910-us-west-1`。ブートストラップ中に作成されたすべてのブートストラップリソースは、この修飾子を使用します。 CDK アプリを開発するときは、シンセサイザーでカスタム修飾子を指定する必要があります。これにより、CDK は合成とデプロイ中にブートストラップリソースを識別するのに役立ちます。スタックインスタンスのデフォルトのシンセサイザーをカスタマイズする例を以下に示します。 **Example** ``` new MyStack(this, 'MyStack', { synthesizer: new DefaultStackSynthesizer({ qualifier: 'abcde0123', }), }); ``` ``` new MyStack(this, 'MyStack', { synthesizer: new DefaultStackSynthesizer({ qualifier: 'abcde0123', }), }) ``` ``` MyStack(self, "MyStack", synthesizer=DefaultStackSynthesizer( qualifier="abcde0123" )) ``` ``` new MyStack(app, "MyStack", StackProps.builder() .synthesizer(DefaultStackSynthesizer.Builder.create() .qualifier("abcde0123") .build()) .build(); ) ``` ``` new MyStack(app, "MyStack", new StackProps { Synthesizer = new DefaultStackSynthesizer(new DefaultStackSynthesizerProps { Qualifier = "abcde0123" }) }); ``` ``` func NewMyStack(scope constructs.Construct, id string, props *MyStackProps) awscdk.Stack { var sprops awscdk.StackProps if props != nil { sprops = props.StackProps } stack := awscdk.NewStack(scope, &id, &sprops) synth := awscdk.NewDefaultStackSynthesizer(&awscdk.DefaultStackSynthesizerProps{ Qualifier: jsii.String("abcde0123"), }) stack.SetSynthesizer(synth) return stack } ``` CDK プロジェクトの `cdk.json` ファイルで新しい修飾子を指定することもできます。 ``` { "app": "...", "context": { "@aws-cdk/core:bootstrapQualifier": "abcde0123" } } ``` Amazon S3 バケット名のみを変更するには、` --bootstrap-bucket-name ` オプションを使用できます。以下に例を示します。 ``` $ cdk bootstrap --bootstrap-bucket-name '' ``` CDK アプリを開発するときは、シンセサイザーで新しいバケット名を指定する必要があります。スタックインスタンスのデフォルトのシンセサイザーをカスタマイズする例を以下に示します。 **Example** ``` new MyStack(this, 'MyStack', { synthesizer: new DefaultStackSynthesizer({ fileAssetsBucketName: 'my-new-bucket-name', }), }); ``` ``` new MyStack(this, 'MyStack', { synthesizer: new DefaultStackSynthesizer({ fileAssetsBucketName: 'my-new-bucket-name', }), }) ``` ``` MyStack(self, "MyStack", synthesizer=DefaultStackSynthesizer( file_assets_bucket_name='my-new-bucket-name' )) ``` ``` new MyStack(app, "MyStack", StackProps.builder() .synthesizer(DefaultStackSynthesizer.Builder.create() .fileAssetsBucketName("my-new-bucket-name") .build()) .build(); ) ``` ``` new MyStack(app, "MyStack", new StackProps { Synthesizer = new DefaultStackSynthesizer(new DefaultStackSynthesizerProps { FileAssetsBucketName = "my-new-bucket-name" }) }); ``` ``` func NewMyStack(scope constructs.Construct, id string, props *MyStackProps) awscdk.Stack { var sprops awscdk.StackProps if props != nil { sprops = props.StackProps } stack := awscdk.NewStack(scope, &id, &sprops) synth := awscdk.NewDefaultStackSynthesizer(&awscdk.DefaultStackSynthesizerProps{ FileAssetsBucketName: jsii.String("my-new-bucket-name"), }) stack.SetSynthesizer(synth) return stack } ``` ### 予防 使用する予定の各 AWS 環境を事前にブートストラップすることをおすすめします。詳細については、「[環境をブートストラップするタイミング](bootstrapping-env.md#bootstrapping-env-when)」を参照してください。特に Amazon S3 バケットの命名の問題では、各 AWS 環境に Amazon S3 バケットが作成され、他のユーザーが Amazon S3 バケット名を使用できなくなります。