これは 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 料金が発生する可能性があります。