Este é o Guia do desenvolvedor do AWS CDK v2. O CDK v1 antigo entrou em manutenção em 1º de junho de 2022 e encerrou o suporte em 1º de junho de 2023.

Referência da CLI do AWS CDK

A interface de linha de comandos (CLI do CDK da AWS) do kit de desenvolvimento em nuvem da AWS (CDK da AWS), também conhecida como Kit de Ferramentas CDK, é a principal ferramenta para interagir com sua aplicação do CDK da AWS. Ela executa sua aplicação, interroga o modelo de aplicação que você definiu e produz e implanta os modelos do AWS CloudFormation gerados pelo AWS CDK. Ela também fornece outros atributos úteis para criar e trabalhar com projetos do AWS CDK. Este tópico contém informações sobre casos de uso comuns da CLI do CDK.

A CLI do CDK é instalada com o Node Package Manager. Na maioria dos casos, recomendamos instalá-lo globalmente.

npm install -g aws-cdk             # install latest version
npm install -g aws-cdk@X.YY.Z      # install specific version

Comandos da CLI do CDK

Todos os comandos da CLI do CDK começam com cdk, que é seguido por um subcomando (list, synthesize, deploy, etc.). Alguns subcomandos têm uma versão mais curta (ls, synth, etc.) que é equivalente. As opções e os argumentos seguem o subcomando em qualquer ordem.

Para obter uma descrição de todos os subcomandos, opções e argumentos, consulte a Referência de comandos da CLI do AWS CDK.

Especificar as opções e seus valores

As opções da linha de comandos começam com dois hífens (--). Algumas opções usadas com frequência têm sinônimos de uma única letra que começam com um único hífen (por exemplo, --app tem um sinônimo -a). A ordem das opções em um comando da CLI do CDK não é importante.

Todas as opções aceitam um valor, que deve seguir o nome da opção. O valor pode ser separado do nome por espaço em branco ou por um sinal de igual =. As duas opções a seguir são equivalentes.

--toolkit-stack-name MyBootstrapStack
--toolkit-stack-name=MyBootstrapStack

Algumas opções são sinalizadores (booleanos). É possível especificar true ou false como seu valor. Se você não fornecer um valor, ele será considerado como true. Você também pode prefixar o nome da opção com um prefixo no- para sugerir false.

# sets staging flag to true
--staging
--staging=true
--staging true

# sets staging flag to false
--no-staging
--staging=false
--staging false

Algumas opções, a saber, --context, --parameters, --plugin, --tags e --trust, podem ser especificadas mais de uma vez para especificar vários valores. Eles são indicados como tendo a ajuda do tipo [array] da CLI do CDK. Por exemplo:

cdk bootstrap --tags costCenter=0123 --tags responsibleParty=jdoe

Ajuda integrada

A CLI do CDK tem ajuda integrada. É possível ver a ajuda geral sobre o utilitário e uma lista dos subcomandos fornecidos emitindo:

cdk --help

Para ver a ajuda de um subcomando específico, por exemplo, deploy, especifique-o antes do sinalizador --help.

cdk deploy --help

Emita cdk version para exibir a versão da CLI do CDK. Forneça essas informações ao solicitar suporte.

Relatórios de versão

Para obter informações sobre como o AWS CDK é usado, os constructos usados pelas aplicações do AWS CDK são coletados e relatados usando um recurso identificado como AWS::CDK::Metadata. Para saber mais, consulte Configuração de relatórios de dados de uso do AWS CDK.

Autenticação com AWS

Há diferentes maneiras de configurar o acesso programático aos seus recursos da AWS, dependendo do ambiente e do acesso da AWS disponível para você.

Para escolher seu método de autenticação e configurá-lo para a CLI do CDK, consulte Configuração das credenciais de segurança para a CLI do AWS CDK.

A abordagem recomendada para novos usuários que estejam desenvolvendo localmente, que não tenham recebido um método de autenticação do empregador, é configurar o Centro de Identidade do AWS IAM. Esse método inclui a instalação da AWS CLI para facilitar a configuração e entrar regularmente no portal de acesso da AWS. Se você escolher esse método, seu ambiente deverá conter os elementos a seguir depois de concluir o procedimento de autenticação do Centro de Identidade do IAM no Guia de referência de ferramentas e SDKs da AWS:

Iniciar uma sessão do portal de acesso da AWS

