Google PCNE: Roteamento, Network Connectivity Center e Segmentação — 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

Esta seção explica o roteamento, o Network Connectivity Center (NCC) e os padrões de segmentação no Google Cloud. Ela foca em como as rotas são criadas e selecionadas, como interconectar VPCs e organizações preservando o isolamento, como construir designs escaláveis de trânsito e inserção de serviços, e como validar e conter falhas.

Fundamentos e controle de roteamento

• Tipos de rota

  • Rotas de sub-rede geradas pelo sistema: Uma por intervalo de sub-rede primário e secundário; sempre as mais preferidas por seus prefixos exatos.
  • Rota padrão para o gateway da internet: Criada automaticamente em novas VPCs; pode ser removida ou substituída.
  • Rotas estáticas: Prefixos personalizados com próximos saltos (next hops) como o gateway da internet padrão, uma instância específica, um balanceador de carga TCP/UDP interno (ILB) como próximo salto, ou um túnel do Cloud VPN. As rotas baseadas em políticas (policy-based routes) adicionam condições de correspondência (tags, contas de serviço, protocolo/porta) e direcionam para uma instância ou ILB como próximo salto para inserção avançada de serviços.
  • Rotas dinâmicas: Aprendidas via Cloud Router por BGP a partir do Cloud VPN ou Cloud Interconnect. Seu escopo é controlado pelo modo de roteamento dinâmico da VPC (regional ou global).

• Seleção de rota

  • Correspondência de prefixo mais longo (longest prefix match) primeiro.
  • Se várias rotas tiverem o mesmo comprimento de prefixo, a prioridade de rota com o menor valor numérico vence (padrão 1000 para rotas personalizadas). Evite sobreposições de prefixos iguais entre caminhos estáticos/dinâmicos; projete para preferir um caminho de forma inequívoca.
  • Empates além da prioridade são resolvidos por mecanismos de desempate internos da plataforma; não confie neles.

• Opções de próximo salto (next-hop) e inserção de serviços

  • Para centralizar o tráfego de saída (egress) ou inserir serviços L3/L7, aponte uma rota estática 0.0.0.0/0 ou rotas baseadas em políticas para um ILB como próximo salto, cujos back-ends são dispositivos virtuais de rede (NVAs).
  • Quando os dispositivos precisam ser contornados para acesso às APIs do Google por instâncias sem IPs externos, habilite o Private Google Access nas sub-redes e adicione rotas estáticas personalizadas para os intervalos de VIPs das APIs do Google publicadas, apontando para o gateway da internet padrão. Isso preserva o acesso privado aos serviços do Google enquanto o restante do tráfego de saída segue o caminho do NGFW.

• Modo de roteamento dinâmico e comportamento multirregional

  • Regional: Rotas aprendidas por um Cloud Router são instaladas apenas para sub-redes na mesma região.
  • Global: Rotas aprendidas em qualquer lugar são instaladas para todas as regiões na VPC, permitindo conectividade multirregional simples e reduzindo a sobrecarga operacional para designs hub-and-spoke. Para usuários e cargas de trabalho próximos a us-east1 e europe-west1, uma única VPC com sub-redes regionais e roteamento dinâmico global permite que eles se comuniquem de forma privada sobre RFC1918 com eficiência otimizada.

• Controle de anúncio de rotas

  • O Cloud Router pode anunciar todas as sub-redes ou um conjunto personalizado de prefixos (incluindo uma rota padrão) para o ambiente on-premises. Controle a seleção do caminho de entrada do on-premises usando ferramentas BGP padrão (MED, AS-path prepending, local preference no on-premises). Para um cenário ativo/standby em direção ao on-premises, defina um MED mais baixo no caminho primário e um MED mais alto no de standby.
  • Evite anunciar o mesmo prefixo de diferentes peers on-premises com ASNs distintos para o mesmo Cloud Router; para ECMP dual-homed ou failover limpo, use o mesmo ASN de peer nos roteadores on-premises redundantes.

Interconectividade e segmentação de VPCs

