Se voce e novo no AWS, a frase "gerenciar infraestrutura como codigo" pode soar abstrata. Este guia explica o que e o CloudFormation, por que ele existe e como funciona, usando analogias do cotidiano para que qualquer pessoa possa entender.
O que e CloudFormation?
Pense em construir uma casa. Nenhum construtor experiente comeca a colocar tijolos sem um projeto primeiro. O projeto diz a todos onde ficam os comodos, onde estao as portas, e permite construir casas identicas a partir do mesmo design.
O CloudFormation e o projeto para sua infraestrutura na AWS. Voce escreve um arquivo de modelo que descreve tudo o que voce precisa — servidores EC2, armazenamento S3, bancos de dados, regras de rede — e o CloudFormation le esse arquivo e cria automaticamente todos esses recursos.
Isso e o que significa IaC (Infraestrutura como Codigo): em vez de clicar no console da AWS para configurar as coisas manualmente, voce descreve o que quer em um arquivo de texto, e o sistema constroi por voce.
Por que isso importa? Imagine que voce tem uma loja online. Voce precisa de tres ambientes separados: desenvolvimento, onde os engenheiros testam novos recursos; staging, onde voce faz as verificacoes finais; e producao, onde os clientes reais compram. Configurar cada um manualmente leva horas e e facil esquecer algum detalhe. Com o CloudFormation, voce implanta a partir do mesmo modelo sempre, e os tres ambientes sao garantidamente identicos.
As secoes principais de um modelo
Um modelo CloudFormation e um arquivo YAML ou JSON organizado em secoes, como os capitulos de um livro de receitas.
| Secao | Funcao | Exemplo | |-------|--------|---------| | Parameters | Valores fornecidos no momento da implantacao | Tipo de instancia, nome do ambiente | | Mappings | Tabelas de consulta para valores condicionais | IDs de AMI diferentes por regiao | | Resources | Os recursos AWS a serem criados (a unica secao obrigatoria) | Instancia EC2, bucket S3, banco de dados RDS | | Outputs | Valores exportados apos a criacao da stack | Nome DNS do balanceador de carga | | Conditions | Regras para decidir se criar certos recursos | Criar um NAT Gateway somente em producao |
Uma analogia de receita ajuda aqui. Parameters sao como "quantas porcoes voce quer fazer". Mappings sao como "a lista de ingredientes varia por pais". Resources sao os passos reais de cozimento. Outputs sao "em qual prato voce serve isso". Conditions sao "se for uma festa, adicione a decoracao".
Dica de exame: apenas a secao Resources e obrigatoria. Todas as outras sao opcionais. O padrao de usar Parameters para entrada, Mappings para buscar valores especificos de regiao e Conditions para criar recursos conforme o ambiente aparece com frequencia.
Change Sets — Visualizar antes de confirmar
Quando voce compra online, revisa o carrinho antes de clicar em "Pagar". Os Change Sets funcionam da mesma forma para mudancas de infraestrutura na AWS.
Imagine este cenario: voce modificou seu modelo CloudFormation para alterar uma regra de grupo de seguranca no seu servidor em execucao. Mas nao tem certeza se essa mudanca vai reiniciar seu banco de dados ou apenas atualizar uma configuracao silenciosamente. Crie um Change Set e o CloudFormation mostrara uma lista: "este recurso sera modificado, aquele recurso sera substituido, este outro recurso sera excluido". Voce pode revisar com calma antes de decidir.
Criar um Change Set nao aplica nenhuma mudanca. Nada acontece ate voce clicar em "Execute". Se nao gostar do que ver, simplesmente exclua o Change Set e nada foi alterado.
Dica de exame: "Voce quer revisar o impacto de uma atualizacao de infraestrutura antes de acontecer" — a resposta e Change Sets.
Stack Policies — Protegendo recursos criticos
Imagine que voce tem um banco de dados de producao com anos de pedidos de clientes. Voce quer garantir que ninguem o exclua ou substitua acidentalmente ao atualizar a stack do CloudFormation. As Stack Policies dao essa protecao.
Uma Stack Policy e um conjunto de regras anexadas a uma stack do CloudFormation que controla quais recursos podem ser atualizados. E como colocar uma fechadura dupla em um cofre bancario. Uma vez que uma Stack Policy esta em vigor, apenas os recursos explicitamente listados como "permitidos para atualizar" podem ser alterados — todo o resto esta protegido.
Um comportamento importante a lembrar: uma Stack Policy nao pode ser completamente removida apos ser definida. No entanto, voce pode substitui-la por uma politica que permita todas as atualizacoes, o que efetivamente remove a restricao.
Dica de exame: "Proteger um recurso critico como um banco de dados RDS de modificacao acidental" — a resposta e Stack Policy.
Drift Detection — Encontrando mudancas nao autorizadas
Voce construiu cuidadosamente sua infraestrutura com o CloudFormation. Entao um dia um colega faz login no console da AWS e altera manualmente uma regra de grupo de seguranca em uma instancia EC2. Agora o estado real do seu ambiente AWS nao corresponde mais ao seu modelo CloudFormation. Essa lacuna entre o modelo e a realidade e chamada de "drift".
O drift e como ter um projeto de edificio que diz que ha tres janelas, mas alguem adicionou uma quarta janela ao edificio real. O projeto esta desatualizado.
Quando voce executa o Drift Detection, o CloudFormation verifica a configuracao atual de cada recurso em relacao ao que o modelo diz que deveria ser. O resultado para cada recurso e IN_SYNC (corresponde ao modelo) ou DRIFTED (difere do modelo). Para recursos com drift, voce pode ver exatamente quais propriedades mudaram e quais sao os valores atuais versus os esperados.
Dica de exame: "Voce quer encontrar diferencas entre seu modelo CloudFormation e mudancas feitas manualmente no console" — a resposta e Drift Detection.
StackSets — Implantar em multiplas contas e regioes de uma vez
Sua empresa cresceu e agora tem quinze contas AWS, uma por equipe ou unidade de negocio. Voce precisa implantar a mesma linha de base de seguranca em todas. Entrar em cada conta e implantar separadamente levaria o dia todo. O StackSets resolve isso.
O StackSets permite implantar um unico modelo CloudFormation em multiplas contas AWS e multiplas regioes simultaneamente. Pense como a sede enviando o mesmo manual de operacoes para cada filial ao mesmo tempo.
Veja como funciona: voce cria um StackSet em sua conta de administrador, especifica as contas de destino ou as OUs do AWS Organizations, e o CloudFormation cria automaticamente uma instancia de stack em cada destino. Voce tambem pode configurar quantas contas sao implantadas simultaneamente e quantas falhas sao aceitaveis antes de a operacao parar.
Dica de exame: "Implantar a mesma stack CloudFormation em multiplas contas e regioes" — a resposta e StackSets.
Entendendo o estado ROLLBACK_COMPLETE
Se algo der errado enquanto o CloudFormation esta criando uma stack, ele tentara automaticamente fazer rollback, ou seja, tentara excluir os recursos que ja criou para que voce nao fique com uma implantacao parcial.
Mas e se o proprio rollback tambem falhar? A stack termina no estado ROLLBACK_COMPLETE. Este e um estado sem saida. Voce nao pode atualizar uma stack em ROLLBACK_COMPLETE. A unica acao disponivel e excluir a stack, corrigir o que causou a falha original e entao criar uma nova stack.
Causas comuns incluem permissoes IAM insuficientes, atingir limites de servico da AWS ou valores de parametros invalidos.
Dica de exame: "Como voce recupera uma stack no estado ROLLBACK_COMPLETE?" — exclua-a, corrija o erro e recrie do zero.
cfn-init, cfn-signal e CreationPolicy
Suponha que voce quer que o CloudFormation crie uma instancia EC2 e instale automaticamente o Apache e o PHP nela. Voce tambem quer que o CloudFormation aguarde ate que a instalacao seja concluida antes de declarar a stack criada com sucesso.
O cfn-init le uma secao de metadados no seu modelo que lista quais pacotes instalar, quais arquivos criar e quais servicos iniciar. Quando a instancia EC2 e iniciada, o cfn-init executa esses passos automaticamente.
O cfn-signal e um comando que voce coloca no final do seu script de instalacao. Quando a instalacao termina com sucesso, o cfn-signal envia uma mensagem de "pronto" de volta ao CloudFormation.
O CreationPolicy e uma configuracao no recurso que diz ao CloudFormation "nao marque este recurso como completo ate receber o sinal". Voce tambem especifica um tempo limite: se o sinal nao chegar dentro desse tempo, a criacao da stack falha.
Esses tres trabalham em equipe. O cfn-init faz o trabalho, o cfn-signal reporta a conclusao, e o CreationPolicy faz o CloudFormation aguardar o relatorio.
Nested Stacks e AWS CDK
A medida que sua aplicacao cresce, um unico modelo CloudFormation pode ter centenas de linhas e ser dificil de gerenciar. Os Nested Stacks resolvem isso dividindo um modelo grande em modulos reutilizaveis menores.
Por exemplo, voce pode ter uma stack de rede (VPC, sub-redes, roteamento), uma stack de seguranca (grupos de seguranca, roles IAM), uma stack de computacao (EC2, Auto Scaling) e uma stack de banco de dados (RDS). Uma stack pai referencia e monta todas estas. Cada stack individual pode ser reutilizada em outros projetos.
O AWS CDK (Cloud Development Kit) adota uma abordagem diferente. Em vez de escrever YAML ou JSON diretamente, voce escreve codigo de infraestrutura em Python, TypeScript, Java ou outras linguagens familiares. Quando voce executa o CDK, ele gera o modelo CloudFormation para voce. Desenvolvedores que se sentem a vontade programando tendem a achar o CDK mais rapido e menos propenso a erros do que escrever modelos manualmente.
Pontos-chave para o exame
"Visualizar o impacto de uma mudanca de infraestrutura antes de acontecer" -- Change Sets
"Encontrar diferencas entre o modelo e mudancas manuais no console" -- Drift Detection
"Implantar a mesma stack em multiplas contas e regioes" -- S