Antes de acessar os serviços da AWS, você precisa de uma sessão ativa do portal de acesso da AWS para que a CLI do CDK use a autenticação do Centro de Identidade do IAM para resolver as credenciais. Dependendo da duração da sessão configurada, o seu acesso acabará expirando e a CLI do CDK encontrará um erro de autenticação. Para entrar no portal de acesso da AWS, execute o comando a seguir na AWS CLI.

aws sso login

Se a configuração do provedor de token de SSO estiver usando um perfil nomeado em vez do perfil padrão, o comando será aws sso login --profile <NAME>. Especifique também esse perfil ao emitir comandos cdk usando a opção --profile ou a variável de ambiente AWS_PROFILE.

Para testar se você já tem uma sessão ativa, execute o comando da AWS CLI a seguir.

aws sts get-caller-identity

A resposta a esse comando deve relatar a conta do Centro de Identidade do IAM e o conjunto de permissões configurados no arquivo compartilhado config.

Especificar região e outra configuração

A CLI do CDK precisa conhecer a região da AWS em que você está implantando e como se autenticar com a AWS. Isso é necessário para operações de implantação e para recuperar valores de contexto durante a síntese. Juntas, sua conta e sua região compõem o ambiente.

A região pode ser especificada usando variáveis de ambiente ou em arquivos de configuração. Essas são as mesmas variáveis e arquivos usados por outras ferramentas da AWS, como a AWS CLI e os vários SDKs da AWS. A CLI do CDK busca essas informações na ordem a seguir.

Além de especificar a autenticação da AWS e uma região na seção [default], você também pode adicionar uma ou mais seções da [profile <NAME>], onde <NAME> é o nome do perfil. Para obter mais informações sobre perfis nomeados, consulte Arquivos compartilhados de configuração e de credenciais no Guia de referência de ferramentas e SDKs da AWS.

O arquivo config da AWS padrão está localizado em ~/.aws/config (macOS/Linux) ou %USERPROFILE%\.aws\config (Windows). Para mais detalhes e locais alternativos, consulte Local dos arquivos de configuração e credenciais compartilhados do Guia de referência de ferramentas e SDKs da AWS

O ambiente que você especifica na sua aplicação do AWS CDK usando a propriedade env da pilha é usado durante a síntese. Ele é usado para gerar um modelo do AWS CloudFormation específico do ambiente e, durante a implantação, substitui a conta ou a região especificada por um dos métodos anteriores. Para obter mais informações, consulte Ambientes para o CDK da AWS.

Opcionalmente, você pode usar a opção --role-arn (ou -r) para especificar o ARN de um perfil do IAM que deve ser usado para implantação. Esse perfil deve ser assumido pela conta da AWS que está sendo usada.

Especificar o comando da aplicação

Muitos atributos da CLI do CDK exigem que um ou mais modelos do AWS CloudFormation sejam sintetizados, o que, por sua vez, exige a execução da aplicação. O AWS CDK oferece suporte a programas escritos em várias linguagens. Portanto, ele usa uma opção de configuração para especificar o comando exato necessário para executar sua aplicação. Essa opção pode ser especificada de duas formas.

Primeiro, e mais comumente, ele pode ser especificado usando a chave app dentro do arquivo cdk.json. Isso está no diretório principal do seu projeto do AWS CDK. A CLI do CDK fornece um comando apropriado ao criar um novo projeto com cdk init. Aqui está o cdk.json de um novo projeto TypeScript, por exemplo.

{
  "app": "npx ts-node bin/hello-cdk.ts"
}

A CLI do CDK procura por cdk.json no diretório de trabalho atual ao tentar executar sua aplicação. Por isso, é possível manter um shell aberto no diretório principal do seu projeto para emitir comandos da CLI do CDK.

A CLI do CDK também procura a chave da aplicação em ~/.cdk.json (ou seja, em seu diretório inicial) se não conseguir encontrá-la em ./cdk.json. Adicionar o comando da aplicação aqui pode ser útil se você costuma trabalhar com código do CDK na mesma linguagem.

Se você estiver em algum outro diretório ou quiser executar sua aplicação usando um comando diferente daquele em cdk.json, use a opção --app (ou -a) para especificá-lo.

cdk --app "npx ts-node bin/hello-cdk.ts" ls

