Se você trabalha com infraestrutura no Google Cloud Platform, provavelmente já se deparou com desafios de conectividade entre serviços. Neste post, vamos explorar em detalhes a Private Service Connection (PSC), uma feature poderosa que mudou a forma como consumimos serviços no GCP de maneira segura e controlada.
O que é Private Service Connection (PSC)?
Private Service Connection é um modelo de conectividade do Google Cloud que permite que aplicações consumam serviços Google (como BigQuery, Cloud Storage, Pub/Sub) ou serviços de terceiros através de um IP privado dentro da sua VPC, eliminando completamente a necessidade de trafegar pela internet pública.
Diferente das abordagens tradicionais com Cloud NAT ou VPN, a PSC funciona através de um mecanismo de endpoint privado que reside dentro da sua rede virtual, oferecendo uma camada adicional de segurança e controle de acesso.
Como funciona por baixo dos panos?
A arquitetura da PSC é baseada em três componentes principais:
- Service Producer — o serviço que você quer consumir (Ex: Google Cloud Services ou uma aplicação sua)
- Service Attachment — um recurso de rede que expõe o serviço de forma segura
- Private Endpoint (PSC Endpoint) — um recurso criado em sua VPC que se conecta ao Service Attachment
Quando uma aplicação acessa um serviço via PSC Endpoint, todo o tráfego permanece dentro da infraestrutura do Google Cloud de forma privada. Não há exposição a IPs públicos, não há tráfego via internet e, mais importante, você tem controle fino sobre quem pode acessar o quê.
Benefícios de Segurança e Controle
1. Eliminação de exposição a internet pública
Sem PSC, para acessar serviços Google de uma rede privada, você precisava:
- Configurar Cloud NAT (expondo sua VPC a um IP público)
- Usar VPN com Google Cloud
- Abrir conexões outbound complexas
Com PSC, todo o acesso é completamente privado. Nenhum pacote sai pela internet pública.
2. Controle granular de acesso
Cada Service Attachment pode ser configurado com políticas de acesso baseadas em identidades:
# Exemplo de policy no Service Attachment
spec:
targetResource: "projects/seu-projeto/global/serviceAttachments/seu-attachment"
bindings:
- role: "compute.networkUsers"
members:
- "projects/consumer-projeto/global/networks/consumer-vpc"
- "serviceAccount:app@seu-projeto.iam.gserviceaccount.com"
Você pode restringir por VPC, projeto GCP, ou até por identidades de serviço específicas.
3. Auditoria e logging melhorados
Como o tráfego não passa por pontos de saída públicos, você tem visibilidade completa através de Cloud VPC Flow Logs:
# Ativar VPC Flow Logs para inspecionar tráfego PSC gcloud logging sinks create psc-logging \ logging.googleapis.com/projects/seu-projeto/logs/vpc-flows \ --log-filter='resource.type="gce_network" AND jsonPayload.src_port > 1024'
Todo o tráfego que passa pelo endpoint fica registrado, facilitando investigações de segurança.
Casos de Uso e Quando Usar
✅ Use PSC quando:
- Conformidade regulatória — Você trabalha com dados sensíveis (financeiro, saúde) que não podem trafegar pela internet
- Arquiteturas de perimetro de segurança — VPCs isoladas que precisam acessar serviços gerenciados
- Multi-projeto com isolamento — Vários projetos GCP precisam consumir um serviço central de forma controlada
- Redução de custos de egress — Tráfego via PSC não incorre em custos de transferência de dados (egress)
- Microsserviços em Kubernetes — Pods precisam acessar BigQuery, Pub/Sub ou Cloud SQL com identidades específicas
❌ Não é necessário quando:
- Você já aceita exposição pública (apps web públicas, APIs externas)
- Está usando APIs via SDK do lado do cliente sem preocupação com dados sensíveis
- Precisa apenas melhorar latência (PSC não é a solução para isso)
Implementação Técnica Detalhada
Passo 1: Criar um Service Attachment
Para expor um serviço (ex: um Load Balancer interno), você cria um Service Attachment:
gcloud compute service-attachments create meu-attachment \ --region=us-central1 \ --target-service=projects/seu-projeto/global/forwardingRules/meu-lb-interno \ --nat-subnets=projects/seu-projeto/regions/us-central1/subnetworks/nat-subnet \ --enable-proxy-protocol
Passo 2: Configurar política de acesso
gcloud compute service-attachments update meu-attachment \ --region=us-central1 \ --consumer-accept-list='projects/seu-projeto/global/networks/consumer-vpc=10'
Neste exemplo, permitimos que a VPC consumer-vpc se conecte com até 10 conexões simultâneas.
Passo 3: Criar o PSC Endpoint no lado consumidor
gcloud compute service-attachments connect \ --name=psc-endpoint-bigquery \ --region=us-central1 \ --network=consumer-vpc \ --subnet=consumer-subnet \ --service-attachment=projects/service-projeto/regions/us-central1/serviceAttachments/meu-attachment
Passo 4: Usar em suas aplicações
A mágica está aqui: depois de criar o endpoint, você acessa o serviço via um IP privado fornecido automaticamente:
// Exemplo em Go acessando BigQuery via PSC import "cloud.google.com/go/bigquery" client, _ := bigquery.NewClient(ctx, "seu-projeto") // O SDK automaticamente usa o PSC Endpoint se estiver na mesma VPC // Não precisa de mudanças no código!
Segurança em Profundidade
Autenticação e Autorização
PSC opera na Camada 3 (Rede), mas integra-se perfeitamente com IAM do GCP. Você ainda precisa de:
- Autenticação via credenciais (Service Account, ADC)
- Autorização via políticas IAM nos recursos consumidos
- Controle de rede via Service Attachment policies
Criptografia
- Tráfego dentro do Google Cloud é criptografado automaticamente (encryption in transit dentro da infraestrutura Google)
- Se você precisa de criptografia fim-a-fim adicional, configure mTLS no aplicativo
DDoS e proteção de rede
Como não há exposição pública, você está naturalmente protegido contra:
- Ataques DDoS diretos
- Escaneamento de portas
- Tentativas de força bruta via internet
Custo e Performance
Custos
- Sem charges extras para tráfego via PSC Endpoint
- Você paga apenas pelos recursos subjacentes (Load Balancer, VM, etc.)
- Sem custos de egress — diferente de tráfego via Cloud NAT
Performance
- Latência similar ao tráfego normal na VPC
- Sem overhead significativo de criptografia
- Ideal para workloads latency-sensitive
Limitações a considerar
- Service Attachment por região — Você precisa de um attachment em cada região onde quer oferecer o serviço
- Limite de conexões simultâneas — Configurável, mas tem um teto baseado no tipo de service attachment
- Não suporta IPv6 — Por enquanto, PSC funciona apenas com IPv4
- Cross-project discovery — Requer configuração explícita; não é descoberta automática
Exemplo Real: Microsserviços isolados acessando dados
Imaginemos uma arquitetura com:
- VPC de dados com Cloud SQL e BigQuery
- VPC de aplicação isolada com microsserviços em GKE
- VPC de terceiros (parceiro externo)

Cada VPC tem seu próprio endpoint, cada um sujeito a diferentes políticas de acesso. A VPC de dados nunca é acessível diretamente — apenas através do Service Attachment controlado.
Conclusão
Private Service Connection é a evolução natural da conectividade segura no Google Cloud. Se você trabalha com dados sensíveis, precisa de conformidade regulatória ou quer aplicar princípio de menor privilégio na sua infraestrutura, PSC deve estar no seu radar.
A implementação é direta, o overhead é mínimo, e os ganhos em segurança e controle são imensos. Especialmente em arquiteturas multi-projeto ou multi-VPC, PSC elimina uma classe inteira de problemas de segurança de rede.
Comece pequeno — crie um Service Attachment para um serviço crítico e experimente. Você vai ver rapidamente por que essa feature virou essencial para infraestruturas enterprise no GCP.
Gostou do conteúdo?
- ✅ Inscreva-se na newsletter para receber mais dicas práticas sobre Cloud e infraestrutura diretamente no seu e-mail!
- 🚀 Conheça a Imersão Golang e leve seus conhecimentos em Go para o próximo nível!