• VPC Network Peering

  • Habilita conectividade privada RFC1918 entre VPCs com baixa latência e sem dispositivos no plano de dados. Por padrão, ele troca rotas de sub-rede e pode, opcionalmente, importar/exportar rotas personalizadas (estáticas e dinâmicas) para estender a alcançabilidade a recursos por trás do Cloud VPN/Interconnect. Não há roteamento transitivo: rotas aprendidas de um peer não são reexportadas para outro peer.
  • Modos de falha e limites: Não pode haver CIDRs sobrepostos; as regras de firewall permanecem independentes por VPC; a largura de banda é alta, mas não substitui balanceadores de carga; roteamento assimétrico em uma malha de peerings não é suportado. Para conectar três VPCs em um triângulo, configure uma malha completa (full mesh) de pares de peering; Vendas↔Finanças e Marketing↔Finanças não habilitam a comunicação Vendas↔Marketing, a menos que esse par também tenha um peering configurado.
  • Planejamento de endereçamento: Ao fazer peering com uma VPC em modo automático (que reserva 10.128.0.0/9), crie o peer em modo personalizado com um CIDR não sobreposto, como 10.0.0.0/9.

• Shared VPC e conectividade multiprojeto

  • Um projeto host (host project) é o dono da VPC; projetos de serviço (service projects) se anexam a sub-redes selecionadas. Isso centraliza a rede e a conectividade híbrida (Cloud Routers, Cloud NAT, Interconnect), ao mesmo tempo que permite a delegação da propriedade da aplicação por projeto. Coloque os VLAN attachments e os Cloud Routers para o Dedicated Interconnect no projeto host para fornecer conectividade on-premises centralizada e de custo eficiente para todos os projetos de serviço.
  • Menor privilégio (Least privilege): Os Network Admins gerenciam o roteamento e as sub-redes; os Security Admins gerenciam as regras e políticas de firewall. Se você não conseguir atualizar os firewalls com o papel de Network Admin, solicite o papel de Security Admin no escopo da Shared VPC.
  • Segmentação: Compartilhe apenas as sub-redes específicas exigidas por um projeto de serviço. Isso se alinha com as melhores práticas do Google para controlar rigorosamente a exposição de rotas entre Produção (Production) e Homologação (Staging).

• Controles de isolamento de rede

  • Limites da VPC: Não há roteamento entre VPCs sem um peering explícito, VPN ou Private Service Connect. Use VPCs separadas para departamentos ou tenants que devem ser totalmente isolados; faça peering apenas naqueles que precisam de conectividade para minimizar a sobrecarga operacional.
  • Políticas de firewall: Use políticas de firewall hierárquicas no nível da organização/pasta para ter barreiras de proteção (guardrails) consistentes e regras por VPC para exceções locais. O padrão de negar entrada (ingress deny) e permitir saída (egress allow) pode ser restringido.
  • Perímetros: Use o VPC Service Controls para restringir o acesso às APIs do Google e mitigar riscos de exfiltração de dados entre projetos e redes.
  • Exposição de IPv6: Para acesso público via IPv6, atribua um endereço IPv6 a um balanceador de carga HTTP(S) externo global que atende ao seu serviço. Os back-ends permanecem privados.

Network Connectivity Center e arquiteturas de trânsito

• NCC hub-and-spoke

  • O hub fornece um plano de controle para o roteamento entre os spokes. Os spokes incluem anexos de VLAN (Interconnect), túneis de HA VPN, spokes de appliance de roteador e spokes de VPC compatíveis para transferência de dados site-to-site. As tabelas de rotas do NCC controlam quais prefixos são importados/exportados e quais spokes os recebem, permitindo uma segmentação precisa.
  • A transferência de dados site-to-site permite que sites on-premises se comuniquem através do backbone do Google usando o hub como trânsito, reduzindo a necessidade de trânsito de terceiros e simplificando as operações.