Ao implantar, você também pode especificar um diretório contendo conjuntos de nuvem sintetizados, como cdk.out, com o valor de --app. As pilhas especificadas são implantadas a partir desse diretório. A aplicação não é sintetizada.

Especificar pilhas

Muitos comandos da CLI do CDK (por exemplo, cdk deploy) funcionam em pilhas definidas na sua aplicação. Se sua aplicação contiver apenas uma pilha, a CLI do CDK presume que você se refere a essa pilha se você não especificar uma pilha explicitamente.

Caso contrário, você deverá especificar a pilha ou pilhas com as quais deseja trabalhar. É possível fazer isso especificando as pilhas desejadas por ID individualmente na linha de comando. Lembre-se de que o ID é o valor especificado pelo segundo argumento quando você instancia a pilha.

cdk synth PipelineStack LambdaStack

Você também pode usar curingas para especificar IDs que correspondam a um padrão.

Você também pode usar a opção --all para especificar todas as pilhas.

Se a sua aplicação usa CDK Pipelines, a CLI do CDK entende suas pilhas e estágios como uma hierarquia. Além disso, a opção --all e o curinga * correspondem apenas às pilhas de nível superior. Para combinar todas as pilhas, use **. Use também ** para indicar todas as pilhas em uma determinada hierarquia.

Ao usar curingas, coloque o padrão entre aspas ou escape dos curingas com \. Caso contrário, seu shell pode tentar expandir o padrão para os nomes dos arquivos no diretório atual. Na melhor das hipóteses, não acontecerá o que você espera; na pior das hipóteses, é possível implantar pilhas que não pretendia. Isso não é estritamente necessário no Windows porque cmd.exe não expande os curingas, mas ainda assim é uma boa prática.

cdk synth "*Stack"    # PipelineStack, LambdaStack, etc.
cdk synth 'Stack?'    # StackA, StackB, Stack1, etc.
cdk synth \*          # All stacks in the app, or all top-level stacks in a CDK Pipelines app
cdk synth '**'        # All stacks in a CDK Pipelines app
cdk synth 'PipelineStack/Prod/**'   # All stacks in Prod stage in a CDK Pipelines app

Fazer bootstrapping em seu ambiente da AWS

A implantação de pilhas com o CDK exige que recursos dedicados especiais do AWS CDK sejam provisionados. O comando cdk bootstrap cria os recursos necessários para você. Você só precisa fazer o bootstrapping se estiver implantando uma pilha que exija esses recursos dedicados. Consulte Bootstrapping do AWS CDK para obter detalhes.

cdk bootstrap

Se emitido sem argumentos, conforme mostrado aqui, o comando cdk bootstrap sintetiza a aplicação atual e faz o bootstrapping dos ambientes nos quais suas pilhas serão implantadas. Se a aplicação contiver pilhas independentes do ambiente, que não especificam explicitamente um ambiente, será feito o bootstrapping na conta e na região padrão, ou o ambiente especificado será usando --profile.

Fora de uma aplicação, é necessário especificar explicitamente o ambiente a sofrer bootstrapping. Você também pode fazer isso para realizar o bootstrapping de um ambiente que não esteja especificado em sua aplicação ou perfil da AWS local. As credenciais devem ser configuradas (por exemplo, em ~/.aws/credentials) para a conta e a região especificadas. É possível especificar um perfil que contenha as credenciais necessárias.

cdk bootstrap <ACCOUNT-NUMBER>/<REGION> # e.g.
cdk bootstrap 1111111111/us-east-1
cdk bootstrap --profile test 1111111111/us-east-1

É possível incorrer em cobranças da AWS pelo que o AWS CDK armazena nos recursos de bootstrapping. Além disso, se você usar --bootstrap-customer-key, uma chave do AWS KMS será criada, o que também incorrerá em cobranças por ambiente.

Criar um nova aplicação

Para criar um nova aplicação, crie um diretório para ele e, dentro do diretório, emita cdk init.

mkdir my-cdk-app
cd my-cdk-app
cdk init <TEMPLATE> --language <LANGUAGE>

As linguagens compatíveis (<LANGUAGE>) são:

<TEMPLATE> é um modelo opcional. Se o modelo desejado for app, o padrão, será possível omiti-lo. Os modelos disponíveis são:

Os modelos usam o nome da pasta do projeto para gerar nomes para arquivos e classes dentro do sua nova aplicação.

