Todo projeto na GCP começa limpo e, uns seis meses depois, vira um amontoado de recursos que ninguém sabe de onde vieram nem quem paga a conta. Dá pra evitar isso com meia dúzia de decisões tomadas cedo.
Organize a casa antes de escalar
Antes de subir a primeira VM, pense na hierarquia: Organization no topo, Folders por área ou ambiente e Projects como unidade de isolamento. Um projeto por ambiente (dev, staging, prod) é o mínimo civilizado — quota, IAM e billing ficam separados de graça.
Amarre cada projeto a um Billing Account e coloque labels de time e centro de custo em tudo. Sem labels, o relatório de custo é um borrão. Com labels, você responde "quanto o time X gastou este mês" em trinta segundos.
IAM: o mínimo necessário, sempre
O pecado clássico é dar Editor pra todo mundo porque "é mais rápido". É rápido até alguém apagar um bucket de produção. Comece pelos papéis predefinidos mais estreitos e só suba o nível quando realmente doer.
Use Service Accounts por carga de trabalho, nunca a default do projeto. Evite baixar chaves JSON — prefira Workload Identity Federation e impersonation, que não deixam segredo circulando por aí. E revise os bindings de tempos em tempos: o Policy Analyzer mostra quem pode fazer o quê antes que isso vire notícia ruim.
Prefira o gerenciado ao "eu que administro"
GCP não é aluguel de VM. Toda vez que você sobe uma máquina pra rodar um Postgres na mão, você assumiu backup, patch, alta disponibilidade e plantão de madrugada. Cloud SQL, Pub/Sub, Cloud Run e BigQuery existem justamente pra você não fazer isso.
O preço do gerenciado às vezes assusta no papel, mas ele some quando você soma as horas de engenharia que uma VM crua consome. Guarde o Compute Engine pro que realmente não cabe num serviço gerenciado — e não pro que dá preguiça de migrar.
Custo não é surpresa de fim do mês
Crie Budgets com alerta em 50%, 90% e 100%, mandando pra e-mail e pra um tópico Pub/Sub. Não impede o gasto, mas te avisa antes do susto na fatura. E ative os relatórios de custo usando aqueles labels que você definiu lá no começo.
Olhe as Recommendations sem preguiça: idle VMs, discos órfãos, committed use discounts. É dinheiro parado em cima da mesa. Some a isso uma política de retenção — log e storage esquecidos são a assinatura mais silenciosa da nuvem.
Se você não vê, você não controla
Cloud Logging e Cloud Monitoring já vêm ligados; o erro é nunca olhar pra eles. Monte dashboards do que importa (latência, taxa de erro, saturação) e alertas com política de notificação de verdade — não um gráfico bonito que ninguém abre.
Defina uma retenção de log consciente, porque nem tudo precisa viver 400 dias. E use log-based metrics pra transformar aquela linha de erro recorrente em um alerta acionável, antes que o cliente te avise do problema.
Clicou uma vez? Então versione para sempre
Configurou no console pra testar? Ótimo, aprendeu como funciona. Agora joga fora e refaz em Terraform. Recurso criado no clique é recurso que ninguém consegue recriar depois — e que vira o clássico "não mexe que tá funcionando".
Com infraestrutura em código você ganha revisão, histórico e reprodutibilidade. De bônus, metade dos deslizes de IAM e billing aparece no diff do pull request, bem antes de chegar em produção.
Boa prática em GCP não é decoreba de serviço, é hábito: organiza, restringe, delega pro gerenciado, vigia o custo e versiona tudo. Faça isso desde o dia um e o seu eu de daqui a seis meses vai te mandar um obrigado.