Infraestrutura como Código na AWS: Terraform vs CloudFormation vs CDK

Toda empresa que já apagou um recurso de produção sem querer, ou que já não conseguiu explicar por que um ambiente de homologação ficou diferente do de produção, esbarrou no mesmo problema: infraestrutura configurada manualmente, clique por clique no console, não é reproduzível nem auditável. É esse o problema que a Infraestrutura como Código (IaC) resolve — e na AWS, a decisão não é "se" adotar IaC, é qual das três ferramentas dominantes usar: o nativo AWS CloudFormation, o multi-cloud Terraform, ou o AWS CDK, que escreve infraestrutura em linguagem de programação de verdade. Este guia compara as três em profundidade, com os critérios que realmente pesam na decisão — linguagem, portabilidade, gestão de estado, curva de aprendizado e custo — e mostra onde a IaC se encaixa no fluxo mais amplo de entrega de software, antes do deploy da aplicação em si.

O Que É Infraestrutura como Código e Por Que Ela Importa

Infraestrutura como Código é a prática de definir servidores, redes, bancos de dados e qualquer outro recurso de nuvem em arquivos de configuração versionáveis, em vez de criá-los manualmente no console ou por uma sequência de comandos ad-hoc. O arquivo descreve o estado desejado da infraestrutura; uma ferramenta de IaC compara esse estado desejado com o que existe hoje na conta AWS e aplica só as mudanças necessárias.

O motivador central é o drift — a divergência silenciosa entre o que a documentação diz que existe e o que realmente está rodando. Drift acontece porque alguém abriu o console numa emergência, mudou uma regra de security group e nunca documentou aquilo. Com IaC, a mudança entra no mesmo arquivo versionado que descreve o resto da infraestrutura, e o histórico do Git mostra exatamente quem mudou o quê e quando.

Três ganhos concretos justificam o investimento em aprender uma ferramenta de IaC:

Reprodutibilidade — recriar um ambiente inteiro (homologação, DR, uma nova região) a partir do mesmo código-fonte, sem depender de um checklist manual que alguém preencheu errado.

Versionamento e revisão — toda mudança de infraestrutura passa por pull request, revisão de código e histórico auditável, o mesmo rigor que já se aplica ao código da aplicação.

Automação seguindo o mesmo padrão do CI/CD — a IaC provisiona a infraestrutura (a VPC, o cluster, o banco de dados); o pipeline de CI/CD faz o deploy da aplicação em cima dela. São etapas complementares de uma mesma esteira, não a mesma coisa — um erro comum é tratar "automação" como um bloco único e misturar as duas responsabilidades no mesmo pipeline, dificultando saber o que quebrou quando algo falha.

AWS CloudFormation: a Ferramenta Nativa da AWS

O AWS CloudFormation é o serviço de IaC nativo da AWS: você descreve os recursos desejados em um template YAML ou JSON, e o CloudFormation provisiona, atualiza e — se necessário — reverte essa infraestrutura como uma unidade chamada stack. A documentação oficial resume bem o valor central: em vez de criar e configurar cada recurso individualmente e descobrir manualmente as dependências entre eles, o CloudFormation cuida disso por você.

Sem custo adicional pela ferramenta em si — o CloudFormation não cobra por usar o serviço; você paga apenas pelos recursos AWS que ele provisiona (EC2, RDS, e assim por diante), o que o torna a opção mais barata em uma comparação estrita de custo da ferramenta.

Integração nativa profunda — como é mantido pela própria AWS, o CloudFormation costuma suportar recursos novos do catálogo AWS no mesmo lançamento ou muito próximo dele, sem depender de um provider de terceiros ser atualizado.

State gerenciado pela AWS — diferente do Terraform, você não precisa se preocupar em armazenar e proteger um arquivo de state à parte: a AWS mantém o estado da stack internamente.

O trade-off é a rigidez da sintaxe declarativa pura: templates grandes em YAML/JSON ficam verbosos, sem laços de repetição nativos nem funções condicionais ricas — para reuso, o caminho é módulos separados (nested stacks) ou macros, que adicionam complexidade própria.

Terraform: o Padrão Multi-Cloud da HashiCorp

O Terraform é a ferramenta de IaC criada pela HashiCorp e escrita em HCL (HashiCorp Configuration Language), uma linguagem declarativa própria pensada para ser legível por humanos. A diferença estrutural em relação ao CloudFormation é o modelo de providers: o Terraform tem milhares de providers disponíveis, o que permite descrever recursos da AWS, Azure, Google Cloud, Kubernetes, GitHub e dezenas de outros serviços na mesma configuração — é essa portabilidade multi-cloud que faz muitas empresas com pegada em mais de um provedor, ou que só querem evitar lock-in de ferramenta, escolherem Terraform em vez do CloudFormation.

