O domínio de redes no exame GCP-ACE exige mais do que memorização — requer capacidade de tomar decisões de arquitetura. Quando se escolhe Shared VPC em vez de VPC Peering? Por que Network Load Balancer é a resposta errada ao servir tráfego HTTPS global? Qual ferramenta separa a estimativa de custos da faturação real? Essas decisões de julgamento definem a diferença entre passar e chutar. Este guia percorre o que torna o networking do GCP único, como selecionar o balanceador de carga correto, quais serviços de suporte usar e como evitar as armadilhas de custos que surpreendem os engenheiros.
---
Como o Networking do GCP Difere de Outras Nuvens
A primeira coisa que surpreende os engenheiros vindos da AWS ou Azure é que o VPC do GCP é um recurso global. Na AWS e no Azure, um VPC ou VNet pertence a uma região específica. Conectar um VPC em Seul a um em US-East requer peering explícito ou um Transit Gateway.
O GCP funciona de forma diferente. Um VPC não tem região — é uma construção global. Você pode colocar sub-redes em Seul (asia-northeast3), US East (us-east1) e Europa (europe-west1) dentro do mesmo VPC, e as VMs conectadas a essas sub-redes podem se comunicar via IPs privados sem nenhuma configuração adicional.
Um segundo diferencial é a rede privada global do Google. Quando o tráfego chega a um balanceador de carga global, ele é recebido no PoP do Google mais próximo e então transportado pela fibra privada do Google — não pela internet pública — para a região do backend. É isso que permite que um único IP Anycast global entregue respostas de baixa latência em todo o mundo.
| Atributo | GCP | AWS | Azure | |----------|-----|-----|-------| | Escopo do VPC | Global (sem região) | Por região | Por região | | Escopo da Sub-rede | Por região, abrange todas as zonas | Por zona de disponibilidade | Por região | | LB Global | IP Anycast único | Configuração separada necessária | Configuração separada necessária | | Backbone Global | Rede privada do Google | Rede interna da AWS | Rede interna da Microsoft |
---
VPC e Sub-redes: O Modelo de VPC Global
Quando você cria um VPC no GCP, não seleciona uma região — é um contêiner de rede global. As regiões entram em jogo no nível da sub-rede. Quando você cria uma sub-rede, especifica uma região, e essa sub-rede abrange automaticamente todas as zonas de disponibilidade nessa região. Uma sub-rede em Seul e uma nos EUA dentro do mesmo VPC permitem que suas VMs se comuniquem via IPs privados sem configuração adicional de roteamento ou peering.
As sub-redes do GCP suportam intervalos de IP secundários além do bloco CIDR primário. São usados principalmente para pods e serviços do GKE, dando às cargas de trabalho do Kubernetes um espaço de endereços independente que não colide com o espaço IP primário das VMs.
As regras de firewall operam no nível do VPC. Para aplicar uma regra a um conjunto específico de VMs, você usa tags de rede ou contas de serviço como alvos. Isso difere dos grupos de segurança da AWS, que se anexam diretamente às instâncias. No GCP, a regra é definida no VPC e a tag na instância determina se a regra se aplica.
| Elemento | Descrição | Limitação Principal | |----------|-----------|---------------------| | VPC | Recurso global, sem afinidade de região | Limite padrão de 5 VPCs por projeto | | Sub-rede | Com escopo de região, cobre todas as zonas | CIDRs sobrepostos não são permitidos | | Intervalo de IP Secundário | Pool de IP adicional para pods e serviços do GKE | Até 30 intervalos por sub-rede | | Regra de Firewall | Nível de VPC, direcionada via tags ou contas de serviço | Processamento stateful |
---
Modo Automático vs Modo Personalizado de VPC e Planejamento de IPs
Ao criar um VPC, você escolhe entre modo automático e modo personalizado. Você pode converter um VPC em modo automático para modo personalizado, mas o inverso não é possível — então a escolha inicial importa.
O modo automático cria automaticamente uma sub-rede /20 em cada região a partir do bloco 10.128.0.0/9. É conveniente para ambientes de desenvolvimento, teste e aprendizado onde a velocidade de configuração importa mais do que a precisão de IP. O modo personalizado dá controle total sobre a criação de sub-redes — você define cada sub-rede manualmente, escolhendo a região e o bloco CIDR.
Para cargas de trabalho em produção, o modo personalizado é a escolha correta sempre que você antecipa conectar a redes on-premises via Cloud Interconnect ou VPN. O bloco 10.128.0.0/9 usado pelo modo automático se sobrepõe a intervalos de endereços comumente usados em data centers corporativos. Se existir uma sobreposição quando você tentar conectar, redesenhar o VPC é sua única opção.
| Atributo | Modo Automático | Modo Personalizado | |----------|-----------------|--------------------| | Criação de Sub-rede | Automática (/20 por região) | Manual (definida pelo usuário) | | Intervalo de IP | 10.128.0.0/9 fixo | Definido pelo usuário | | Recomendado Para | Dev/teste, aprendizado | Produção, empresarial | | Conectividade On-Premises | Alto risco de conflito de IP | Conflito evitável | | Conversão | Auto → Personalizado permitido | Personalizado → Auto não permitido |
!VPC em modo automático vs modo personalizado
Shared VPC e VPC Peering: Dois Modelos de Conectividade
Quando você precisa de conectividade de rede entre múltiplos projetos do GCP, tem duas opções: Shared VPC e VPC Peering. Este é consistentemente um dos tópicos mais confundidos no exame.
Shared VPC designa um projeto como o projeto host, que possui e gerencia o VPC. Outros projetos — chamados projetos de serviço — são anexados ao host e implantam suas VMs em sub-redes que pertencem ao VPC do host. As VMs se comunicam via IPs privados dentro do mesmo VPC, e há uma separação clara entre os administradores de rede (equipe do projeto host) e as equipes de aplicação (equipes de projetos de serviço).
VPC Peering conecta dois VPCs ponto a ponto. Cada VPC permanece gerenciado de forma independente, e o peering habilita a comunicação via IP privado entre eles. A propriedade crítica a lembrar é a não-transitividade. Se o VPC A está emparelhado com o VPC B, e o VPC B está emparelhado com o VPC C, o VPC A e o VPC C não podem se comunicar. Você precisaria estabelecer um peering direto entre A e C. Shared VPC evita isso completamente porque todos os projetos de serviço compartilham o mesmo VPC.
| Atributo | Shared VPC | VPC Peering | |----------|------------|-------------| | Propriedade da Rede | Projeto host único | Cada VPC de propriedade independente | | Modelo de Gerenciamento | Centralizado (projeto host) | Distribuído (cada equipe) | | Escala de Projetos de Serviço | Até 1.000 projetos de serviço | Requer peerings N:N | | Não-transitividade | Não se aplica (mesmo VPC) | Aplica-se (A-B-C não pode transitar) | | Entre Organizações | Não suportado (somente mesma org) | Suportado | | Fator Principal de Decisão | Governança de rede central | Propriedade independente de rede |
Gatilho do exame: múltiplas VMs de projetos precisando de comunicação via IP privado com gerenciamento central → Shared VPC. Dois VPCs independentes precisando de conectividade privada → VPC Peering.
---
Tipos de Balanceadores de Carga do GCP e Estrutura de Decisão
A seleção de balanceador de carga é um tópico de alta frequência no exame GCP-ACE. A árvore de decisão corre ao longo de três eixos: escopo (global vs regional), direção (externo vs interno) e camada (L7 aplicação vs L4 rede).
O Application Load Balancer externo global (antes Global HTTP(S) LB) aceita tráfego via um único IP Anycast de qualquer lugar do mundo, roteia solicitações para diferentes backends com base no caminho URL e cabeçalho de host, e lida com a terminação SSL com certificados gerenciados pelo Google. Opera na Camada 7. Se você precisar rotear /api/orders e /api/users para serviços backend separados, este é o balanceador de carga que você quer.
O Application Load Balancer interno lida com tráfego HTTP dentro de um VPC. É usado para comunicação privada entre microsserviços e como gateway de API privada. Não tem IP público.
Network Load Balancer opera na Camada 4 e lida com TCP e UDP. Não pode inspecionar URLs, tornando-o inadequado para roteamento baseado em caminhos. Destaca-se em cenários de ultra-baixa latência como servidores de jogos e aplicações UDP em tempo real.
| Tipo de Balanceador | Escopo | Camada | Capacidades Principais | Escolher Quando | |---------------------|--------|--------|------------------------|------------------| | Application LB Externo Global | Global | L7 | Roteamento URL, Anycast global, descarregamento SSL | HTTPS global, roteamento por caminho URL | | Application LB Externo Regional | Regional | L7 | Roteamento URL, descarregamento SSL | HTTPS de região única | | Application LB Interno | Regional | L7 | Tráfego HTTP privado dentro do VPC | HTTP entre microsserviços | | Network LB Externo (passthrough) | Regional | L4 | TCP/UDP, ultra-baixa latência | Gaming, streaming, apps legadas | | Network LB Interno (passthrough) | Regional | L4 | TCP/UDP privado dentro do VPC | Cargas de trabalho internas de alto desempenho | | Proxy Network LB | Global/Regional | L4 | Proxy TCP | TCP + distribuição global |
Guia de decisão: HTTPS global com roteamento URL → Application LB Externo Global. HTTP interno entre microsserviços → Application LB Interno. UDP com ultra-baixa latência → Network LB. Failover regional automático → Application LB Global.
---
Cloud DNS, Cloud CDN e Cloud NAT: Funções e Limites
Os serviços de rede de suporte aparecem no exame, e seus limites importam. Saber o que cada um faz — e o que não faz — previne identificação incorreta sob pressão de tempo.
Cloud DNS gerencia registros DNS com SLA de 99,99%. Uma zona pública lida com nomes de domínio resolvíveis externamente. Uma zona privada é anexada a um ou mais VPCs e só é visível para as VMs dentro desses VPCs — resolvedores externos não podem consultá-