Listar pilhas

Para ver uma lista dos IDs das pilhas em sua aplicação do AWS CDK, insira um dos seguintes comandos equivalentes:

cdk list
cdk ls

Se a sua aplicação contiver pilhas do CDK Pipelines, a CLI do CDK exibirá os nomes das pilhas como caminhos de acordo com sua localização na hierarquia do pipeline. (Por exemplo, PipelineStack, PipelineStack/Prod e PipelineStack/Prod/MyService.)

Se sua aplicação contiver muitas pilhas, será possível especificar IDs de pilhas completos ou parciais das pilhas a serem listadas. Para obter mais informações, consulte Especificação de pilhas.

Adicione o sinalizador --long para ver mais informações sobre as pilhas, incluindo os nomes das pilhas e seus ambientes (conta e região da AWS).

Sintetizar pilhas

O comando cdk synthesize (quase sempre abreviado para synth) sintetiza uma pilha definida em sua aplicação em um modelo do CloudFormation.

cdk synth         # if app contains only one stack
cdk synth MyStack
cdk synth Stack1 Stack2
cdk synth "*"     # all stacks in app

Consulte cdk synth --help para obter todas as opções disponíveis. Algumas das opções usadas com mais frequência são abordadas na seção a seguir.

Especificar valores do contexto

Use a opção --context ou -c para passar valores de contexto do runtime para sua aplicação do CDK.

# specify a single context value
cdk synth --context key=value MyStack

# specify multiple context values (any number)
cdk synth --context key1=value1 --context key2=value2 MyStack

Ao implantar várias pilhas, os valores de contexto especificados normalmente são passados para todas elas. Se quiser, você pode especificar valores diferentes para cada pilha prefixando o nome da pilha no valor do contexto.

# different context values for each stack
cdk synth --context Stack1:key=value Stack2:key=value Stack1 Stack2

Especificar o formato de exibição

Por padrão, o modelo sintetizado é exibido no formato YAML. Em vez disso, adicione o sinalizador --json para exibi-lo no formato JSON.

cdk synth --json MyStack

Especificar o diretório de saída

Adicione a opção --output (-o) para gravar os modelos sintetizados em um diretório diferente de cdk.out.

cdk synth --output=~/templates

Implantar pilhas

O subcomando cdk deploy implanta uma ou mais pilhas especificadas em sua conta da AWS.

cdk deploy        # if app contains only one stack
cdk deploy MyStack
cdk deploy Stack1 Stack2
cdk deploy "*"    # all stacks in app

Consulte cdk deploy --help para obter todas as opções disponíveis. Algumas das opções mais úteis são abordadas na seção a seguir.

Ignorar síntese

O comando cdk deploy normalmente sintetiza as pilhas da sua aplicação antes da implantação para garantir que a implantação reflita a versão mais recente da sua aplicação. Se você sabe que não alterou seu código desde o último cdk synth, é possível suprimir a etapa de síntese redundante durante a implantação. Para fazer isso, especifique o diretório cdk.out do seu projeto na opção --app.

cdk deploy --app cdk.out StackOne StackTwo

Desabilitar reversão

O AWS CloudFormation tem a capacidade de reverter as alterações para que as implantações sejam atômicas. Isso significa que eles são bem-sucedidos ou falham como um todo. O AWS CDK herda esse recurso porque sintetiza e implanta modelos do AWS CloudFormation.

A reversão garante que seus recursos estejam sempre em um estado consistente, o que é vital para as pilhas de produção. No entanto, enquanto você ainda está desenvolvendo sua infraestrutura, algumas falhas são inevitáveis, e reverter implantações malsucedidas pode atrasar o processo.

Por esse motivo, a CLI do CDK permite que você desabilite a reversão adicionando --no-rollback ao seu comando cdk deploy. Com esse sinalizador, implantações com falha não são revertidas. Em vez disso, os recursos implantados antes do recurso com falha permanecem em vigor e a próxima implantação começa com o recurso com falha. Você passará muito menos tempo esperando por implantações e muito mais tempo desenvolvendo sua infraestrutura.

Troca dinâmica

Use o sinalizador --hotswap com cdk deploy para tentar atualizar seus recursos da AWS diretamente em vez de gerar um conjunto de alterações do AWS CloudFormation e implantá-lo. A implantação volta à implantação do AWS CloudFormation se a troca dinâmica não for possível.