• Spokes de appliance de roteador e NVAs de terceiros

  • Os spokes de appliance de roteador integram roteadores/firewalls virtuais hospedados no Compute Engine como serviços de trânsito ou inline. Use o ILB como próximo salto (next hop) para alcançar escalabilidade e failover com verificação de integridade (health-checked) entre múltiplos appliances.
  • Design de alta disponibilidade (HA): Implante pelo menos dois appliances em zonas diferentes; coloque-os atrás de um ILB com um MIG sempre que possível; habilite o encaminhamento de IP (IP forwarding) nas instâncias; use direcionamento simétrico com o ILB como próximo salto; distribua a carga usando rotas baseadas em políticas (policy-based routes) com base em tags ou contas de serviço.
  • Trade-offs de throughput e falha: Os NVAs são limitados pelo tipo de instância e pela largura de banda da NIC; planeje a escalabilidade horizontal. A falha de um appliance ou de sua verificação de integridade aciona a remoção do ILB e um failover rápido, mas garanta que os temporizadores de convergência de rota e os limites de integridade (health thresholds) estejam ajustados para evitar instabilidades (flaps).

• Trade-offs de topologia de trânsito

  • Hub-and-spoke com NCC: Política centralizada, alta escalabilidade, controle claro do raio de impacto (blast-radius); requer um design de tabelas de rotas e intenção de importação/exportação.
  • Peering full mesh: Simples para um número pequeno de VPCs, sem trânsito central, mas escala mal e não pode fornecer transitividade ou inserção de serviços.
  • Saída (egress) centralizada: Aplicação de segurança simples através de um único NGFW ou NAT; pode adicionar latência e se tornar um gargalo (choke point); mitigue com pontos de saída regionais e autoscaling.
  • VPN em malha (mesh) com Cloud Routers: Flexível e rápido de implantar; a sobrecarga operacional aumenta com o número de peers; considere o NCC para consolidar.

• Considerações sobre o Cloud VPN

  • Se o dispositivo on-premises não tiver BGP, use o Cloud VPN baseado em políticas (policy-based) com rotas estáticas e seletores de tráfego (traffic selectors) com escopo bem definido; planeje uma migração futura para o HA VPN com BGP para minimizar a sobrecarga de longo prazo.
  • Para túneis ativo/standby em direção ao ambiente on-premises, manipule o MED ou o AS-path no local. Para roteadores on-premises duplos conectando-se a um único Cloud Router, prefira ASNs de peer idênticos para permitir a instalação de ambos os caminhos e o uso de ECMP; usar ASNs de peer diferentes geralmente resulta na seleção de apenas um caminho.

Operações: validação, análise e contenção de interrupções

• Validação de conectividade e análise de rotas

  • Use os Connectivity Tests do Network Intelligence Center para rastrear o caminho dos dados através de VMs, load balancers, VPC peering, Cloud VPN e Interconnect, validando regras de firewall e rotas.
  • Analise as rotas efetivas por VM/sub-rede para confirmar os próximos saltos (next hops) e prefixos dinâmicos; verifique se o escopo do modo de roteamento dinâmico está alinhado com a intenção.
  • Para problemas de desempenho ou experiência do usuário, prefira o balanceamento de carga HTTP(S) global para reduzir a latência para usuários em todo o mundo através de ingresso anycast e terminação na borda; os network load balancers são regionais e não melhoram a latência global.

• Contenção de interrupções e redução do raio de impacto (blast radius)

  • Segmente por VPCs, tabelas de rotas do NCC e sub-redes de Shared VPC por projeto para evitar a propagação não intencional de falhas ou configurações incorretas.
  • Evite dependências transitivas via peering; onde o trânsito for necessário, use o NCC e importação/exportação controlada para restringir a alcançabilidade.
  • Use políticas de firewall centralizadas no nível da organização para regras de negação/permissão de base e políticas locais para exceções de aplicativos; teste as alterações com os Connectivity Tests.
  • Onde a segurança inline for necessária, implante um ILB como next-hop com verificações de saúde (health checks) e roteamento baseado em políticas para um failover suave. Garanta que as APIs críticas do Google sejam alcançáveis via Private Google Access ou Cloud NAT sem depender de IPs externos.
  • Monitore as sessões BGP e as alterações de rota; padronize métricas (MED, local preference) e planos de endereçamento para evitar oscilação de rotas e fluxos assimétricos.

• Exemplos curtos de configuração

  • Crie uma rota estática para direcionar o tráfego através de um ILB inline:
    • gcloud compute routes create egress-via-ngfw –network my-vpc –destination-range 0.0.0.0/0 –next-hop-ilb ngfw-ilb –priority 900
  • Prefira um de dois caminhos BGP de entrada para o on-premise usando MED (no roteador on-premise):
    • route-map FROM_GCP permit 10
    • set metric 20
    • router bgp 65000
    • neighbor 169.254.x.y route-map FROM_GCP in

