Google PCNE: Arquitetura de VPC, Sub-redes e Planejamento de Endereçamento — Guia de estudos

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Network Engineer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Uma Virtual Private Cloud (VPC) é uma rede global e logicamente isolada que abrange todas as regiões do Google Cloud. As sub-redes são construções regionais dentro de uma VPC e hospedam intervalos de IP que servem de base para o Compute Engine, GKE e outros recursos. Uma arquitetura de VPC sólida equilibra a eficiência do endereçamento, o crescimento e o controle operacional, garantindo ao mesmo tempo conectividade de baixa latência e custo-benefício para cargas de trabalho intra e interprojetos e para as APIs do Google.

Escopo da VPC, arquitetura de sub-rede e modos

• VPC global, sub-redes regionais

  • Uma única VPC abrange todas as regiões. As sub-redes são criadas por região e definem CIDRs IPv4 primários e intervalos secundários opcionais. As instâncias recebem IPs das sub-redes regionais, mas podem se comunicar de forma privada entre regiões dentro da mesma VPC por padrão.
  • Modo de roteamento dinâmico
    • Regional: Os Cloud Routers trocam rotas apenas com as sub-redes em sua região.
    • Global: Os Cloud Routers em uma região anunciam as rotas aprendidas para todas as regiões. Prefira o modo global quando cargas de trabalho multirregionais ou egresso de alta disponibilidade (HA) forem necessários.

• Modo automático vs. modo personalizado

  • O modo automático cria uma sub-rede por região com CIDRs pré-atribuídos. É conveniente para inícios rápidos, mas inflexível em escala. Ele pode ser convertido para o modo personalizado; a conversão é unidirecional.
  • O modo personalizado oferece controle total sobre a criação de sub-redes e a escolha de CIDRs. Este é o padrão recomendado para planejamento de endereçamento em produção, Shared VPC, peering e crescimento.
  • Nota de migração: Após converter do modo automático para o personalizado, artefatos ou modelos que presumiam sub-redes automáticas geralmente falham até serem explicitamente atualizados para referenciar as sub-redes personalizadas.

• Imutabilidade e crescimento da sub-rede

  • A região da sub-rede é imutável; você não pode mover uma sub-rede entre regiões.
  • Os intervalos IPv4 primários podem ser expandidos no local (prefixo ampliado), não podem ser reduzidos e devem permanecer não sobrepostos em toda a VPC e em quaisquer redes conectadas.
  • Os intervalos secundários podem ser adicionados ou removidos (sujeito ao uso), mas também não devem se sobrepor.

Planejamento de endereçamento: intervalos primários/secundários, IPs de alias, IPv6 e espaço privado

• Intervalos IPv4 primários e secundários

  • Intervalo primário: atribui endereços à interface da VM (nic0 por padrão). Ele cria uma rota de sub-rede gerada pelo sistema e é usado para a maior parte da comunicação interna.
  • Intervalos secundários: associam CIDRs adicionais à sub-rede e são necessários para clusters GKE nativos da VPC. Rotas geradas pelo sistema para os intervalos secundários permitem conectividade leste-oeste para Pods e Services.

• IPs de alias

  • Os IPs de alias permitem que uma NIC de VM possua múltiplos IPs dos intervalos primário ou secundário da sub-rede, possibilitando políticas rígidas baseadas em IP, IPs de Pod para GKE nativo da VPC e utilização eficiente de IPs.
  • Para o GKE, planeje grandes CIDRs secundários contínuos para minimizar a fragmentação e redimensionamentos futuros. Exemplo: para 100 nós com 200 Pods/nó e 1500 Services, aloque um intervalo secundário para Pods de pelo menos /17 e para Services de /21 para deixar uma margem de crescimento.

• Projeto com RFC 1918 privado e gerenciamento de IP

  • Escolha blocos não sobrepostos em todas as VPCs atuais e planejadas, ambientes on-premises e de parceiros. Reserve grandes blocos-pai para cada ambiente e, em seguida, divida-os em sub-blocos previsíveis por região e por função.
  • Reserve capacidade para crescimento, intervalos secundários, buffers de migração (dual-stack temporário/NAT duplo) e endpoints de infraestrutura (VIPs de ILB, endpoints de PSC).
  • Evite os blocos corporativos mais comuns se a conectividade com parceiros for provável; ou segmente com NAT para evitar conflitos.