Atualmente, a troca dinâmica é compatível com funções do Lambda, máquinas de estado do Step Functions e imagens de contêineres do Amazon ECS. O sinalizador --hotswap também desabilita a reversão (ou seja, implica em --no-rollback).

Modo de observação

O modo de observação da CLI do CDK (cdk deploy --watch ou cdk watch, de forma abreviada) monitora continuamente os arquivos de origem e ativos da sua aplicação do CDK em busca de alterações. Ele executa imediatamente uma implantação das pilhas especificadas quando uma alteração é detectada.

Por padrão, essas implantações usam a o sinalizador --hotswap, que acelera a implantação de alterações nas funções do Lambda. Ele também volta à implantação do AWS CloudFormation se você tiver alterado a configuração da infraestrutura. Para que cdk watch sempre realize implantações do AWS CloudFormation completas, adicione o sinalizador --no-hotswap a cdk watch.

Todas as alterações feitas enquanto cdk watch já está executando uma implantação são combinadas em uma única implantação, que começa assim que a implantação em andamento é concluída.

O modo de observação usa a chave "watch" no cdk.json do projeto para determinar quais arquivos monitorar. Por padrão, esses arquivos são os arquivos e ativos da sua aplicação, mas isso pode ser alterado modificando as entradas "include" e "exclude" na chave "watch". O arquivo cdk.json a seguir mostra um exemplo dessas entradas.

{
  "app": "mvn -e -q compile exec:java",
  "watch": {
    "include": "src/main/**",
    "exclude": "target/*"
  }
}

cdk watch executa o comando "build" do cdk.json para criar sua aplicação antes da síntese. Se sua implantação exigir algum comando para criar ou empacotar seu código do Lambda (ou qualquer outra coisa que não esteja na sua aplicação do CDK), adicione-o aqui.

