AWS CloudFormation (AWS nativo)

CloudFormation é o serviço de IaC nativo da AWS: você descreve os recursos em um template, JSON ou YAML, e o serviço transforma a declaração em uma stack, uma unidade de provisionamento, atualização e destruição executada pela própria AWS. Diferente de Terraform e Pulumi, não há ferramenta client executando chamadas de API: o motor roda no lado da nuvem, o que traz garantias de integração fortes, como visibilidade imediata de recursos novos, rollback automático em falha de criação e acoplamento direto com IAM, Service Catalog e organizações multi-conta. Para operações 100 por cento AWS, CloudFormation permanece escolha sólida e, em vários cenários corporativos, requisito de compliance, pois todo recurso criado nasce dentro de um rastro de stack nativo. O custo da escolha é a portabilidade: o template só serve para AWS, e o fluxo de trabalho não se transfere para outra nuvem. Este arquivo cobre a anatomia dos templates, o ciclo de vida de stacks e change sets, drift detection, StackSets e a comparação direta com Terraform.

Conceito: o template como contrato com a AWS

Um template CloudFormation descreve recursos no formato do serviço, com blocos Parameters para entradas, Conditions para lógica declarativa, Resources para o que será criado, Outputs para resultados e Mappings para tabelas de lookup. O template é a fonte de verdade da stack: a AWS guarda a versão aplicada, e toda atualização é um diff calculado pelo serviço contra o template novo. Não existe state externo para proteger, pois o estado é mantido pelo próprio serviço.

O modelo de unidades é a stack. Todos os recursos de uma stack nascem, evoluem e morrem juntos, e a identidade da stack aparece em tags, event logs e no console. Essa coesão é a grande força do desenho, pois rollback e remoção são atômicos por stack, e também a grande armadilha, pois stack gigante é acoplamento gigante, e o particionamento de stacks é uma das decisões mais importantes de quem adota o serviço.

A mudança declarativa segue o mesmo espírito do IaC em geral: você atualiza o template e o serviço calcula o que precisa criar, alterar ou substituir. O detalhe fino é o conjunto de update policies por recurso, que permite controlar se uma alteração pode acontecer in-place ou exige substituição, e em qual janela a substituição pode acontecer em cargas com Auto Scaling.

Templates JSON e YAML: anatomia do documento

O formato JSON é o original, e o YAML é o dominante na prática por legibilidade e por comentários. Funções intrínsecas, !Ref, !Sub, !GetAtt, !Join, !Select, fazem a interpolação dentro do documento: referências a parâmetros, atributos de outros recursos, strings compostas com região e conta. A expressividade é menor que HCL e muito menor que linguagens de programação, o que empurra desenho complexo para geração externa de template, tema que retorna na comparação final.

Parâmetros tipados, com restrições e valores permitidos, são o mecanismo de reuso: o mesmo template cria a stack de dev e a de produção com parâmetros diferentes. Outputs, por sua vez, expõem valores que outras stacks consomem por export e Fn::ImportValue, formando uma malha de dependências explícitas entre stacks, que é a alternativa CloudFormation ao grafo de dependências do Terraform.

A biblioteca de recursos acompanha a AWS de perto: recursos novos geralmente nascem com suporte no CloudFormation no mesmo ritmo ou poucos dias depois. Para recursos ainda não suportados, o hook de escape é o recurso custom, funções Lambda chamadas pela stack, que devolve flexibilidade ao preço de lógica própria a manter, monitorar e proteger.

O desenho do repositório de templates segue a disciplina de qualquer IaC: versionamento, revisão de PR e pipeline que valida com aws cloudformation validate-template ou com lint dedicado antes de qualquer deploy. Como o documento é estático, a validação estática tem limite; lógica condicional complexa vive em Conditions e funções intrínsecas, e templates que ficam ilegíveis são o sinal de que o time precisa de geração de template ou de mudar de ferramenta.