• Planejamento de IPv6

  • IPv6 externo: use endereços IPv6 externos globais em balanceadores de carga globais para acesso de clientes e alcançabilidade anycast.
  • IPv6 interno: onde disponível, habilite sub-redes de pilha dupla (dual-stack) para atribuir IPv6 interno a VMs e ajuste as regras de firewall de acordo. Planeje os registros DNS AAAA e garanta a paridade com a política de IPv4.
  • Mantenha o IPv4 para controles intra-nuvem e integrações de terceiros; introduza o IPv6 gradualmente por meio de balanceadores de carga e sub-redes de pilha dupla (dual-stack).

Roteamento: rotas implícitas, rotas personalizadas, prioridades, tags e próximos saltos (next hops)

• Rotas implícitas (geradas pelo sistema)

  • Rotas de sub-rede: uma por sub-rede primária e por intervalo secundário, o destino é igual ao CIDR, o próximo salto é a própria sub-rede.
  • Rota padrão: uma rota 0.0.0.0/0 para o gateway de internet padrão é criada por padrão; a saída (egress) para a internet requer um IP externo ou NAT.

• Rotas personalizadas e lógica de seleção

  • A correspondência de prefixo mais longo (longest prefix match) vence. Se várias rotas tiverem o mesmo comprimento de prefixo, o número de prioridade mais baixo vence (prioridade padrão de 1000).
  • Tags e contas de serviço (service accounts)
    • Rotas sem tags se aplicam a todas as VMs. Rotas com escopo de tag se aplicam apenas a instâncias com as tags de rede correspondentes.
    • Regras de firewall baseadas em identidade podem corresponder a contas de serviço; use-as para um controle mais granular do que as tags, sempre que possível.

• Próximos saltos (Next hops)

  • Os próximos saltos suportados para rotas personalizadas incluem:
    • Gateway de internet padrão (0.0.0.0/0 ou prefixos de saída mais específicos)
    • Instância (requer encaminhamento de IP para rotear tráfego para outros; usado para appliances virtuais)
    • Túnel do Cloud VPN (rotas estáticas)
    • Balanceador de carga interno regional como próximo salto (para padrões de appliances escaláveis)
  • Você não pode definir o próximo salto para uma conexão de VPC peering; o peering gerencia sua própria troca de rotas.

• Exemplo de direcionamento de tráfego (appliance virtual)

  • Crie uma rota mais específica que a rota da sub-rede com um próximo salto para uma instância com encaminhamento de IP, com escopo definido por tags nas VMs de origem.
  • Exemplo:
    • gcloud compute routes create app-egress –network=prod-vpc –destination-range=0.0.0.0/0 –next-hop-instance=fw-appliance –next-hop-instance-zone=us-west1-a –priority=800 –tags=egress-via-fw

• Saída para APIs do Google sem IPs externos

  • Opção 1: Habilite o Private Google Access (PGA) nas sub-redes e, em seguida, adicione rotas personalizadas para os VIPs das APIs do Google para o gateway de internet padrão para contornar um caminho de saída padrão de terceiros, se necessário.
  • Opção 2: Use o Cloud NAT com PGA para fornecer saída para serviços do Google para VMs privadas.
  • Opção 3: Use o Private Service Connect para APIs do Google para consumo sem internet; o tráfego permanece na rede do Google e usa um endpoint RFC1918 privado em sua VPC.
  • Para acesso restrito, aponte os clientes para os VIPs restritos das APIs do Google e aplique controles de saída.

Shared VPC, peering, administração delegada e contas de serviço