Os curingas no estilo Git, tanto * quanto **, podem ser usados nas chaves "watch" e "build". Cada caminho é interpretado em relação ao diretório principal do cdk.json. O valor padrão de include é **/*, ou seja, todos os arquivos e diretórios no diretório raiz do projeto. exclude é opcional.

Especificação de parâmetros do AWS CloudFormation

A CLI do CDK oferece suporte à especificação de parâmetros do AWS CloudFormation na implantação. É possível fornecê-los na linha de comando seguindo o sinalizador --parameters.

cdk deploy MyStack --parameters uploadBucketName=UploadBucket

Para definir vários parâmetros, use vários sinalizadores --parameters.

cdk deploy MyStack --parameters uploadBucketName=UpBucket --parameters downloadBucketName=DownBucket

Se você estiver implantando várias pilhas, poderá especificar um valor diferente de cada parâmetro para cada pilha. Para fazer isso, prefixe o nome do parâmetro com o nome da pilha e dois pontos. Caso contrário, o mesmo valor será passado para todas as pilhas.

cdk deploy MyStack YourStack --parameters MyStack:uploadBucketName=UploadBucket --parameters YourStack:uploadBucketName=UpBucket

Por padrão, o AWS CDK retém os valores dos parâmetros de implantações anteriores e os usa em implantações posteriores, caso não sejam especificados explicitamente. Use o sinalizador --no-previous-parameters para exigir que todos os parâmetros sejam especificados.

Especificar arquivo de saídas

Se sua pilha declarar saídas do AWS CloudFormation, elas normalmente são exibidas na tela no final da implantação. Para gravá-los em um arquivo no formato JSON, use o sinalizador --outputs-file.

cdk deploy --outputs-file outputs.json MyStack

Aprovar alterações relacionadas à segurança

Para protegê-lo contra alterações não intencionais que afetam sua postura de segurança, a CLI do CDK solicita que você aprove as alterações relacionadas à segurança antes de implantá-las. É possível especificar o nível de alteração que requer aprovação:

cdk deploy --require-approval <LEVEL>

<LEVEL> pode ser um dos seguintes:

A configuração também pode ser definida no arquivo cdk.json.

{
  "app": "...",
  "requireApproval": "never"
}

Comparar pilhas

O comando cdk diff compara a versão atual de uma pilha (e suas dependências) definida em sua aplicação com as versões já implantadas ou com um modelo do AWS CloudFormation salvo e exibe uma lista de alterações.

Stack HelloCdkStack
IAM Statement Changes
┌───┬──────────────────────────────┬────────┬──────────────────────────────┬──────────────────────────────┬───────────┐
│   │ Resource                     │ Effect │ Action                       │ Principal                    │ Condition │
├───┼──────────────────────────────┼────────┼──────────────────────────────┼──────────────────────────────┼───────────┤
│ + │ ${Custom::S3AutoDeleteObject │ Allow  │ sts:AssumeRole               │ Service:lambda.amazonaws.com │           │
│   │ sCustomResourceProvider/Role │        │                              │                              │           │
│   │ .Arn}                        │        │                              │                              │           │
├───┼──────────────────────────────┼────────┼──────────────────────────────┼──────────────────────────────┼───────────┤
│ + │ ${MyFirstBucket.Arn}         │ Allow  │ s3:DeleteObject*             │ {aws}:${Custom::S3AutoDeleteOb │           │
│   │ ${MyFirstBucket.Arn}/*       │        │ s3:GetBucket*                │ jectsCustomResourceProvider/ │           │
│   │                              │        │ s3:GetObject*                │ Role.Arn}                    │           │
│   │                              │        │ s3:List*                     │                              │           │
└───┴──────────────────────────────┴────────┴──────────────────────────────┴──────────────────────────────┴───────────┘
IAM Policy Changes
┌───┬────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────┐
│   │ Resource                                               │ Managed Policy ARN                                     │
├───┼────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────┤
│ + │ ${Custom::S3AutoDeleteObjectsCustomResourceProvider/Ro │ {"Fn::Sub":"arn:${{aws}::Partition}:iam::aws:policy/serv │
│   │ le}                                                    │ ice-role/AWSLambdaBasicExecutionRole"}                 │
└───┴────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────┘
(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299)

Parameters
[+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/S3Bucket AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392S3BucketBF7A7F3F: {"Type":"String","Description":"S3 bucket for asset \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""}
[+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/S3VersionKey AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392S3VersionKeyFAF93626: {"Type":"String","Description":"S3 key for asset version \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""}
[+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/ArtifactHash AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392ArtifactHashE56CD69A: {"Type":"String","Description":"Artifact hash for asset \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""}

Resources
[+] {aws}::S3::BucketPolicy MyFirstBucket/Policy MyFirstBucketPolicy3243DEFD
[+] Custom::S3AutoDeleteObjects MyFirstBucket/AutoDeleteObjectsCustomResource MyFirstBucketAutoDeleteObjectsCustomResourceC52FCF6E
[+] {aws}::IAM::Role Custom::S3AutoDeleteObjectsCustomResourceProvider/Role CustomS3AutoDeleteObjectsCustomResourceProviderRole3B1BD092
[+] {aws}::Lambda::Function Custom::S3AutoDeleteObjectsCustomResourceProvider/Handler CustomS3AutoDeleteObjectsCustomResourceProviderHandler9D90184F
[~] {aws}::S3::Bucket MyFirstBucket MyFirstBucketB8884501
 ├─ [~] DeletionPolicy
 │   ├─ [-] Retain
 │   └─ [+] Delete
 └─ [~] UpdateReplacePolicy
     ├─ [-] Retain
     └─ [+] Delete

Para comparar as pilhas da sua aplicação com a implantação existente:

cdk diff MyStack

Para comparar as pilhas da sua aplicação com um modelo salvo do CloudFormation:

cdk diff --template ~/stacks/MyStack.old MyStack

Importar recursos existentes para uma pilha

É possível usar o comando cdk import para colocar os recursos sob o gerenciamento do CloudFormation para uma pilha do AWS CDK específica. Isso é útil se você estiver migrando para o AWS CDK ou movendo recursos entre pilhas ou alterando seu ID lógico. cdk import usa Importações de recursos do CloudFormation. Veja a lista de recursos que podem ser importados aqui.

Para importar um recurso existente em uma pilha do AWS CDK, siga as etapas a seguir:

Atualmente, esse atributo não oferece suporte à importação de recursos para pilhas aninhadas.

Configuração (cdk.json)

Os valores padrão de muitos sinalizadores de linha de comandos da CLI do CDK podem ser armazenados no arquivo cdk.json de um projeto ou no arquivo .cdk.json do seu diretório de usuário. A seguir, é apresentada uma referência alfabética às configurações compatíveis.