Quase todo projeto de nuvem começa errado do mesmo jeito: alguém cria um projeto no console, sobe uma máquina para testar, o teste vira piloto e o piloto vira produção. Seis meses depois existem trinta projetos sem padrão de nome, permissões em e-mails individuais, redes sobrepostas e uma fatura que ninguém explica. A landing zone é o oposto disso: a fundação da nuvem desenhada antes das aplicações, descrita em código e construída numa ordem que evita retrabalho.

Este artigo é o complemento prático do nosso texto sobre Terraform com IA, que trata do método e dos guarda-rails da infraestrutura como código. Aqui mostramos a sequência real de construção de uma fundação no Google Cloud: o que vem antes do quê, onde a IA ajuda de verdade e quais decisões de custo precisam nascer junto com a primeira linha de código.

Por que “landing zone” e não “cria um projeto e vamos ver”

O projeto isolado parece inofensivo porque não tem custo de decisão. O problema aparece quando ele precisa conviver com outros. Uma landing zone resolve quatro coisas de uma vez — e as quatro são caras de resolver na correria.

• Hierarquia. No GCP, organização, pastas e projetos não são cosmética: são o ponto em que políticas e permissões passam a ser herdadas. Uma organization policy que bloqueia IP externo, aplicada na pasta de produção, vale para tudo que nascer ali dentro — inclusive o projeto que alguém criar amanhã sem avisar.
• IAM desde o dia 1. O projeto avulso quase sempre nasce com um owner pessoal. Isso é dívida imediata: quando a pessoa sai da empresa, ninguém sabe o que quebra ao remover o acesso.
• Rede planejada. Faixas de IP se escolhem uma vez. Duas sub-redes sobrepostas impedem peering e só aparecem no dia em que o ambiente precisa conversar com o resto da empresa.
• Faturamento separado por ambiente. Produção, homologação e desenvolvimento em projetos distintos é o que torna o custo legível. Sem isso, qualquer conversa de FinOps começa com três semanas de arqueologia.

Além disso, com a fundação pronta, subir um ambiente novo deixa de ser projeto e vira execução de código.

A ordem de construção que evita retrabalho

A sequência abaixo não é estética: cada camada consome a saída da anterior, e inverter a ordem significa refazer.

1. Organização e pastas. Primeiro a árvore: pastas por ambiente (produção, não produção) e uma comum para rede, logs e ferramentas. É aqui que entram as organization policies que valem para sempre: regiões permitidas, proibição de chave estática, bloqueio de acesso público em storage.
2. Projetos por ambiente. Um projeto por ambiente e por domínio de responsabilidade, com nome padronizado e faturamento vinculado. Projeto é a unidade de cota, isolamento e custo do GCP — usar poucos “para simplificar” é o erro mais comum e o mais caro.
3. IAM com grupos, nunca usuário direto. As permissões vão para grupos do diretório corporativo, e as pessoas entram e saem dos grupos — papel em e-mail individual não é auditável na prática. Mesma regra para contas de serviço: escopo mínimo, uma por aplicação, com impersonation em vez de chave.
4. VPC e sub-redes. Aqui entra a VPC compartilhada: uma rede em projeto host, consumida pelos projetos de serviço, o que evita que cada aplicação invente a sua. Planeje as faixas com folga e guarde o plano de endereçamento no repositório, não em planilha.
5. Conectividade. Saída por Cloud NAT, para que a carga não precise de IP público; firewall por conta de serviço ou tag, não por faixa solta; e Private Service Connect quando houver banco gerenciado — banco com IP público é o achado recorrente de qualquer avaliação de segurança.
6. Workloads. Só agora entram Cloud Run ou GKE. A escolha é de operação, não de moda: Cloud Run cobra por requisição e some sem tráfego; GKE dá controle fino e cobra o cluster mesmo ocioso.
7. Observabilidade. Por fim, o que fecha o ciclo: log sinks centralizados em projeto próprio, retenção definida e alertas com destino real — não uma caixa de e-mail que ninguém lê.

O que a IA acelera aqui

Landing zone é trabalho repetitivo e estruturado — exatamente o feitio em que os assistentes de IA rendem. Quatro usos se pagam já no primeiro ambiente.