• Shared VPC

  • O projeto host (host project) possui uma ou mais VPCs e sub-redes gerenciadas centralmente. Os projetos de serviço (service projects) anexam cargas de trabalho a sub-redes compartilhadas selecionadas.
  • Administração delegada
    • O Shared VPC Admin configura os anexos e o compartilhamento de sub-redes.
    • Os Network Admins gerenciam rotas, sub-redes e firewall no projeto host.
    • O IAM no nível do projeto nos projetos de serviço controla a implantação da carga de trabalho; você pode compartilhar apenas as sub-redes necessárias para limitar o raio de impacto (blast radius) e a visibilidade das rotas.
  • Contas de serviço (Service accounts)
    • Prefira políticas de firewall baseadas em contas de serviço para um controle determinístico e orientado por identidade entre as equipes.
    • Use contas de serviço dedicadas por camada e ambiente, com papéis de privilégio mínimo para acesso a dados (por exemplo, conceda o papel de Storage Object Viewer a uma conta de serviço que lê dados do Cloud Storage).

• VPC Network Peering

  • Restrições
    • Não transitivo: A↔B e B↔C não implicam A↔C. Construa uma malha completa (full mesh) se necessário.
    • Não pode haver sobreposição de intervalos de IP entre as redes em peering.
    • A troca é limitada a rotas de sub-rede (incluindo intervalos secundários); o direcionamento de próximo salto via peering não é suportado.
  • Use o peering para conectividade privada de baixa latência dentro da organização com sobrecarga operacional mínima quando VPCs separadas devem permanecer administrativamente distintas.

• Conectividade híbrida

  • Centralize o Dedicated Interconnect e o Cloud Router em um projeto host de Shared VPC para compartilhar conectividade de alta capacidade com os projetos de serviço dos departamentos.
  • Use anexos de VLAN de alta disponibilidade (HA VLAN attachments), localidades de borda (edge locations) diversas, Cloud Routers duplos e roteamento dinâmico global para resiliência e propagação para todas as regiões necessárias.

Operações: expansão, alta disponibilidade (HA), acesso privado, verificação e solução de problemas

• Expansão de sub-redes e restrições de migração

  • Expanda no local quando uma sub-rede se aproximar da capacidade; valide todas as redes conectadas para garantir que não haja sobreposição e garanta que os intervalos secundários dependentes do GKE permaneçam adequados.
  • Se os intervalos se sobrepuserem entre organizações ou parceiros, empregue NAT ou renumeração em etapas. Você não pode emparelhar VPCs com sobreposição nem instalar rotas dinâmicas com sobreposição.

• Posicionamento regional e alta disponibilidade

  • Posicione as sub-redes nas regiões mais próximas dos usuários e dos dados. Para bases de usuários transatlânticas, uma única VPC com sub-redes regionais em us-east1 e europe-west1 fornece conectividade privada direta com latência otimizada e custo zero de egresso dentro da VPC.
  • Distribua as cargas de trabalho entre as zonas; use grupos de instâncias gerenciadas regionais e balanceadores de carga internos/externos regionais para tolerância a falhas de zona.
  • Para ambientes híbridos, implante Cloud Routers e attachments duplos por região ou local de borda; habilite o BFD onde for compatível; use o roteamento dinâmico global para failover.

• Acesso Privado do Google e endpoints restritos

  • Habilite o PGA em sub-redes que hospedam instâncias sem IPs externos.
  • Para impedir o egresso geral para a internet e, ao mesmo tempo, permitir o acesso às APIs do Google:
    • Roteie o tráfego padrão para o seu NGFW.
    • Adicione rotas estáticas mais específicas para os VIPs das APIs do Google para o gateway de internet padrão ou implante endpoints PSC para as APIs do Google.

  • Exemplo:

undefined

• Verificação de topologia e solução de problemas
  • Use o Network Intelligence Center:
    • Connectivity Tests para validar a alcançabilidade e simular decisões de roteamento, firewall e gateway.
    • Performance Dashboard e Topology para visualizar caminhos e a saúde da rede.
  • Logs e telemetria:
    • VPC Flow Logs para observar permissões/negações (allow/deny) e latência por interface.
    • Firewall Rules Logging para confirmar correspondências de regras.
    • Logs e saúde do Cloud NAT para problemas de egresso sem IPs externos.
    • Logs do balanceador de carga e de verificação de saúde (health-check) para a prontidão do backend.

  • Verificações via CLI:

undefined

e

undefined

para confirmar a política efetiva. -

undefined

e

undefined

a partir de VMs de teste; use o packet mirroring para inspeção profunda quando necessário.

Cenário de Problema Prático

