Como criar infraestrutura como código com CDK

Infraestrutura como código significa descrever toda a sua cloud em arquivos versionados, revisáveis e reproduzíveis. Neste artigo, você vai entender por que clicar no console da AWS cria dívida técnica e como o CDK, o Terraform e o CloudFormation resolvem isso na prática.

O que é infraestrutura como código?

Infraestrutura como código (IaC) é a prática de descrever toda a sua infraestrutura de cloud em arquivos de código, tratada com o mesmo rigor de qualquer aplicação: versionamento, revisão, documentação e recriação com um comando. Em vez de clicar no console da AWS, você escreve um arquivo que declara o bucket S3, a função Lambda e as permissões, e a ferramenta aplica essa declaração no provedor.

O ganho central é a reprodutibilidade. Quando a stack inteira vive em código commitado no GitHub, qualquer pessoa do time consegue ler o que está em produção, propor uma mudança em pull request e recriar o ambiente idêntico do zero. Isso é impossível quando a configuração existe apenas na memória de quem clicou.

Vale separar dois mundos que costumam se confundir: a configuração declarativa em YAML (o formato mais comum em ferramentas como o CloudFormation) e o código imperativo em linguagens como TypeScript, que o AWS CDK usa para gerar essa declaração.

Por que configurar tudo pelo console da AWS dá problema?

Configurar recursos manualmente no console funciona para aprender, e é até recomendável no começo. O problema aparece quando a operação cresce: uma alteração feita no banco RDS de staging pode simplesmente nunca ser replicada em produção, porque nada registra que ela existiu.

Os riscos concretos do console manual são sempre os mesmos:

• A mudança não fica documentada em lugar nenhum, só no histórico de cliques de quem a fez.
• Ela não é revisável: ninguém aprova ou critica a alteração antes de ela entrar em produção.
• Ela não é reproduzível: recriar o ambiente exige lembrar de cada passo.
• Ela não é auditável: meses depois, ninguém sabe por que aquela configuração está ali.

Para uma startup de dois engenheiros, isso às vezes é aceitável. Para um projeto robusto, cada recurso criado à mão é dívida técnica que alguém vai pagar durante um incidente.

Quais ferramentas de infraestrutura como código existem?

Existe mais de uma família de ferramentas de infraestrutura como código, e a escolha depende do provedor, do formato que o time prefere e do histórico do projeto. As quatro mais citadas no ecossistema AWS são resumidas abaixo.

Ferramenta	Formato	Vínculo	Observação
Terraform	HCL (arquivos declarativos)	HashiCorp	Multi-cloud, a mais popular do mercado
OpenTofu	HCL	Comunidade, fork do Terraform	Alternativa livre após a mudança de licença do Terraform em 2023
AWS CloudFormation	YAML/JSON	Nativa da AWS	Organiza recursos em stacks direto no dashboard
AWS CDK	TypeScript, Python e outras	Nativa da AWS	Gera CloudFormation a partir de código

Existem também opções como o Pulumi, o Bicep (voltado ao Azure) e o próprio Kubernetes, que muita gente considera uma forma de IaC para workloads em contêineres.

Como o CDK da AWS funciona na prática?

O CDK inverte a lógica: em vez de escrever centenas de linhas de YAML, você escreve TypeScript que instancia constructos como aws_s3.Bucket ou aws_lambda.Function. O CDK interpreta esse código e sintetiza um template CloudFormation, que é o que de fato provisiona os recursos.

A stack e o app

Um app CDK agrupa uma ou mais stacks, e cada stack é um conjunto de recursos que sobem e descem juntos. O nome do projeto e o environment (dev, prod) ficam definidos no código, e você pode ramificar por variável de ambiente: o mesmo código cria um banco com backups resilientes em produção e um banco descartável em dev.

Um exemplo mínimo: S3 + Lambda

Uma stack simples cria um bucket e uma função que escreve nele. O bucket nasce de uma linha de TypeScript, e a permissão de escrita também: algo como bucket.grantWrite(helloFunction) descreve a política de IAM em uma linha, em vez de um documento JSON manual.

