GCP: o mapa essencial

Duas características distinguem o GCP na prática: o projeto como unidade central de tudo (recursos, permissão, cobrança, cota) e a rede global — uma VPC pode abranger várias regiões, sem peering entre elas. Quem vem da AWS costuma tropeçar nesses dois pontos, e não nos nomes dos serviços.

Organização, pastas e projetos

Organização (empresa.com.br)
├── Pasta "producao"
│   ├── Projeto "loja-prod"          ← recursos, IAM, cota e cobrança
│   └── Projeto "dados-prod"
└── Pasta "nao-producao"
    └── Projeto "loja-dev"

O projeto é a fronteira de isolamento: um projeto por ambiente e por domínio, com o faturamento vinculado à organização. Apagar o projeto apaga tudo dentro dele — o que é ótimo para ambiente efêmero e perigoso para produção (proteja com liens).

gcloud config set project loja-prod
gcloud projects describe loja-prod
gcloud resource-manager liens create --project=loja-prod \
  --restrictions=resourcemanager.projects.delete --reason="produção"

As Organization Policies aplicadas na pasta valem para todos os projetos abaixo: restringir regiões, proibir IP público em VM, exigir CMEK, desabilitar criação de chave de service account. Essa última é a que mais reduz risco.

Computação

Serviço	Use quando
Cloud Run	Container HTTP ou por evento; escala a zero; o padrão mais produtivo do GCP
GKE (Autopilot)	Precisa de Kubernetes sem operar nós
GKE (Standard)	Precisa controlar nós, GPU, add-on específico
Cloud Functions	Função pequena orientada a evento
GCE	Legado, licença, controle de sistema operacional

Cloud Run é a escolha padrão para serviço em container: sem cluster para operar, com escala a zero e integração direta com IAM e Cloud SQL. GKE Autopilot é um meio-termo bom quando o ecossistema Kubernetes importa.

Rede global e balanceamento

A VPC do GCP é global, com sub-redes por região. Isso simplifica topologia multi-região — não há peering interno para configurar — e exige atenção com o Shared VPC: uma rede central (projeto host) usada por vários projetos de serviço, que é o padrão recomendado para organização com muitos times.

O balanceador HTTP(S) global oferece um IP anycast único, com backend em várias regiões e Cloud CDN acoplado. Para o Brasil, a região é southamerica-east1 (São Paulo), com southamerica-west1 (Santiago) como par regional.

Regras de firewall são da VPC (não do recurso) e usam prioridade e tags ou service accounts como alvo — prefira service account como alvo, porque tag de rede é fácil de aplicar por engano.

gcloud compute firewall-rules create permitir-app-para-db \
  --network=vpc-prod --direction=INGRESS --priority=1000 \
  --action=ALLOW --rules=tcp:5432 \
  [email protected] \
  [email protected]

Dados

Cloud Storage (objetos, com classes e ciclo de vida), Cloud SQL (Postgres/MySQL gerenciado, com réplica e backup automático), Spanner (relacional distribuído, caro e poderoso), Firestore (documentos), BigQuery (analítico — o serviço mais característico do GCP) e Pub/Sub (mensageria).

No BigQuery, o custo é por dado varrido na consulta: particione e agrupe as tabelas, selecione colunas em vez de SELECT *, e defina limite de bytes por consulta. Uma consulta mal escrita pode custar mais que um mês de servidor.

IAM e service accounts

O IAM do GCP é principal → papel → recurso, herdado da organização para baixo. Use papéis predefinidos e evite os basic (Owner, Editor, Viewer), que são amplos demais.

A regra mais importante: não crie chave JSON de service account. Ela é credencial estática e é a origem de boa parte dos vazamentos no ecossistema. As alternativas cobrem quase todos os casos:

• Dentro do GCP: anexe a service account ao recurso (VM, Cloud Run, GKE).
• No GKE: Workload Identity liga a ServiceAccount do Kubernetes à do GCP.
• Fora do GCP (CI, outra nuvem): Workload Identity Federation com OIDC.

# GKE: Pod assume identidade do GCP sem nenhuma chave
gcloud iam service-accounts add-iam-policy-binding [email protected] \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:loja-prod.svc.id.goog[loja/app]"

Cloud Logging, Monitoring e custo

Cloud Logging recebe tudo por padrão, o que é conveniente e caro. Use exclusion filters para descartar o ruído na entrada e sinks para mandar o que precisa durar para o Cloud Storage ou BigQuery.

# descarte log de health check antes de pagar por ele
gcloud logging sinks create sem-healthcheck storage.googleapis.com/empresa-logs-frios \
  --log-filter='severity>=WARNING'

Cloud Monitoring cobre métricas, dashboards e alertas (com SLO nativo). Para custo, ative orçamento com alerta, exporte o faturamento para o BigQuery e use rótulos obrigatórios — e lembre dos descontos automáticos por uso sustentado, que tornam a comparação de preço com outras nuvens menos direta do que a tabela sugere.

Próximo passo: organize contas, projetos e guardrails em Landing zone.