State file como fonte da verdade — o Terraform mantém um arquivo de state que registra o mapeamento entre a configuração declarada e os recursos reais provisionados. Esse arquivo precisa ser armazenado de forma segura e compartilhada entre a equipe (tipicamente em um backend remoto, como um bucket S3 com trava de concorrência) — um erro comum em times que começam com Terraform é deixar o state local na máquina de um único desenvolvedor, o que trava qualquer colaboração e cria risco real de perda de estado.

Ecossistema maduro e amplo — módulos prontos no Terraform Registry, ampla documentação da comunidade, e integração de primeira classe com praticamente qualquer ferramenta de CI/CD do mercado.

Vale registrar dois eventos recentes que mudaram o cenário em torno do Terraform: em agosto de 2023, a HashiCorp relicenciou o Terraform para a Business Source License (BSL), deixando de ser open source no sentido estrito da OSI — o que levou parte da comunidade a criar o fork OpenTofu, hoje sob a Linux Foundation, mantendo a licença aberta original. Depois, em fevereiro de 2025, a IBM concluiu a aquisição da HashiCorp, o que passou a levantar perguntas sobre o roadmap de longo prazo do produto — não é motivo para não usar Terraform hoje, mas é um fator que empresas mais conservadoras avaliam ao decidir entre Terraform e OpenTofu para um projeto novo.

AWS CDK: Infraestrutura Escrita em Linguagem de Programação de Verdade

O AWS Cloud Development Kit (CDK) resolve a IaC de um jeito estruturalmente diferente dos dois anteriores: em vez de uma linguagem declarativa própria, você escreve a infraestrutura em uma linguagem de programação de propósito geral — TypeScript, Python, Java, C#/.NET ou Go, segundo a documentação oficial — usando laços, condicionais, funções e classes como em qualquer outro código. O CDK então sintetiza esse código em um template CloudFormation padrão, que é o que efetivamente provisiona os recursos — ou seja, o CDK roda por cima do CloudFormation, não o substitui.

Constructs como unidade de reuso — a AWS CDK Construct Library oferece componentes de alto nível com padrões seguros por padrão (ex.: um construct de "serviço Fargate atrás de um load balancer" que já inclui VPC, cluster, listener e security groups configurados corretamente), reduzindo dezenas de recursos CloudFormation a poucas linhas de código. Times podem publicar seus próprios constructs internos no Construct Hub para reaproveitar padrões entre squads.

A mesma linguagem do time de aplicação — para uma equipe que já programa em TypeScript ou Python no dia a dia, o CDK elimina a troca de contexto entre "escrever aplicação" e "escrever infraestrutura", e permite usar testes unitários, revisão de código e IDE com autocomplete da mesma forma que já usa para a aplicação.

O trade-off do CDK é a curva de abstração adicional: um erro na lógica do programa (um laço que gera recursos a mais, uma condição mal escrita) só aparece no template CloudFormation sintetizado, exigindo o hábito de sempre revisar o diff gerado antes de aplicar — a mesma disciplina de terraform plan, mas em uma etapa a mais no processo.

Terraform vs CloudFormation vs CDK: Comparação Direta

Não existe ferramenta "melhor" de forma absoluta — a escolha certa depende do que a equipe já sabe operar, se a empresa é mono-cloud ou multi-cloud, e do apetite por uma camada extra de abstração:

Na prática, muitas empresas não usam uma ferramenta isolada — times multi-cloud tendem a Terraform por padrão; times AWS-first com forte cultura de engenharia de software tendem a CDK; e equipes menores, com escopo simples e só AWS, muitas vezes ficam bem servidas só com CloudFormation, sem precisar da complexidade adicional de nenhuma das outras duas.

Como a IaC se Encaixa no Fluxo de CI/CD

IaC e CI/CD resolvem problemas diferentes e complementares, e é comum confundir os dois quando se está começando: a IaC provisiona a infraestrutura — a VPC, o cluster ECS ou EKS, o banco RDS, as filas SQS; o CI/CD faz o deploy da aplicação em cima dessa infraestrutura já existente — builda a imagem, roda os testes, publica a nova versão do código.

O guia de CI/CD Avançado na AWS já cobre em detalhe como estruturar pipelines com CodePipeline e CodeBuild, e estratégias de deploy Blue-Green e Canary para a aplicação em si. A conexão entre os dois temas acontece de duas formas na prática:

Pipeline de infraestrutura separado do pipeline de aplicação — um pipeline dedicado roda terraform plan/apply (ou cdk diff/deploy, ou publica uma stack CloudFormation) sempre que a definição de infraestrutura muda, tipicamente com menos frequência e mais governança do que o deploy de aplicação, que pode acontecer várias vezes ao dia.

Revisão do plano antes do apply, dentro do próprio pipeline — assim como um deploy de aplicação passa por testes automatizados antes de ir para produção, uma mudança de infraestrutura deveria passar por uma etapa que mostra exatamente o que vai ser criado, alterado ou destruído, com um gate de aprovação humana antes do apply em produção — a mesma lógica de um deploy Blue-Green, aplicada à camada de infraestrutura.

Boas Práticas de Infraestrutura como Código na AWS

Algumas práticas separam um uso maduro de IaC de um projeto que vira dívida técnica em poucos meses:

Modularize desde o início — módulos Terraform, nested stacks no CloudFormation, ou constructs reutilizáveis no CDK evitam que cada novo ambiente seja copiado e colado do anterior, com pequenas divergências acumulando ao longo do tempo.

State remoto, com trava de concorrência, no Terraform — um backend remoto (S3 com DynamoDB para locking, ou Terraform Cloud) evita o cenário clássico de dois desenvolvedores aplicando mudanças conflitantes ao mesmo tempo e corrompendo o state.

Sempre revise o plano antes do apply — terraform plan, cdk diff ou a mudança de change set no CloudFormation existem exatamente para isso: nenhuma mudança de infraestrutura em produção deveria ser aplicada sem alguém ter lido, linha por linha, o que vai mudar.

Separe ambientes por conta ou por workspace, nunca só por nome de recurso — misturar produção e homologação na mesma conta AWS, diferenciando só pelo prefixo do nome, é um erro comum que aumenta drasticamente o raio de impacto de um erro de configuração. Uma Landing Zone com AWS Organizations bem estruturada resolve isso na base, com contas separadas por ambiente desde o início.

Trate o código de infraestrutura com o mesmo rigor do código de aplicação — revisão obrigatória por pull request, testes automatizados (como checkov ou tflint para validação estática), e nunca aplicar uma mudança direto da máquina local em produção.

Casos de Uso por Porte de Empresa

A ferramenta certa muda conforme o tamanho e a maturidade da operação:

Empresas pequenas, só AWS, poucos ambientes — CloudFormation costuma ser suficiente: zero custo adicional, sem outra ferramenta para instalar, e a curva de aprendizado fica concentrada só na sintaxe do template.

Empresas em crescimento com múltiplos ambientes e alguma perspectiva multi-cloud — Terraform tende a compensar o investimento na curva de aprendizado, especialmente se a empresa já usa outros serviços fora da AWS (Cloudflare, Datadog, GitHub) que também têm provider Terraform, unificando a IaC de toda a stack em um só lugar.

Empresas com engenharia de software madura, times grandes de desenvolvimento — o CDK tende a ganhar tração quando já existe disciplina forte de testes, revisão de código e CI/CD para aplicação, e o time quer aplicar essa mesma disciplina à infraestrutura, na mesma linguagem que já domina.

Para empresas de 30 a 700 funcionários que estão estruturando a primeira esteira de IaC do zero, um erro recorrente é escolher a ferramenta pela popularidade no mercado, sem considerar o que a equipe interna já sabe operar — o custo de aprendizado errado, multiplicado por dezenas de ambientes recriados do zero, costuma superar de longe a diferença teórica entre as ferramentas. Um parceiro de consultoria AWS com experiência nas três opções ajuda a evitar essa escolha por modismo.

O Futuro da Infraestrutura como Código na AWS

A tendência mais clara é a convergência entre IaC e as mesmas práticas de engenharia de software já consolidadas para aplicação: testes automatizados de infraestrutura, policy-as-code (regras que bloqueiam automaticamente um plano que viole um padrão de segurança ou de custo), e cada vez mais integração entre a etapa de IaC e a disciplina de FinOps — prever o custo de uma mudança de infraestrutura antes mesmo de aplicá-la, direto no pipeline.

No lado do ecossistema, a disputa entre Terraform e OpenTofu após a mudança de licença de 2023 e a aquisição pela IBM em 2025 ainda está se acomodando, e é razoável esperar mais empresas avaliando as duas opções lado a lado nos próximos anos. Já o AWS CDK continua ganhando terreno em organizações AWS-first que já têm cultura forte de software, especialmente à medida que mais serviços novos da AWS chegam com constructs de alto nível prontos no dia do lançamento.

Perguntas Frequentes sobre Infraestrutura como Código na AWS

