

Esta es la guía para desarrolladores de AWS CDK v2. La primera versión del CDK pasó a la etapa de mantenimiento el 1.° de junio de 2022 y no cuenta con soporte desde el 1.° de junio de 2023.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Inicie su entorno para usarlo con el CDK AWS
<a name="bootstrapping-env"></a>

Inicie su AWS entorno para prepararlo para las implementaciones de pilas del AWS Cloud Development Kit (AWS CDK).
+ Para obtener una introducción a los entornos, consulte [Entornos](environments.md) del CDK. AWS 
+ Para obtener una introducción al arranque, consulte [Arranque de AWS CDK](bootstrapping.md).

## Cómo arrancar su entorno
<a name="bootstrapping-howto"></a>

Puede utilizar la interfaz de línea de comandos AWS CDK (AWS CDK CLI) o la herramienta de AWS CloudFormation implementación que prefiera para arrancar su entorno.<a name="bootstrapping-howto-cli"></a>

 **Use la CLI de CDK**   
Puede usar el comando `cdk bootstrap` de la CLI de CDK para arrancar su entorno. Este es el método que recomendamos si no necesita realizar modificaciones importantes en el arranque.    
 **Inicie el sistema desde cualquier directorio de trabajo**   
Para arrancar desde cualquier directorio de trabajo, proporcione el entorno de arranque como un argumento de la línea de comandos. A continuación, se muestra un ejemplo:  

```
$ cdk bootstrap <aws://123456789012/us-east-1>
```
Si no tiene su número de AWS cuenta, puede obtenerlo desde la consola de AWS administración. También puede usar el siguiente comando AWS CLI para mostrar la información de su cuenta predeterminada, incluido su número de cuenta:  

```
$ aws sts get-caller-identity
```
Si ha nombrado perfiles en sus `credentials` archivos AWS `config` y, utilice la `--profile` opción para recuperar la información de la cuenta de un perfil específico. A continuación, se muestra un ejemplo:  

```
$ aws sts get-caller-identity --profile <prod>
```
Para mostrar la región predeterminada, utilice el comando `aws configure get`:  

```
$ aws configure get region
$ aws configure get region --profile <prod>
```
Al proporcionar un argumento, el prefijo `aws://` es opcional. Lo siguiente es válido:  

```
$ cdk bootstrap <123456789012/us-east-1>
```
Para arrancar varios entornos al mismo tiempo, proporcione varios argumentos:  

```
$ cdk bootstrap <aws://123456789012/us-east-1> <aws://123456789012/us-east-2>
```  
 **Inicie el programa desde el directorio principal de un proyecto de CDK**   
Puede ejecutar `cdk bootstrap` desde el directorio principal de un proyecto de CDK que contenga un archivo `cdk.json`. Si no proporciona un entorno como argumento, la CLI de CDK obtendrá la información del entorno de las fuentes predeterminadas, como sus archivos `config` y `credentials` o cualquier información del entorno especificada para la pila de CDK.  
Al arrancar desde el directorio principal de un proyecto de CDK, los entornos proporcionados a partir de los argumentos de la línea de comandos tienen prioridad sobre otras fuentes.  
Para arrancar un entorno especificado en sus archivos `config` y `credentials`, utilice la opción `--profile`:  

```
$ cdk bootstrap --profile <prod>
```
Para obtener más información sobre el comando `cdk bootstrap` y las opciones admitidas, consulte [cdk bootstrap](ref-cli-cmd-bootstrap.md).<a name="bootstrapping-howto-cfn"></a>

 **Utilice cualquier herramienta AWS CloudFormation **   