Cenário de Problema Prático

A Acme Retail opera em uma organização Google Cloud com múltiplos projetos, com duas populações de usuários próximas a us-east1 e europe-west1. Eles precisam de comunicação privada e de baixo custo entre workloads em diferentes regiões, conectividade on-premise centralizada e filtragem de URL inline para a saída da internet, mantendo o departamento de Finanças isolado do de Engenharia.

1. Construa uma única Shared VPC em um projeto host com sub-redes regionais em us-east1 e europe-west1, e defina o modo de roteamento dinâmico como global.

• Justificativa: Uma única VPC permite comunicação direta RFC1918 entre regiões sem a sobrecarga do peering. O roteamento dinâmico global instala as rotas híbridas aprendidas em todas as regiões, simplificando as operações e garantindo fluxos eficientes dentro da VPC.

2. Compartilhe apenas as sub-redes necessárias com cada projeto de serviço; coloque Finanças e Engenharia em projetos de serviço separados.

• Justificativa: O compartilhamento no nível de sub-rede fornece segmentação organizacional e minimiza a exposição não intencional de rotas. O departamento de Finanças permanece isolado simplesmente por não compartilhar as sub-redes de Engenharia e por escopos de política de firewall separados.

3. Termine o Dedicated Interconnect no projeto host e anexe Cloud Routers; anuncie apenas os prefixos necessários usando anúncios personalizados (custom advertisements).

• Justificativa: A conectividade híbrida centralizada reduz o custo e a complexidade, mantendo o controle sobre o que alcança o ambiente on-premise. Os anúncios personalizados evitam a superexposição e contêm o raio de impacto.

4. Insira um appliance de filtragem de URL L7 inline atrás de um balanceador de carga interno TCP/UDP regional; direcione o tráfego de saída com uma rota estática 0.0.0.0/0 para o ILB como next-hop em cada região.

• Justificativa: O ILB como next-hop, junto com health checks, fornece inserção de serviço de alta disponibilidade (HA) com fluxos simétricos através dos appliances. Rotas estáticas com prioridade mais alta que a padrão garantem que todo o tráfego de saída seja filtrado.

5. Garanta que instâncias sem IPs externos possam alcançar as APIs do Google diretamente: habilite o Private Google Access em todas as sub-redes e adicione rotas estáticas para os intervalos de VIPs das APIs do Google para o gateway de internet padrão, a fim de contornar o appliance.

• Justificativa: O Private Google Access preserva o acesso privado ao BigQuery e ao Pub/Sub; rotas personalizadas evitam o “hairpinning” desnecessário através do filtro, reduzindo custo e latência.

6. Mantenha o departamento de Finanças isolado: negue o tráfego entre projetos em políticas de firewall hierárquicas e não configure peering entre Finanças e Engenharia. Onde a colaboração Engenharia↔Analytics for necessária, crie um par de VPCs dedicadas em peering com CIDRs que não se sobreponham.

• Justificativa: Os limites da VPC, a ausência de peering e as políticas de firewall no nível da organização impõem o isolamento. O peering direcionado oferece baixa sobrecarga operacional para conectividade departamental específica, sem transitividade.

7. Valide e monitore: use os Connectivity Tests para verificar a alcançabilidade entre regiões e a inserção do appliance; monitore a saúde do BGP do Cloud Router e as tabelas de rotas; implemente MED nos roteadores on-premise para failover ativo/standby se existirem múltiplos túneis.

• Justificativa: A validação proativa detecta configurações incorretas precocemente. Os controles de BGP mantêm os caminhos on-premise determinísticos durante manutenções ou falhas, enquanto a telemetria do NCC/Cloud Router acelera a solução de problemas.

Este design atende aos requisitos da Acme Retail com custo mínimo e alta eficiência: roteamento privado multirregional em uma única VPC, conectividade híbrida centralizada, inserção de serviço controlada e forte segmentação organizacional.

← Conectividade Privada para o Google e Serviços Gerenciados · Todos os domínios · GKE →

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

Navegar Google →