Preciso escolher só uma ferramenta de IaC para toda a empresa?

Não necessariamente, mas é recomendável evitar fragmentação excessiva. É comum uma empresa padronizar em uma ferramenta principal (por exemplo, Terraform) e usar CloudFormation ou CDK pontualmente para um caso específico — o risco é ter três ferramentas diferentes gerenciando a mesma stack sem nenhum critério, o que dificulta saber qual delas é a fonte da verdade de cada recurso.

Terraform e AWS CDK podem ser usados juntos?

Tecnicamente sim — dá para o Terraform provisionar a infraestrutura de rede e conta, por exemplo, enquanto o CDK cuida de uma aplicação específica. Mas essa combinação exige definir claramente os limites de responsabilidade de cada ferramenta, porque nenhuma das duas enxerga o que a outra provisionou, o que pode gerar recursos duplicados ou conflitantes sem essa fronteira bem definida.

O AWS CDK substitui o CloudFormation?

Não. O CDK sintetiza o código escrito em TypeScript, Python ou outra linguagem suportada em um template CloudFormation padrão, que é o que realmente provisiona os recursos. O CDK é uma camada de abstração sobre o CloudFormation, não uma alternativa a ele.

É seguro guardar o state file do Terraform no mesmo repositório Git do código?

Não é recomendado. O state pode conter dados sensíveis (como senhas geradas ou ARNs de recursos) em texto plano, e arquivos de state commitados no Git geram conflitos de merge constantes em times com mais de uma pessoa aplicando mudanças. O padrão é um backend remoto, como um bucket S3 com versionamento e criptografia habilitados.

O que é o OpenTofu e por que ele existe?

É um fork do Terraform, criado pela comunidade em resposta à mudança de licença da HashiCorp para Business Source License em agosto de 2023. O OpenTofu manteve a licença open source original e hoje é mantido sob a Linux Foundation, funcionando como alternativa para empresas que priorizam licenciamento aberto ou que ficaram cautelosas após a aquisição da HashiCorp pela IBM, concluída em fevereiro de 2025.

Qual ferramenta de IaC é mais barata?

Nenhuma das três cobra pela ferramenta em si no uso mais comum: CloudFormation e CDK não têm custo adicional além dos recursos AWS provisionados, e o Terraform CLI/open source também é gratuito — o custo aparece só se a empresa optar por um plano pago do Terraform Cloud/Enterprise para funcionalidades de colaboração e governança.

Vale a pena migrar um ambiente já em produção, criado manualmente, para IaC?

Sim, mas de forma gradual. A prática mais segura é começar "importando" a infraestrutura existente para o código (todas as três ferramentas têm mecanismos de import), em vez de recriar tudo do zero — o que evita janelas de indisponibilidade e reduz o risco de esquecer uma configuração fina que só existia na memória de quem criou o recurso originalmente.

Infraestrutura como Código Como Base de Qualquer Operação AWS Madura

Não existe jornada de maturidade em nuvem que dispense Infraestrutura como Código — a única pergunta real é qual ferramenta, ou combinação de ferramentas, melhor se encaixa no que a equipe já sabe operar e no quanto de portabilidade multi-cloud faz sentido para o negócio. CloudFormation resolve bem o caso simples e nativo; Terraform resolve o caso multi-cloud e multi-fornecedor; CDK resolve o caso de um time que já pensa em software e quer aplicar a mesma disciplina à infraestrutura.

As empresas que tratam a escolha da ferramenta de IaC como uma decisão de arquitetura — documentada, revisada e alinhada com o resto da esteira de entrega, incluindo o CI/CD que faz o deploy da aplicação — são as que conseguem escalar o número de ambientes e de squads sem multiplicar o caos operacional que a IaC deveria eliminar.

Artigos Relacionados

Para aprofundar em temas conectados à Infraestrutura como Código na AWS:

• CI/CD Avançado na AWS: Pipelines com CodePipeline, CodeBuild e Estratégias de Deploy Blue-Green/Canary — a etapa que consome a infraestrutura provisionada por IaC para fazer o deploy contínuo da aplicação.
• Landing Zone e AWS Organizations: Como Estruturar uma Arquitetura Multi-Conta Segura e Escalável — a base de contas separadas por ambiente sobre a qual a IaC provisiona cada stack.
• AWS Well-Architected Framework: o Guia Avançado — o pilar de Excelência Operacional reforça exatamente as práticas de automação e reprodutibilidade que a IaC viabiliza.
• FinOps AWS: o Guia Completo para Reduzir Custos na Nuvem — como prever e controlar o custo dos recursos que a infraestrutura como código provisiona.