# Template CloudFormation: bucket versionado e criptografado por ambiente
AWSTemplateFormatVersion: "2010-09-09"
Description: Bucket de arquivos com versionamento e criptografia

Parameters:
  Ambiente:                      # parâmetro explícito por stack
    Type: String
    Default: producao
    AllowedValues: [producao, staging]

Resources:
  BucketArquivos:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "arquivos-${Ambiente}-${AWS::AccountId}"
      VersioningConfiguration:
        Status: Enabled
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      Tags:
        - Key: ManagedBy
          Value: cloudformation

Outputs:
  BucketNome:
    Value: !Ref BucketArquivos   # saída consumida por outras stacks
    Export:
      Name: !Sub "bucket-arquivos-${Ambiente}"

Stacks, change sets e o ciclo de vida

A stack nasce com create-stack, evolui com update-stack e morre com delete-stack, e o evento de cada operação fica registrado em stack events com status por recurso. Em produção, o caminho correto para atualizar é o change set: a AWS calcula o diff proposto pelo template novo, você revisa as operações exatas, criações, alterações, substituições, e só então executa. O change set é a versão CloudFormation do plan, e ignorá-lo é programar substituição acidental de recursos de banco.

O rollback automático é comportamento padrão e importante de configurar consciente: em falha de criação, a stack reverte e apaga o que já criou; em falha de atualização, reverte para o template anterior. O mecanismo protege produção de estados parciais, mas esconde detalhes do erro na saída, e a prática saudável é inspecionar os eventos da stack e os logs dos recursos envolvidos antes de repetir a operação.

A organização de stacks em produção tem dois eixos: por ciclo de vida, redes separadas de aplicações, e por domínio, cada produto com a sua stack. O eixo de ciclo de vida reduz o blast radius de cada atualização; o eixo de domínio preserva a autonomia dos times. A combinação usual no nível corporativo é fundação de rede e segurança em stacks centrais governadas pela plataforma, e stacks de domínio em catálogo para os times de produto.

# Change set: revisar antes de executar
aws cloudformation create-change-set \
  --stack-name producao-core \
  --template-body file://template.yaml \
  --change-set-name mudanca-42

aws cloudformation describe-change-set \
  --change-set-name mudanca-42 --stack-name producao-core

aws cloudformation execute-change-set \
  --change-set-name mudanca-42 --stack-name producao-core

Drift detection

Drift detection pergunta, por recurso, se a configuração real da AWS diverge do template aplicado, e produz um relatório por propriedade com status in sync, modified ou deleted. A detecção é nativa, não exige ferramenta externa, e cobre o cenário clássico de operação AWS: alguém alterou um security group ou uma regra de lifecycle pelo console, e agora a stack mente sobre a realidade.

O comportamento importante é o que a detecção não faz: ela não corrige, apenas reporta. A política de resposta pertence à operação. A divergência aceita, como tag ajustada manualmente por urgência, precisa entrar no template na próxima janela; a divergência indevida, como porta aberta no console, precisa ser revertida. Sem essa disciplina, drift detection vira relatório ignorado, e a stack perde a credibilidade de fonte de verdade.

A integração com auditoria é o diferencial operacional: como a detecção é serviço nativo, ela se encaixa em frameworks de governança AWS, Config, GuardDuty e políticas de organização, sem ferramenta extra. Times grandes executam detecção programada nas stacks críticas e encaminham desvios para fila de triagem, tratando drift como incidente classificável, na mesma linha que o restante deste módulo já defendeu.

Um detalhe de escopo merece registro: drift detection só cobre o que a stack declara. Recursos criados fora de qualquer template, o clássico recurso fantasma, não aparecem em nenhum relatório, pois nenhuma stack os conhece. Por isso a política de acesso ao console precisa limitar a criação de recursos a canais governados, e ferramentas de inventário comparam o que existe na conta com o que as stacks declaram.