Puede copiar la [plantilla de arranque](https://github.com/aws/aws-cdk-cli/blob/main/packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml) del *aws-cdk-cli GitHub repositorio* u obtenerla con el `cdk bootstrap --show-template` comando. A continuación, utilice cualquier AWS CloudFormation herramienta para implementar la plantilla en su entorno.  
Con este método, puedes usar nuestra AWS CloudFormation StackSets Torre AWS de Control. También puede utilizar la AWS CloudFormation consola o la interfaz de línea de AWS comandos (AWS CLI). Puede realizar modificaciones en la plantilla antes de implementarla. Este método puede ser más flexible y adecuado para implementaciones a gran escala.  
El siguiente es un ejemplo del uso de la opción `--show-template` para recuperar y guardar la plantilla de arranque en su máquina local:  

**Example**  

```
$ cdk bootstrap --show-template > bootstrap-template.yaml
```
En Windows, PowerShell debe usarse para conservar la codificación de la plantilla.  

```
powershell "cdk bootstrap --show-template | Out-File -encoding utf8 bootstrap-template.yaml"
```
Si aparecen avisos de CDK en el resultado de la AWS CloudFormation plantilla, proporcione la `--no-notices` opción junto con el comando.
Para implementar esta plantilla mediante la CLI de CDK, puede ejecutar lo siguiente:  

```
$ cdk bootstrap --template <bootstrap-template.yaml>
```
El siguiente es un ejemplo del uso de la AWS CLI para implementar la plantilla:  

**Example**  

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

```
aws cloudformation create-stack ^
  --stack-name CDKToolkit ^
  --template-body file://<path/to/>bootstrap-template.yaml ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --region <us-west-1>
```
Para obtener información sobre cómo iniciar varios entornos, consulte Cómo iniciar [varias AWS cuentas para CloudFormation StackSets utilizarlas en AWS CDK en el blog sobre operaciones y migraciones CloudFormation StackSets](https://aws.amazon.com/blogs/mt/bootstrapping-multiple-aws-accounts-for-aws-cdk-using-cloudformation-stacksets/) en la * AWS nube*.

## Cuando arrancar su entorno
<a name="bootstrapping-env-when"></a>

Debe iniciar cada AWS entorno antes de implementarlo en el entorno. Recomendamos arrancar de forma proactiva cada entorno que desee utilizar. Puede hacerlo antes de planificar la implementación efectiva de las aplicaciones CDK en el entorno. Al arrancar sus entornos de forma proactiva, evita posibles problemas futuros, como conflictos de nombres de bucket de Amazon S3 o la implementación de aplicaciones CDK en entornos que no se iniciaron.

Está bien arrancar un entorno más de una vez. Si un entorno ya se inició, la pila de arranque se actualizará si es necesario. De lo contrario, no pasará nada.

Si intenta implementar una pila de CDK en un entorno que no arrancó, verá un error como el siguiente:

```
$ 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)
```<a name="bootstrapping-env-when-update"></a>

 **Actualice su pila de bootstrap**   
De forma periódica, el equipo de CDK actualizará la plantilla de arranque a una versión nueva. Cuando esto sucede, le recomendamos que actualice la pila de arranque. Si no personalizó el proceso de arranque, puede actualizar su pila de arranque con los mismos pasos que siguió para arrancar su entorno originalmente. Para obtener más información, consulte el [historial de versiones de la plantilla de arranque.](#bootstrap-template-history)

## Recursos predeterminados creados durante el arranque
<a name="bootstrapping-env-default"></a><a name="bootstrapping-env-roles"></a>

 **Funciones de IAM creadas durante el arranque**   
De forma predeterminada, el bootstrapping aprovisiona las siguientes funciones de AWS Identity and Access Management (IAM) en su entorno:  
+  `CloudFormationExecutionRole` 
+  `DeploymentActionRole` 
+  `FilePublishingRole` 
+  `ImagePublishingRole` 
+  `LookupRole` <a name="bootstrapping-env-roles-cfn"></a>  
 `CloudFormationExecutionRole`   
Esta función de IAM es una función de CloudFormation servicio que otorga CloudFormation permiso para realizar despliegues de pilas en su nombre. Esta función te da CloudFormation permiso para realizar llamadas a la AWS API en tu cuenta, incluida la implementación de pilas.  
Al usar un rol de servicio, los permisos proporcionados para el rol de servicio determinan qué acciones se pueden realizar en tus CloudFormation recursos. Sin esta función de servicio, las credenciales de seguridad que proporcione con la CLI de CDK determinarían lo que CloudFormation está permitido hacer.  
 `DeploymentActionRole`   
Este rol de IAM concede permiso para realizar implementaciones en su entorno. La CLI de CDK lo asume durante las implementaciones.  
Al usar un rol para las implementaciones, puede realizar implementaciones entre cuentas, ya que el rol lo pueden asumir AWS las identidades de una cuenta diferente.  
 `FilePublishingRole`   
Este rol de IAM concede permiso para realizar acciones contra el bucket de Amazon Simple Storage Service (Amazon S3) que arrancó, incluidas la carga y eliminación de activos. La CLI de CDK lo asume durante las implementaciones.  
 `ImagePublishingRole`   
Este rol de IAM concede permiso para realizar acciones contra el repositorio Amazon Elastic Container Registry (Amazon ECR) que arrancó. La CLI de CDK lo asume durante las implementaciones.  
 `LookupRole`   
Esta función de IAM otorga `readOnly` permiso para buscar [valores de contexto en el entorno](context.md). AWS La CLI de CDK lo asume al realizar tareas como la síntesis de plantillas y las implementaciones.<a name="bootstrapping-env-default-id"></a>

 **Recurso IDs creado durante el arranque**   
Al implementar la plantilla de arranque predeterminada, los recursos físicos IDs para el arranque se crean utilizando la siguiente estructura:. `cdk-<qualifier>-<description>-<account-ID>-<Region>`  
+  **Calificador**: un valor de cadena único de nueve caracteres de `hnb659fds`. El valor real no tiene importancia.
+  **Descripción**: una descripción corta del recurso. Por ejemplo, `container-assets`.
+  **ID de cuenta**: el ID de AWS cuenta del entorno.
+  **Región**: la AWS región del entorno.
El siguiente es un ejemplo de ID físico del bucket transitorio de Amazon S3 creado durante el arranque: `cdk-hnb659fds-assets-012345678910-us-west-1`.

## Permisos que se deben utilizar al arrancar el entorno
<a name="bootstrapping-env-permissions"></a>

Al iniciar un AWS entorno, la identidad de IAM que realiza el arranque debe tener al menos los siguientes permisos:

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

Con el tiempo, la pila de arranque, incluidos los recursos que se crean y los permisos que requieren, puede cambiar. Con cambios futuros, es posible que tenga que modificar los permisos necesarios para arrancar un entorno.

## Personalice el arranque
<a name="bootstrapping-env-customize"></a>

Si la plantilla de arranque predeterminada no se ajusta a sus necesidades, puede personalizar el arranque de recursos a su entorno de las siguientes maneras:
+ Utilizar las opciones de línea de comandos con el comando `cdk bootstrap`: este método es el mejor para realizar cambios pequeños y específicos que se admiten mediante las opciones de la línea de comandos.
+ Modificar la plantilla de arranque predeterminada e implementarla: este método es el mejor para realizar cambios complejos o si desea tener un control total sobre la configuración de los recursos aprovisionados durante el arranque.

[Para obtener más información sobre la personalización del arranque, consulte Personalizar el arranque de CDK. AWS](bootstrapping-customizing.md)

## Proceso de arranque con CDK Pipelines
<a name="bootstrapping-env-pipelines"></a>

Si utiliza CDK Pipelines para realizar la implementación en el entorno de otra cuenta y recibe un mensaje como el siguiente:

```
Policy contains a statement with one or more invalid principals
```

Este mensaje de error significa que los roles de IAM adecuados no existen en el otro entorno. La causa más probable es que el entorno no arrancó. Arranque el entorno e inténtelo de nuevo.<a name="bootstrapping-env-pipelines-protect"></a>

 **Cómo proteger su pila de bootstrap para que no se elimine**   
Si se elimina una pila de bootstrap, también se eliminarán los AWS recursos que se aprovisionaron originalmente en el entorno para respaldar las implementaciones de CDK. Esto hará que la canalización deje de funcionar. Si esto sucede, no existe una solución general para la recuperación.  
Una vez que se arranque el entorno, no elimine ni vuelva a crear la pila de arranque del entorno. En su lugar, intente actualizar la pila de arranque a una nueva versión ejecutando el comando `cdk bootstrap` de nuevo.  
Para evitar que se elimine accidentalmente la pila de arranque, le recomendamos que proporcione la opción `--termination-protection` junto con el comando `cdk bootstrap` para habilitar la protección contra la terminación. Puede habilitar la protección contra la terminación en pilas de arranque nuevas o existentes. Para obtener instrucciones sobre cómo habilitar la protección de terminación, consulte [Enable termination protection for the bootstrap stack](bootstrapping-customizing.md#bootstrapping-customizing-cli-protection).

## Historial de versiones de la plantilla de arranque
<a name="bootstrap-template-history"></a>

La plantilla de bootstrap está versionada y evoluciona con el tiempo con la propia CDK. AWS Si proporciona su propia plantilla de arranque, manténgala actualizada mediante la plantilla canónica predeterminada. Querrá asegurarse de que su plantilla siga funcionando con todas las características del CDK.

**nota**  
Las versiones anteriores de la plantilla de arranque creaban una clave AWS KMS en cada entorno de arranque de forma predeterminada. Para evitar que se le cobre por la clave KMS, reinicie el arranque de estos entornos con `--no-bootstrap-customer-key`. El valor predeterminado actual es sin una clave KMS, lo que ayuda a evitar estos cargos.

Esta sección contiene una lista de los cambios realizados en cada versión.


| Versión de plantilla |  AWS Versión CDK | Cambios | 
| --- | --- | --- | 
|   **1**   |  1.40.0  |  Versión inicial de la plantilla con el bucket, la clave, el repositorio y los roles.  | 
|   **2**   |  1.45.0  |  Se dividió el rol del publicador de activos en roles independientes del publicador de archivos e imágenes.  | 
|   **3**   |  1.46.0  |  Se agregó la opción de exportación de `FileAssetKeyArn` para poder agregar permisos de descifrado a los consumidores de activos.  | 
|   **4**   |  1.61.0  |   AWS Los permisos de KMS ahora están implícitos a través de Amazon S3 y ya no son necesarios`FileAssetKeyArn`. Se agregó el parámetro SSM de `CdkBootstrapVersion` para que la versión de la pila de arranque se pueda verificar sin conocer el nombre de la pila.  | 
|   **5**   |  1.87.0  |  El rol de implementación puede leer el parámetro SSM.  | 
|   **6**   |  1.108.0  |  Se agregó un rol de búsqueda independiente del rol de implementación.  | 
|   **6**   |  1.109,0  |  Se adjuntó una etiqueta `aws-cdk:bootstrap-role` a los roles de implementación, publicación de archivos y publicación de imágenes.  | 
|   **7**   |  1.110,0  |  El rol de implementación ya no puede leer directamente los buckets de la cuenta de destino. (Sin embargo, este rol es, en efecto, el de administrador y, de todos modos, siempre puede usar sus AWS CloudFormation permisos para hacer que el bucket sea legible).  | 
|   **8**   |  1.114.0  |  El rol de búsqueda tiene permisos completos de solo lectura para el entorno de destino y también tiene una etiqueta de `aws-cdk:bootstrap-role`.  | 
|   **9**   |  2.1.0  |  Corrige el rechazo de las cargas de activos de Amazon S3 por parte del SCP de cifrado al que se hace referencia comúnmente.  | 
|   **10**   |  2.4.0  |  Amazon ECR ahora ScanOnPush está activado de forma predeterminada.  | 
|   **11**   |  2.18.0  |  Agrega una política que permite a Lambda extraer datos de los repositorios de Amazon ECR para sobrevivir al reinicio del arranque.  | 
|   **12**   |  2.20.0  |  Agrega soporte para experimentos de `cdk import`.  | 
|   **13**   |  2.25.0  |  Hace que las imágenes del contenedor de los repositorios de Amazon ECR creados en el arranque sean inmutables.  | 
|   **14**   |  2.34.0  |  Desactiva de forma predeterminada el escaneo de imágenes de Amazon ECR en el nivel del repositorio para permitir el arranque de regiones que no admiten el escaneo de imágenes.  | 
|   **15**   |  2.60,0  |  Las claves KMS no se pueden etiquetar.  | 
|   **16**   |  2.69,0  |  Aborda el resultado de Security Hub[KMS.2](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html#kms-2).  | 
|   **17**   |  2.72.0  |  Aborda el resultado de Security Hub [ECR.3](https://docs.aws.amazon.com/securityhub/latest/userguide/ecr-controls.html#ecr-3).  | 
|   **18**   |  2.80,0  |  Se revirtieron los cambios realizados en la versión 16, ya que no funcionan en todas las particiones y no se recomiendan.  | 
|   **19**   |  2.106.1  |  Se han revertido los cambios realizados en la versión 18, en los que se eliminaba la AccessControl propiedad de la plantilla. ([\$127964](https://github.com/aws/aws-cdk/issues/27964))  | 
|   **20**   |  2.119.0  |  Añada `ssm:GetParameters` una acción a la función de AWS CloudFormation implementación de IAM. Para obtener más información, consulte [\$128336](https://github.com/aws/aws-cdk/pull/28336/files#diff-4fdac38426c4747aa17d515b01af4994d3d2f12c34f7b6655f24328259beb7bf).  | 
|   **21**   |  2.149.0  |  Se agregó una condición al rol de publicación de archivos.  | 
|   **22**   |  2.160,0  |  Se agregaron permisos de `sts:TagSession` a la política de confianza de los roles de IAM de arranque.  | 
|   **23**   |  2.161,0  |  Se agregaron permisos de `cloudformation:RollbackStack` y `cloudformation:ContinueUpdateRollback` a la política de confianza del rol de IAM de implementación. Esto proporciona permisos para el comando `cdk rollback`.  | 
|   **24**   |  2.165.0  |  Cambie el periodo de días durante el que se conservarán los objetos no actuales del bucket de arranque, de 365 a 30 días. Dado que el nuevo comando `cdk gc` introduce la capacidad de eliminar objetos del bucket de arranque, este nuevo comportamiento garantiza que los objetos eliminados permanezcan en el bucket de arranque durante 30 días en lugar de 365 días. Para obtener más información sobre este cambio, consulte `aws-cdk` PR [\$131949](https://github.com/aws/aws-cdk/pull/31949).  | 
|   **25**   |  2.165,0  |  Agregue soporte al bucket de arranque para eliminar las cargas de varias partes incompletas. Las cargas de varias partes incompletas se eliminarán después de 1 día. Para obtener más información sobre este cambio, consulte `aws-cdk` PR [\$131956](https://github.com/aws/aws-cdk/pull/31956).  | 
|   **26**   |  2.1002.0  |  Agregue al recurso dos políticas relacionadas con la eliminación (`UpdateReplacePolicy` y `DeletionPolicy` al `FileAssetsBucketEncryptionKey`). Estas políticas garantizan que el antiguo recurso clave de AWS KMS se elimine correctamente cuando se actualice o elimine la pila de arranque. Para obtener más información sobre este cambio, consulte `aws-cdk-cli` PR [\$1100](https://github.com/aws/aws-cdk-cli/pull/100).  | 
|   **27**   |  2.1003.0  |  Agregue una nueva política de recursos de Amazon ECR para conceder a Amazon EMR sin servidor permisos específicos para recuperar imágenes de contenedores. Para obtener más información sobre este cambio, consulte `aws-cdk-cli` PR [\$1112](https://github.com/aws/aws-cdk-cli/pull/112).  | 
|   **28**   |  2.1015,0  |  Añada permisos para realizar acciones de refactorización de pilas a la función de implementación y TagSession permisos a todas las funciones. [Para obtener más información sobre este cambio, consulte `aws-cdk-cli` PR \$1471.](https://github.com/aws/aws-cdk-cli/pull/471)  | 
|   **29**   |  2.1026,0  |  Todas las AssumeRole llamadas que proporcionen un se ExternalId rechazarán de forma predeterminada, a menos que estén deshabilitadas. Para obtener más información sobre este cambio, consulta `aws-cdk-cli` PR [\$1811](https://github.com/aws/aws-cdk-cli/pull/811).  | 
|   **30**   |  2.1034.0  |  Añada permisos para describir los eventos de la pila a la función de despliegue para poder mostrar con precisión los errores de validación CloudFormation temprana. Para obtener más información sobre este cambio, consulte `aws-cdk-cli` PR [\$1970](https://github.com/aws/aws-cdk-cli/pull/970).  | 

## Actualización de una plantilla de arranque de heredada a una moderna
<a name="bootstrapping-template"></a>

El AWS CDK v1 admitía dos plantillas de arranque: la antigua y la moderna. CDK v2 solo admite la plantilla moderna. Como referencia, estas son las diferencias de alto nivel entre estas dos plantillas.


| Característica | Heredada (solo en la v1) | Moderna (v1 y v2) | 
| --- | --- | --- | 
|   **Implementaciones entre cuentas**   |  No permitido  |  Permitido  | 
|   ** AWS CloudFormation Permisos**   |  Se implementa con los permisos del usuario actual (determinados por el AWS perfil, las variables de entorno, etc.)  |  Se implementa con los permisos especificados cuando se aprovisionó la pila de arranque (por ejemplo, mediante el uso de `--trust`)  | 
|   **Control de versiones**   |  Solo hay disponible una versión de la pila de arranque  |  La pila de Bootstrap está versionada; se pueden agregar nuevos recursos en futuras versiones y las aplicaciones de AWS CDK pueden requerir una versión mínima  | 
|   **Recursos**\$1   |  Bucket de Amazon S3  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/cdk/v2/guide/bootstrapping-env.html)  | 
|   ** AWS Clave KMS**   |  Roles de IAM  |  Repositorio de Amazon ECR  | 
|   **Nombramiento de los recursos**   |  Se generan de forma automática  |  Determinista  | 
|   **Cifrado de bucket**   |  Clave predeterminada  |   AWS clave gestionada de forma predeterminada. Se puede personalizar para utilizar una clave administrada por el cliente.  | 
+  *Agregaremos recursos adicionales a la plantilla de bootstrap según sea necesario.* 

Un entorno que arrancó con la plantilla heredada debe actualizarse para utilizar la plantilla moderna de CDK v2 mediante el reinicio del arranque. Vuelva a implementar todas las aplicaciones de AWS CDK en el entorno al menos una vez antes de eliminar el depósito antiguo.

## Abordar los resultados de Security Hub
<a name="bootstrapping-securityhub"></a>

Si utiliza AWS Security Hub, es posible que vea información sobre algunos de los recursos creados por el proceso de arranque de AWS CDK. Los resultados de Security Hub le ayudan a encontrar configuraciones de recursos que debe comprobar para garantizar su precisión y seguridad. Hemos revisado estas configuraciones de recursos específicas con AWS Security y estamos seguros de que no constituyen un problema de seguridad.<a name="bootstrapping-securityhub-kms2"></a>

 **[KMS.2] Los directores de IAM no deberían tener políticas integradas de IAM que permitan realizar acciones de descifrado en todas las claves de KMS**   
El *rol de implementación* (`DeploymentActionRole`) otorga permiso para leer datos cifrados, lo cual es necesario para las implementaciones entre cuentas con CDK Pipelines. Las políticas de este rol no otorgan permisos a todos los datos. Solo concede permiso para leer datos cifrados de Amazon S3 y AWS KMS, y solo cuando esos recursos lo permiten a través de su política de bucket o clave.  
A continuación, se incluye un fragmento de estas dos instrucciones sobre el *rol de implementación* de la plantilla de arranque:  

```
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
              ...
```<a name="bootstrapping-securityhub-kms2-why"></a>  
 **¿Por qué Security Hub marca esto?**   
Las políticas contienen un `Resource: *` combinado con una cláusula `Condition`. Security Hub marca el comodín `*`. Este comodín se utiliza porque, en el momento en que se inicia la cuenta, la clave AWS KMS creada por CDK Pipelines para CodePipeline el depósito de artefactos aún no existe y, por lo tanto, ARN no puede hacer referencia a ella en la plantilla de arranque. Además, Security Hub no tiene en cuenta la cláusula `Condition` al hacer esta marca. Esto se `Condition` limita `Resource: *` a las solicitudes realizadas desde la misma cuenta de la clave KMS. AWS AWS Estas solicitudes deben provenir de Amazon S3 en la misma AWS región que la clave de AWS KMS.  
 **¿Debo corregir este hallazgo?**   
Mientras no haya modificado la clave AWS KMS de la plantilla de arranque para que sea demasiado permisiva, la *función de implementación* no permitirá más acceso del necesario. Por lo tanto, no es necesario corregir este resultado.  
 **¿Qué sucede si quiero corregir este hallazgo?**   
La forma de solucionar este resultado dependerá de si utilizará o no CDK Pipelines para las implementaciones entre cuentas.    
 **Para corregir el Security Hub: buscar y usar CDK Pipelines para despliegues entre cuentas**   

1. Si aún no lo hizo, implemente la pila arranque de CDK mediante el comando `cdk bootstrap`.

1. Si aún no lo hizo, cree e implemente la Pipeline de CDK. Para obtener instrucciones, consulte [Integración y entrega continuas (CI/CD) con CDK Pipelines](cdk-pipeline.md).

1. Obtenga el ARN de la clave AWS KMS del depósito de CodePipeline artefactos. Este recurso se crea durante la creación de la canalización.

1. Obtenga una copia de la plantilla de arranque de CDK para modificarla. El siguiente es un ejemplo, mediante la CLI de AWS CDK:

   ```
   $ cdk bootstrap --show-template > bootstrap-template.yaml
   ```

1. Modifique la plantilla mediante la sustitución del `Resource: *` de la instrucción `PipelineCrossAccountArtifactsKey` por su valor de ARN.

1. Implemente la plantilla para actualizar su pila de arranque. A continuación, se muestra un ejemplo mediante la CLI de CDK:

   ```
   $ cdk bootstrap aws://<account-id>/<region> --template bootstrap-template.yaml
   ```  
 **Para solucionar el problema de Security Hub si no utilizas CDK Pipelines para despliegues entre cuentas**   

1. Obtenga una copia de la plantilla de arranque de CDK para modificarla. A continuación, se muestra un ejemplo mediante la CLI de CDK:

   ```
   $ cdk bootstrap --show-template > bootstrap-template.yaml
   ```

1. Elimine las instrucciones `PipelineCrossAccountArtifactsBucket` y `PipelineCrossAccountArtifactsKey` de la plantilla.

1. Implemente la plantilla para actualizar su pila de arranque. A continuación, se muestra un ejemplo mediante la CLI de CDK:

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

## Consideraciones
<a name="bootstrapping-env-considerations"></a>

Dado que el arranque aprovisiona los recursos de su entorno, es posible que se le cobren AWS gastos si esos recursos se utilizan con la CDK. AWS 

# Personalización del arranque del AWS CDK
<a name="bootstrapping-customizing"></a>

Puede personalizar el arranque del AWS Cloud Development Kit (AWS CDK) mediante la interfaz de línea de comandos del AWS CDK (CLI de AWS CDK) o modificando e implementando la plantilla de arranque de AWS CloudFormation.

Para obtener una introducción al arranque, consulte [Arranque de AWS CDK](bootstrapping.md).

## Utilice la CLI de CDK para personalizar el arranque
<a name="bootstrapping-customizing-cli"></a>

A continuación, se muestran algunos ejemplos de cómo puede personalizar el arranque mediante la CLI de CDK. Para obtener una lista de todas las opciones `cdk bootstrap`, consulte [arranque de CDK](ref-cli-cmd-bootstrap.md).<a name="bootstrapping-customizing-cli-s3-name"></a>

 **Anule el nombre del bucket de Amazon S**   
Utilice la opción `--bootstrap-bucket-name` para anular el nombre del bucket de Amazon S3 predeterminado. Esto puede requerir que modifique la síntesis de plantillas. Consulte [Personalizar la síntesis de pilas de CDK](configure-synth.md#bootstrapping-custom-synth) para obtener más información.<a name="bootstrapping-customizing-keys"></a>

 **Modifique las claves de cifrado del lado del servidor del bucket de Amazon S**   
De forma predeterminada, el bucket de Amazon S3 de la pila de arranque está configurado para usar claves administradas de AWS para el cifrado del servidor. Para usar una clave administrada por el cliente existente, utilice la opción `--bootstrap-kms-key-id` y proporcione un valor para que la clave del AWS Key Management Service (AWS KMS) la utilice. Si desea tener un mayor control sobre la clave de cifrado, proporcione una `--bootstrap-customer-key` para que utilice una clave administrada por el cliente.<a name="bootstrapping-customizing-cli-deploy-role"></a>

 **Adjunte políticas administradas al rol de implementación que asuma AWS CloudFormation**   
De forma predeterminada, las pilas se implementan con todos los permisos de administrador mediante la política `AdministratorAccess`. Para usar sus propias políticas administradas, utilice la opción `--cloudformation-execution-policies` y proporcione los ARN de las políticas administradas para asociarlos al rol de implementación.  
Para proporcionar varias políticas, páselas en una sola cadena, separadas por comas:  

```
$ cdk bootstrap --cloudformation-execution-policies "arn:aws:iam::aws:policy/AWSLambda_FullAccess,arn:aws:iam::aws:policy/AWSCodeDeployFullAccess"
```
Para evitar errores en la implementación, asegúrese de que las políticas que especifique sean suficientes para cualquier implementación que vaya a realizar en el entorno que se arranca.

 **Cambie el calificador que se agrega a los nombres de los recursos de la pila de arranque**   
De forma predeterminada, el calificador `hnb659fds` se agrega al ID físico de los recursos de la pila de arranque. Para cambiar este valor, use la opción `--qualifier`.  
Esta modificación resulta útil cuando se aprovisionan varias pilas de arranque en el mismo entorno para evitar conflictos de nombres.  
El calificador se cambia para aislar los nombres entre las pruebas automatizadas del propio CDK. A menos que pueda reducir con mucha precisión los permisos de IAM otorgados al rol de ejecución de CloudFormation, tener dos pilas de arranque diferentes en una sola cuenta no brinda ninguna ventaja de aislamiento de permisos. Por lo tanto, no suele ser necesario cambiar este valor.  
Cuando cambia el calificador, la aplicación CDK debe pasar el valor modificado al sintetizador de pilas. Consulte [Personalizar la síntesis de pilas de CDK](configure-synth.md#bootstrapping-custom-synth) para obtener más información.

 **Agregue etiquetas a la pila de arranque**   
Utilice la opción `--tags` en el formato de `KEY=VALUE` para agregar etiquetas de CloudFormation a su pila de arranque.

 **Especifique otras cuentas de AWS que se puedan implementar en el entorno que se arranca**   
Utilice la opción `--trust` para proporcionar cuentas de AWS adicionales que tengan permiso para implementarse en el entorno que se arranca. De forma predeterminada, siempre se confiará en la cuenta que ejecuta el arranque.  
Esta opción resulta útil cuando se arranca un entorno en el que se implementará una Pipeline del CDK de otro entorno.  
Cuando utilice esta opción, también debe proporcionar las `--cloudformation-execution-policies`.  
Para agregar cuentas de confianza a una pila de arranque existente, debe especificar todas las cuentas en las que puede confiar, incluidas las que haya proporcionado anteriormente. Si solo proporciona cuentas nuevas en las que confiar, se eliminarán las cuentas de confianza anteriores.  
A continuación, se muestra un ejemplo de confianza de dos cuentas:  

```
$ 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.
```<a name="bootstrapping-customizing-cli-accounts-lookup"></a>

 **Especifique otras cuentas de AWS adicionales que puedan buscar información en el entorno que se arranca**   
Utilice la opción `--trust-for-lookup` para especificar las cuentas de AWS que están autorizadas para buscar información contextual del entorno que se arranca. Esta opción resulta útil para dar permiso a las cuentas para sintetizar las pilas que se van a implementar en el entorno, sin concederles realmente permiso para implementar esas pilas directamente.<a name="bootstrapping-customizing-cli-protection"></a>

 **Habilite la protección de la terminación para la pila de arranque**   
Si se elimina una pila de arranque, también se eliminarán los recursos de AWS que se aprovisionaron originalmente en el entorno. Tras el arranque del entorno, recomendamos que no elimine ni vuelva a crear la pila de arranque del entorno, a menos que lo haga de forma intencionada. En su lugar, intente actualizar la pila de arranque a una nueva versión ejecutando de nuevo el comando `cdk bootstrap`.  
Utilice la opción `--termination-protection` para administrar la configuración de la protección de terminación de la pila de arranque. Es posible evitar que una pila de arranque y sus recursos se eliminen de manera accidental; para ello, habilite la protección de terminación. Esto es particularmente importante si utiliza Pipelines del CDK, ya que no hay ninguna opción de recuperación general en caso de que elimine accidentalmente la pila de arranque.  
Tras activar la protección contra la terminación, puede utilizar la AWS CLI o la consola de AWS CloudFormation para realizar la verificación.    
 **Para habilitar la protección contra la terminación**   

1. Ejecute el siguiente comando para habilitar la protección de terminación en una pila de arranque nueva o existente:

   ```
   $ cdk bootstrap --termination-protection
   ```

1. Utilice la AWS CLI o la consola de CloudFormation verificarlo. A continuación se muestra un ejemplo del uso de la AWS CLI. Si modificó el nombre de la pila de arranque, sustituya el `CDKToolkit` por el nombre de la pila:

   ```
   $ aws cloudformation describe-stacks --stack-name <CDKToolkit> --query "Stacks[0].EnableTerminationProtection"
   true
   ```

## Modificar la plantilla de arranque predeterminada
<a name="bootstrapping-customizing-template"></a>

Cuando necesite una mayor personalización de la que la CLI de CDK pueda proporcionar, puede modificar la plantilla de arranque según sea necesario. A continuación, implemente la plantilla para arrancar su entorno.

 **Para modificar e implementar la plantilla de arranque predeterminada**   

1. Obtenga la plantilla de arranque predeterminada mediante la opción `--show-template`. De forma predeterminada, la CLI de CDK mostrará la plantilla en la ventana de su terminal. Puede modificar el comando de la CLI de CDK para guardar la plantilla en su máquina local. A continuación, se muestra un ejemplo:

   ```
   $ cdk bootstrap --show-template > <my-bootstrap-template.yaml>
   ```

1. Modifique la plantilla de arranque según sea necesario. Todos los cambios que realice deben respetar la plantilla de contrato de arranque. Para obtener más información sobre la plantilla de contrato de arranque, consulte [Seguimiento el contrato de arranque](#bootstrapping-contract).

   Para asegurarse de que nadie que ejecute `cdk bootstrap` cuando utilice la plantilla predeterminada sobrescriba sus personalizaciones accidentalmente más adelante, cambie el valor predeterminado del parámetro `BootstrapVariant` de la plantilla. La CLI de CDK solo permitirá sobrescribir la pila de arranque mediante plantillas que tengan la misma `BootstrapVariant` y una versión igual o superior a la de la plantilla implementada actualmente.

1. Implemente la plantilla modificada mediante el método de implementación de AWS CloudFormation de su preferencia. A continuación, se muestra un ejemplo que utiliza la CLI de CDK:

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

## Respete el contrato de arranque
<a name="bootstrapping-contract"></a>

Para que las aplicaciones del CDK se implementen correctamente, las plantillas de CloudFormation generadas durante la síntesis deben especificar correctamente los recursos creados durante el arranque. Estos recursos se denominan comúnmente *recursos de arranque*. El arranque crea recursos en su entorno de AWS que el AWS CDK utiliza para llevar a cabo implementaciones y administrar los activos de las aplicaciones. La síntesis produce plantillas de CloudFormation a partir de cada pila de CDK de la aplicación. Estas plantillas no solo definen los recursos de AWS que se aprovisionarán a partir de la aplicación. También especifican los recursos de arranque que se van a utilizar durante la implementación.

Durante la síntesis, la CLI de CDK no sabe específicamente cómo se arrancó el entorno de AWS. En su lugar, la CLI de CDK produce plantillas de CloudFormation basadas en el sintetizador que configure. Por lo tanto, es posible que al momento de personalizar el arranque deba personalizar la síntesis. Consulte [Personalizar la síntesis de pilas de CDK](configure-synth.md#bootstrapping-custom-synth) para obtener instrucciones sobre cómo personalizar la síntesis. El objetivo es garantizar que las plantillas sintetizadas de CloudFormation sean compatibles con el entorno de arranque. Esta compatibilidad se conoce como *contrato de arranque*.

El método más sencillo para personalizar la síntesis de pilas consiste en modificar la clase `DefaultStackSynthesizer` de la instancia `Stack`. Si necesita una personalización más allá de la que puede ofrecer esta clase, puede escribir su propio sintetizador como una clase que implemente el código ` [IStackSynthesizer](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.IStackSynthesizer.html) ` (que quizás derive del `DefaultStackSynthesizer`).

Cuando personalice el arranque, respete la plantilla del contrato de arranque para que siga siendo compatible con `DefaultStackSynthesizer`. Si modifica el arranque más allá de la plantilla del contrato de arranque, deberá escribir su propio sintetizador.

### Control de versiones
<a name="bootstrapping-contract-versioning"></a>

La plantilla de arranque debe contener un recurso para crear un parámetro de Amazon EC2 Systems Manager (SSM) con un nombre reconocido y un resultado que refleje la versión de la plantilla:

```
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]
```

### Roles
<a name="bootstrapping-contract-roles"></a>

El `DefaultStackSynthesizer` requiere cinco roles de IAM para cinco propósitos diferentes. Si no utiliza los roles predeterminados, debe especificar los ARN de su rol de IAM dentro del objeto `DefaultStackSynthesizer`. Los roles son los siguientes:
+ Al *rol de implementación* lo asumen la CLI de CDK y AWS CodePipeline para la implementación en un entorno. Su `AssumeRolePolicy` controla quién puede llevar a cabo la implementación en el entorno. En la plantilla, puede ver los permisos que necesita este rol.
+ Al *rol de búsqueda* lo asume la CLI de CDK para llevar a cabo búsquedas de contexto en un entorno. Su `AssumeRolePolicy` controla quién puede llevar a cabo la implementación en el entorno. Los permisos que necesita este rol se pueden ver en la plantilla.
+ Al *rol de publicación de archivos* y al *rol de publicación de imágenes* lo asumen la CLI de CDK y los proyectos de AWS CodeBuild para publicar activos en un entorno. Se utilizan para escribir en el bucket de Amazon S3 y en el repositorio de Amazon ECR, respectivamente. Estos roles requieren acceso de escritura a estos recursos.
+  *El rol de ejecución de AWSCloudFormation* se transfiere a AWS CloudFormation para llevar a cabo implementación real. Sus permisos son aquellos con los que se ejecutará la implementación. Los permisos se transfieren a la pila como un parámetro que enumera los ARN de las políticas administradas.

### Salidas
<a name="bootstrapping-contract-outputs"></a>

La CLI de CDK requiere que existan las siguientes salidas de CloudFormation en la pila de arranque:
+  `BucketName`: el nombre del bucket del activo de archivo.
+  `BucketDomainName`: el bucket del activo de archivo en formato de nombre de dominio.
+  `BootstrapVersion`: la versión actual de la pila de arranque.

### Historial de plantillas
<a name="bootstrapping-contract-history"></a>

La plantilla de arranque cuenta con control de versiones y evoluciona con el tiempo junto con el AWS CDK. Si proporciona su propia plantilla de arranque, manténgala actualizada mediante la plantilla canónica predeterminada. Querrá asegurarse de que su plantilla siga funcionando con todas las características del CDK. Para obtener más información, consulte el [historial de versiones de la plantilla de arranque.](bootstrapping-env.md#bootstrap-template-history)

# Cree y aplique límites de permisos para AWS CDK
<a name="customize-permissions-boundaries"></a>

Un *límite de permisos* es una característica avanzada de AWS Identity and Access Management (IAM) que se puede utilizar para establecer los permisos máximos que puede tener una entidad de IAM, como un usuario o un rol. Puede utilizar los límites de permisos para restringir las acciones que las entidades de IAM pueden realizar al utilizar AWS Cloud Development Kit (AWS CDK).

Para obtener más información sobre los límites de permisos, consulte [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) en la *Guía del usuario de IAM*.

## Cuándo utilizar los límites de permisos con AWS CDK
<a name="customize-permissions-boundaries-when"></a>

Considere la posibilidad de aplicar límites de permisos cuando necesite impedir que los desarrolladores de su organización realicen determinadas acciones con AWS CDK. Por ejemplo, si hay recursos específicos en su entorno de AWS que no desea que los desarrolladores modifiquen, puede crear y aplicar un límite de permisos.

## Cómo aplicar los límites de permisos con AWS CDK
<a name="customize-permissions-boundaries-how"></a>

### Cree el límite de permisos
<a name="customize-permissions-boundaries-how-create"></a>

En primer lugar, crea el límite de permisos para establecer el límite para una entidad IAM (usuario o rol). Esto puede ser mediante una política administrada por AWS o una política administrada por el cliente. Esta política limita los permisos máximos que puede tener el usuario o rol. Para obtener instrucciones sobre la creación de límites de permisos de IAM, consulte [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) en la *Guía del usuario de IAM*.

Los límites de permisos establecen los permisos máximos que puede tener una entidad de IAM, pero no los conceden por sí solos. Debe utilizar los límites de permisos con las políticas de IAM para limitar y conceder de manera efectiva los permisos adecuados a su organización. También debe evitar que las entidades de IAM puedan escapar de los límites que usted establece. Para ver un ejemplo, consulte [Delegar la responsabilidad a otros mediante los límites de permisos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate) en la *Guía del usuario de IAM*.

### Aplique el límite de permisos durante el arranque
<a name="customize-permissions-boundaries-how-apply"></a>

Tras crear el límite de permisos, puede aplicarlo a AWS CDK durante el arranque.

Utilice la opción [`--custom-permissions-boundary`](ref-cli-cmd-bootstrap.md#ref-cli-cmd-bootstrap-options-custom-permissions-boundary) y especifique el nombre del límite de permisos que se va a aplicar. A continuación, se muestra un ejemplo que aplica un límite de permisos denominado `cdk-permissions-boundary`:

```
$ cdk bootstrap --custom-permissions-boundary <cdk-permissions-boundary>
```

De forma predeterminada, CDK usa el rol de IAM `CloudFormationExecutionRole` definido en la plantilla de arranque para recibir permisos al realizar implementaciones. Al aplicar el límite de permisos personalizado durante el arranque, dicho límite se asocia a este rol. A continuación, el límite de permisos establecerá el número máximo de permisos que pueden conceder los desarrolladores de su organización al utilizar AWS CDK. Para obtener más información sobre esta función, consulte [Roles de IAM creadas durante el arranque](bootstrapping-env.md#bootstrapping-env-roles).

Cuando se aplican los límites de permisos de esta manera, se emplean en el entorno específico que se inicia. Para usar el mismo límite de permisos en varios entornos, debe aplicarlo para cada entorno durante el arranque. También puede aplicar diferentes límites de permisos para diferentes entornos.

## Más información
<a name="customize-permissions-boundaries-learn"></a>

Para obtener más información sobre los límites de permisos, consulte [When and where to use IAM permissions boundaries](https://aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/) en el *Blog de seguridad de AWS*.

# Solución de problemas de arranque de AWS CDK
<a name="bootstrapping-troubleshoot"></a>

Solucione los problemas más comunes al arrancar el entorno con AWS Cloud Development Kit (AWS CDK).
+ Para obtener una introducción al arranque, consulte [Arranque de AWS CDK](bootstrapping.md).
+ Para obtener instrucciones sobre el arranque, consulte [Arranque su entorno para utilizarlo con el AWS CDK](bootstrapping-env.md).

## Al arrancar con la plantilla predeterminada, aparece el error “CREATE\$1FAILED” para el bucket de Amazon S3
<a name="bootstrapping-troubleshoot-s3-bucket-name"></a>

Al arrancar mediante el comando `cdk bootstrap` de la interfaz de la línea de comandos de AWS CDK (CLI de CDK) con la plantilla de arranque predeterminada, aparece el siguiente error:

```
CREATE_FAILED | AWS::S3::Bucket | <BucketName> already exists
```

Antes de comenzar con la solución de problemas, asegúrese de que utiliza la versión más reciente de la CLI de CDK.
+ Para comprobar la versión, ejecute `cdk --version`.
+ Para instalar la versión más reciente, ejecute `npm install -g aws-cdk`.

Tras instalar la versión más reciente, intente volver a arrancar el entorno. Si recibe el mismo error, continúe con la solución de problemas.

### Causas habituales
<a name="bootstrapping-troubleshoot-s3-bucket-name-causes"></a>

Cuando arranca su entorno, AWS CDK genera ID físicos para sus recursos de arranque. Para obtener más información, consulte [ID de recursos creados durante el arranque](bootstrapping-env.md#bootstrapping-env-default-id).

A diferencia del resto de los recursos de arranque, los nombres del bucket de Amazon S3 son globales. Esto significa que cada nombre de bucket debe ser único en todas las cuentas de AWS para todas las regiones de AWS dentro de una partición. Para obtener más información, consulte [Descripción general de los buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) en la *Guía del usuario de Amazon S3*. Por lo tanto, la causa más común de este error es que el ID físico generado como nombre del bucket ya existe en algún lugar en la partición. Puede estar en su cuenta o en otra cuenta.

El siguiente es un ejemplo de un nombre de bucket: `cdk-hnb659fds-assets-012345678910-us-west-1`. Si bien es poco probable, dado que el calificador y el ID de cuenta forman parte del nombre, es posible que otra cuenta de AWS utilice este nombre para un bucket de Amazon S3. Como los nombres del bucket tienen un alcance global, no puede usarlos si los usa una cuenta diferente en la misma partición. Lo más probable es que haya un bucket con el mismo nombre en algún lugar de su cuenta. Puede estar en la región que intenta arrancar o en otra región.

Por lo general, la solución consiste en localizar este bucket en su cuenta y determinar qué hacer con él, o bien personalizar el proceso de arranque para crear recursos de arranque con un nombre diferente.

### Resolución
<a name="bootstrapping-troubleshoot-s3-bucket-name-resolution"></a>

En primer lugar, determine si existe un bucket con el mismo nombre dentro de su cuenta de AWS. Si utiliza una identidad de AWS con permisos válidos para buscar buckets de Amazon S3 en su cuenta, puede hacerlo de las siguientes maneras:
+ Utilice el comando `aws s3 ls` de la interfaz de la línea de comandos de AWS (AWS CLI) para ver una lista de todos sus buckets.
+ Busque los nombres del bucket de cada región en su cuenta mediante la [consola Amazon S3](https://console.aws.amazon.com/s3).

Si existe un bucket con el mismo nombre, determine si está en uso. Si no se utiliza, considere la posibilidad de eliminar el bucket e intente arrancar el entorno de nuevo.

Si existe un bucket con el mismo nombre y no desea eliminarlo, determine si ya está asociado a una pila de arranque en la cuenta. Puede que tengas que comprobar en varias regiones. La región en el nombre del bucket de Amazon S3 no significa necesariamente que el bucket esté en esa región. Para comprobar si está asociada a la pila de arranque de `CDKToolkit`, puede llevar a cabo una de las siguientes acciones para cada región:
+ Utilice el comando de AWS CLI `aws cloudformation describe-stack-resources --stack-name <CDKToolkit> --region <Region>` para ver los recursos en la pila de arranque y comprobar si el bucket aparece en la lista.
+ En la [consola de AWS CloudFormation](https://console.aws.amazon.com/cloudformation), seleccione la pila `CDKToolkit`. A continuación, en la pestaña **Recursos**, compruebe si el bucket existe.

Si el bucket está asociado a una pila de arranque, determine si la pila de arranque se encuentra en la misma región en la que intenta arrancar. Si es así, su entorno ya está en fase de arranque y debería poder empezar a utilizar CDK para implementar aplicaciones en su entorno. Si el bucket de Amazon S3 está asociado a una pila de arranque en una región diferente, tendrá que decidir qué hacer. Las posibles soluciones incluyen cambiar el nombre del bucket de Amazon S3 existente, eliminar el bucket de Amazon S3 actual si no se utiliza o usar un nombre nuevo para el bucket de Amazon S3 que intenta crear.

Si no encuentra un bucket de Amazon S3 con el mismo nombre en su cuenta, es posible que esté en una cuenta distinta. Para resolver este problema, tendrá que personalizar el arranque para crear nuevos nombres para todos sus recursos de arranque o solo para su bucket de Amazon S3. Para crear nuevos nombres para todos los recursos de arranque, puede modificar el calificador. Para crear un nuevo nombre solo para el bucket de Amazon S3, puede proporcionar un nuevo nombre de bucket.

Para personalizar el arranque, puede usar las opciones con el comando `cdk bootstrap` de la CLI de CDK o modificar la plantilla de arranque. Para obtener instrucciones generales, consulte [Personalización del arranque de AWS CDK](bootstrapping-customizing.md).

Si personaliza el arranque, tendrá que aplicar los mismos cambios a la síntesis antes de poder implementar una aplicación de forma correcta. Para obtener instrucciones, consulte [Personalizar la síntesis de la pila de CDK](configure-synth.md#bootstrapping-custom-synth).

Por ejemplo, puede proporcionar un nuevo calificador con `cdk bootstrap`:

```
$ cdk bootstrap --qualifier <abcde0123>
```

A continuación, se muestra un ejemplo de un nombre de bucket de Amazon S3 que se creará con esta modificación: `cdk-abcde0123-assets-012345678910-us-west-1`. Todos los recursos de arranque creados durante el proceso de arranque utilizarán este calificador.

Al desarrollar la aplicación CDK, debe especificar el calificador personalizado en el sintetizador. Esto ayuda al CDK a identificar sus recursos de arranque durante la síntesis y la implementación. A continuación, se muestra un ejemplo de personalización del sintetizador predeterminado para la instancia de pila:

**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
}
```
También, puede especificar el nuevo calificador en el archivo `cdk.json` del proyecto de CDK:  

```
{
  "app": "...",
  "context": {
    "@aws-cdk/core:bootstrapQualifier": "abcde0123"
  }
}
```
Para modificar únicamente el nombre del bucket de Amazon S3, puede utilizar la opción ` --bootstrap-bucket-name `. A continuación, se muestra un ejemplo:  

```
$ cdk bootstrap --bootstrap-bucket-name '<my-new-bucket-name>'
```

Al desarrollar la aplicación de CDK, debe especificar el nombre del nuevo bucket en el sintetizador. A continuación, se muestra un ejemplo de personalización del sintetizador predeterminado para la instancia de pila:

**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
}
```

### Prevención
<a name="bootstrapping-troubleshoot-s3-bucket-name-prevention"></a>

Recomendamos arrancar de forma proactiva cada entorno de AWS que desee usar. Para obtener más información, consulte [Cuándo arrancar el entorno](bootstrapping-env.md#bootstrapping-env-when). Específicamente para el problema de denominación de los buckets de Amazon S3, esto creará buckets de Amazon S3 en cada entorno de AWS e impedirá que otros usen su nombre de bucket de Amazon S3.