• Módulos reutilizáveis. Descrever “projeto padrão com APIs habilitadas, conta de serviço, rótulos obrigatórios e sink de log” e receber o módulo com variáveis e outputs tira o trabalho mecânico do caminho. O ganho real é a consistência: o quinto projeto sai igual ao primeiro.
• Revisão do plan procurando destruição. Em fundação, o perigo não é criar recurso a mais — é o plan propor recriar uma sub-rede porque alguém mexeu num atributo imutável. Um resumo do que será destruído ou forçado a recriar transforma centenas de linhas de diff numa lista curta para decidir.
• Documentação da landing zone. Tabela de projetos, plano de endereçamento e matriz de grupos e papéis, gerados do código real — e por isso ainda verdadeiros no mês seguinte.
• Converter desenho em código. Do diagrama para o primeiro esqueleto de módulos é onde a IA mais economiza tempo — desde que o desenho já traga as decisões de rede e hierarquia tomadas por gente.

Estado e segurança da própria fundação

O código que cria a nuvem inteira é o ativo mais sensível do ambiente. Três regras não se negociam.

Primeiro, o state vive em bucket dedicado, num projeto próprio de ferramentas, com versionamento ligado e bloqueio de concorrência. O versionamento permite voltar de um estado corrompido; o lock evita dois apply simultâneos destruindo o arquivo. O acesso é restrito: quem lê o state lê o inventário completo do ambiente.

Segundo, uma conta de serviço por pipeline, com o menor privilégio que ainda permita o trabalho — a identidade que aplica produção não é a que aplica desenvolvimento. Terceiro: nenhuma chave estática no repositório. A autenticação deve ser por federação de identidade, com credencial de vida curta emitida na hora. Chave de conta de serviço em arquivo JSON é o vazamento que mais aparece em auditoria — e a organization policy que proíbe criá-las deve estar ligada desde o primeiro dia.

FinOps desde a fundação

Custo não é assunto do sexto mês. Duas coisas nascem com a landing zone. A primeira são os rótulos obrigatórios — ambiente, centro de custo, aplicação, responsável — aplicados por módulo e barrados no pipeline quando faltarem: recurso sem rótulo é recurso que ninguém explica na fatura. A segunda é o orçamento com alerta por projeto, com limiares em percentuais e destinatário que acompanha.

E há uma lição de campo que vale mais que regra genérica. Numa avaliação de FinOps no Google Cloud para um cliente do setor de seguros, encontramos CUDs (committed use discounts, descontos por compromisso de uso de um a três anos) contratados para banco gerenciado com utilização praticamente nula, e compromissos flexíveis de computação consumidos em menos da metade. O desconto existia no papel; o gasto continuava lá, todo mês, sem contrapartida.

Checklist da landing zone

• Hierarquia de organização e pastas em código, com organization policies herdadas.
• Projetos separados por ambiente, com nome padronizado pelo módulo e faturamento vinculado.
• IAM só por grupos; nenhum papel em e-mail individual; contas de serviço com escopo mínimo.
• Plano de endereçamento IP documentado, sem sobreposição com a rede local.
• VPC compartilhada com projeto host e firewall por identidade, não por faixa.
• Cloud NAT na saída; acesso privado aos gerenciados; nenhum banco com IP público.
• Bucket de state com versionamento, lock e acesso restrito.
• Pipeline com identidade federada, sem chave estática; plan no pull request e apply só após aprovação.
• Rótulos obrigatórios validados no pipeline e orçamento com alerta por projeto.
• Log sinks centralizados, retenção definida e alertas com destinatário real.
• Verificação periódica de drift, com a correção feita no código.

Para ir mais fundo antes do primeiro módulo, dois materiais ajudam. Na Inove Academy, o guia rápido de migração para nuvem orienta o que vai por lift-and-shift e o que merece redesenho — decisão que muda o desenho da landing zone. E a calculadora FinOps dá a ordem de grandeza do desperdício antes de qualquer compromisso: exatamente a medida que falta quando um CUD é comprado no impulso.

No fim, a landing zone não é um entregável bonito de arquitetura. É a diferença entre uma nuvem que cresce por adição e uma que cresce por remendo. A primeira absorve a próxima aplicação em horas; a segunda cobra, a cada nova carga, o preço das decisões que ninguém quis tomar no começo.