StackSets: deploy multi-conta e multi-região

StackSets estende o modelo de stack para escala de organização: um template, criado como stack set, é instanciado como stack instances em dezenas de contas e regiões de uma vez, com controle de quais contas participam por OU da AWS Organizations. É o mecanismo canônico para bases de plataforma: roles de CI, agentes de monitoramento, configuração de GuardDuty e CloudTrail em cada conta nova da organização.

O modelo de permissões é o detalhe que decide a adoção: um role de administração na conta central assume um role de execução em cada conta alvo, e a separação entre quem manda e quem executa é audível em IAM. Deploy gradual, por conta e por região, com tolerância de falha configurável, permite rollout controlado: se a instância falha em três contas, a operação pausa antes de espalhar o problema.

StackSets resolve o problema que, em Terraform, exigiria loops de assume-role e backend por conta. Em contrapartida, acopla a operação ao modelo de organização AWS, e times que precisam do mesmo desenho em outra nuvem não aproveitam nada do esforço. Para plataforma puramente AWS, multi-conta com governança central, o recorte é quase sempre vencedor.

Integração nativa: IAM, Service Catalog e o ecossistema AWS

A integração com IAM é estrutural: toda operação de stack roda sob uma role, e essa role limita o que a stack pode criar e alterar, o que permite desenhar papéis de menor privilégio por domínio, a stack do domínio de rede só toca recursos de rede. Combinada com CloudTrail, essa propriedade dá auditoria de ponta a ponta sem ferramenta adicional, um diferencial frente a ferramentas externas que usam credenciais amplas.

O AWS Service Catalog constrói sobre CloudFormation a camada de catálogo corporativo: produtos são templates aprovados pela plataforma, com versionamento, parâmetros restritos e constraint de quem pode lançar o quê. O time de produto lança uma stack padronizada a partir do catálogo, herdando desenho de segurança e tags obrigatórias, e a autonomia não vira anarquia; é o modelo de governança por plataforma que muitas empresas buscam.

Complementam o quadro o resource import, para trazer recursos criados fora do serviço para dentro de uma stack, e os hooks e policies de stack, para travar destruição de recursos críticos. O conjunto forma uma plataforma de IaC mais completa que a soma das ferramentas externas, desde que a operação inteira esteja disposta a viver dentro da AWS.

Comparação com Terraform

A leitura de decisão é simples quando o contexto é simples e sutil quando não é. Operação puramente AWS com governança centralizada e muitas contas tende ao CloudFormation, e ganha rollback automático, StackSets e auditoria nativa. Operação multicloud, ou time que valoriza fluxo único e ecossistema de módulos, tende ao Terraform. Muitas empresas grandes usam os dois: CloudFormation para plataforma e catálogo, Terraform para o que cruza fronteiras de nuvem e SaaS.

Erros comuns e boas práticas

• Atualizar stack sem change set em produção; o diff não revisado esconde substituições de banco e filas, e o rollback automático não desfaz perda de dados.
• Construir stacks gigantes com dezenas de recursos acoplados; particione por ciclo de vida e por domínio, e use exports para dependências entre stacks.
• Deixar drift acumulado sem política de resposta; execute detecção programada nas stacks críticas e trate desvio como incidente a classificar.
• Usar recursos custom para o que já tem suporte nativo; Lambda de suporte é superfície extra de falha, custo e segurança.
• Misturar mudanças manuais de IAM com stacks; permission boundaries e roles por stack mantêm o menor privilégio audível.
• Repetir o mesmo template com copiar e colar entre contas; StackSets com parâmetros existe exatamente para eliminar essa duplicação.
• Ignorar versionamento de templates; template sem tag de release e sem changelog destrói a rastreabilidade que o serviço promete.
• Assumir que rollback automático restaura dados; rollback restaura infraestrutura, e dados perdidos em operação errada continuam perdidos.