O Acme Retail Group precisa de uma rede Google Cloud multirregional de baixa latência com controle centralizado, acesso sem internet às APIs do Google para instâncias privadas e isolamento rigoroso entre departamentos que não precisam se comunicar. Algumas equipes executam GKE com alta densidade de Pods. A Acme também direciona o egresso geral através de um firewall de terceiros, mas deseja que o tráfego das APIs do Google evite o firewall.

1. Construa uma única Shared VPC em um projeto host no modo custom com roteamento dinâmico global e crie sub-redes regionais em us-east1 e europe-west1 com intervalos secundários reservados para o GKE.

• Justificativa: Uma única VPC fornece conectividade privada, sem custo, entre regiões sobre endereços RFC1918 para eficiência otimizada. O modo custom e o roteamento dinâmico global suportam o planejamento preciso de IPs e a propagação de rotas multirregionais.

2. Compartilhe apenas as sub-redes específicas necessárias com o projeto de serviço de cada departamento; crie três projetos de serviço (Vendas, Finanças, Marketing) e exponha apenas as sub-redes necessárias para cada um.

• Justificativa: O compartilhamento por sub-rede limita o raio de impacto (blast radius) e a exposição de rotas, impondo o isolamento e, ao mesmo tempo, permitindo operações centrais. O IAM delegado permite que administradores de rede centrais gerenciem firewalls e rotas, enquanto as equipes de aplicação implantam cargas de trabalho de forma independente.

3. Para departamentos que precisam se comunicar, emparelhe suas VPCs dedicadas ou coloque-os nas mesmas sub-redes da Shared VPC; para departamentos isolados, não faça o emparelhamento e não compartilhe sub-redes com sobreposição.

• Justificativa: O emparelhamento (peering) fornece conectividade privada de baixa latência com sobrecarga operacional mínima. A não transitividade exige conexões em malha (mesh) explícitas apenas onde necessário, o que preserva o isolamento por padrão.

4. Habilite o Private Google Access em todas as sub-redes compartilhadas e implante endpoints do Private Service Connect para as APIs do Google; mantenha a rota padrão para um firewall de terceiros e adicione rotas estáticas mais específicas para os VIPs das APIs do Google para o gateway de internet padrão.

• Justificativa: O PGA e o PSC fornecem consumo de API sem internet a partir de VMs privadas. As rotas mais específicas garantem que o tráfego da API contorne o NGFW, enquanto o egresso de internet não relacionado ao Google continua pelo caminho de inspeção.

5. Aloque CIDRs primários e secundários com margem para crescimento: para o GKE, dimensione um intervalo secundário para Pods (por exemplo, /17) e um secundário para Services (/21) por região de alto tráfego; use IPs de alias para Pods e Services e crie clusters VPC-native vinculados a esses intervalos.

• Justificativa: Intervalos secundários e IPs de alias evitam o esgotamento de IPs de nós e permitem um agendamento denso. O dimensionamento para a demanda futura evita redimensionamentos disruptivos e a renumeração de intervalos secundários.

6. Implemente HA para tráfego híbrido e de appliances: implante Cloud Routers duplos e HA VPN ou Interconnect conforme necessário; onde o direcionamento através de um virtual appliance for necessário, use uma rota customizada mais específica com o próximo salto (next hop) definido para um balanceador de carga interno regional ou uma instância com encaminhamento de IP (IP forwarding) e aplicabilidade com escopo de tag.

• Justificativa: A alta disponibilidade na borda (edge) garante a continuidade durante falhas. O escopo de rotas por tags evita o hairpinning acidental de tráfego e permite que apenas instâncias selecionadas percorram o caminho do appliance.

7. Verifique e opere com os Connectivity Tests do Network Intelligence Center, VPC Flow Logs e Firewall Rules Logging; aplique políticas de firewall baseadas em identidade usando contas de serviço e mantenha registros de IPAM com buffers reservados por região e função.

• Justificativa: A verificação proativa evita interrupções durante as mudanças. Políticas baseadas em identidade são mais robustas do que abordagens baseadas apenas em tags. A disciplina de IPAM impede a sobreposição que bloquearia o emparelhamento ou suprimiria rotas aprendidas.

Todos os domínios · Política de Firewall →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Google →