O código da função fica em um index.js comum, exportando um handler. A cada cdk deploy, o CDK empacota e atualiza esse código na Lambda, então aplicação e infraestrutura evoluem no mesmo fluxo de commit.

Como todo código TypeScript, você pode teoricamente chamar uma API externa e decidir em runtime se cria ou não um recurso. Funciona, mas evite: o objetivo é justamente que o resultado do deploy seja previsível e idêntico em toda execução.

Como fazer o primeiro deploy com CDK passo a passo?

O fluxo básico cabe em quatro passos, e cada um tem uma função clara no ciclo de vida da stack.

1. Configure as credenciais da AWS CLI: gere as chaves em Security Credentials no console e configure-as na sua máquina, para que o CDK saiba em qual conta trabalhar.
2. Defina a stack em TypeScript: crie o app com cdk init, instancie o bucket e a função desejados, e conecte as permissões entre eles.
3. Rode npx cdk deploy: o CDK sintetiza o CloudFormation, mostra a lista exata de mudanças que vão acontecer e pede sua confirmação antes de criar qualquer recurso.
4. Destrua quando quiser com npx cdk destroy: como tudo foi criado a partir do código, remover a stack inteira é seguro e limpo.

Um detalhe que pega iniciantes: a região. Se a região padrão da CLI não for a que você espera (por exemplo, eu-east-1 versus eu-west-1), os recursos nascem em outro lugar e você passa minutos procurando a função no console. Vale conferir a configuração antes do primeiro deploy.

Depois do deploy, você encontra a Lambda e o bucket no console normalmente, podendo testar a função direto de lá. A diferença é que, agora, aquilo tudo existe também no seu repositório.

Quais benefícios a IaC traz para times maduros?

O resultado prático de migrar para infraestrutura como código é que a infraestrutura passa a ter o mesmo ciclo de vida do software. O código vai para o GitHub, entra por pull request, recebe revisão e é aplicado por uma pipeline de CI/CD, não pela máquina de um engenheiro.

Com isso, você ganha de graça: debug em grupo, porque qualquer pessoa baixa o código e inspeciona o CloudFormation gerado; ambientes consistentes, porque dev e prod vêm do mesmo arquivo; e histórico completo, porque cada mudança tem autor, data e discussão associados no Git.

Não é à toa que empresas maduras tratam IaC como requisito, e não como diferencial. A curva de aprendizado existe, o próprio autor do vídeo conta que levou mais de um mês para se sentir confortável com CDK, mas ela se paga no primeiro incidente evitado.

Perguntas frequentes

• Preciso começar pelo console antes de usar infraestrutura como código? Não é obrigatório, mas ajuda. Entender o que a ferramenta faz por baixo dos panos torna o CDK e o Terraform menos opacos quando algo dá errado.

• CDK e CloudFormation são concorrentes? Não. O CDK gera templates CloudFormation a partir de código em TypeScript, Python ou outras linguagens. No fim, quem provisiona os recursos é sempre o CloudFormation.

• O Terraform ainda é open source? Não desde 2023, quando a HashiCorp mudou a licença. O OpenTofu é o fork mantido pela comunidade e hoje é a alternativa livre mais usada por quem quer manter o fluxo de trabalho do Terraform.

• Infraestrutura como código serve só para AWS? Não. O conceito vale para qualquer provedor: Azure tem Bicep, Google Cloud tem ferramentas próprias, e Terraform e OpenTofu funcionam com múltiplas clouds no mesmo projeto.

Transforme aulas em artigo com o Skala Blog

Este artigo nasceu de uma aula em vídeo sobre infraestrutura como código, e é exatamente esse tipo de conteúdo que merece existir também em texto: pesquisável, citável e legível em cinco minutos. Se você produz explicações técnicas no YouTube, o Skala Blog transforma a transcrição do seu vídeo em um artigo estruturado, pronto para revisar e publicar.

O fluxo é simples: você cola a URL do vídeo, o Skala Blog transcreve e gera o rascunho do artigo, e você refina antes de publicar. Visite skalablog.com e dê ao seu melhor conteúdo uma segunda vida em texto.

Source video