Google PCA: Redes, Conectividade Híbrida e Arquitetura de Tráfego — Guia de estudos

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Visão Geral

A arquitetura de rede, conectividade híbrida e tráfego no Google Cloud gira em torno de um design de Virtual Private Cloud (VPC) seguro e escalável; interconexões híbridas confiáveis; gerenciamento de tráfego inteligente; e observabilidade robusta. O objetivo é fornecer serviços resilientes e de baixa latência com segmentação clara, egresso controlado e modos de falha previsíveis. Esta seção descreve padrões de design práticos, trade-offs e orientações operacionais sobre os principais serviços de rede do Google Cloud.

Arquitetura e Segmentação de VPC

• Planejamento de endereços e sub-redes

  • Use VPCs no modo personalizado para controlar a criação de sub-redes e o endereçamento IP. Evite VPCs padrão em produção.
  • Aloque blocos RFC1918 não sobrepostos com antecedência. Considere o crescimento futuro, topologias de alta disponibilidade e extensões híbridas. Reserve intervalos para serviços (por exemplo, endpoints do Private Service Connect) e para peering/Interconnect.
  • Prefira sub-redes menores, por função ou por ambiente, em vez de grandes redes planas para minimizar o raio de impacto de falhas (blast radius) e simplificar as regras de firewall.

• Rotas

  • Cada VPC possui uma tabela de rotas do sistema; as rotas são avaliadas pela correspondência de prefixo mais longo e depois pela prioridade. As rotas gerenciadas pelo Google incluem a rota padrão da internet, se existirem IPs externos, e rotas de sub-rede. Rotas dinâmicas são trocadas com o ambiente on-premises via Cloud Router.
  • Use rotas estáticas personalizadas com moderação; confie no roteamento dinâmico sempre que possível para obter resiliência. Evite rotas blackhole, exceto como um controle deliberado.

• Regras de firewall

  • O firewall da VPC é stateful e avaliado por prioridade, com uma negação implícita no final. Use network tags ou service accounts como alvo; o direcionamento por service accounts oferece garantias de identidade mais fortes do que as tags.
  • Separe as regras de permissão (allow) por finalidade (verificações de saúde, comunicação entre camadas, administração) e defina seu escopo para service accounts ou intervalos de IP de origem.
  • Registre as decisões de firewall para regras críticas no Cloud Logging para auxiliar na análise forense e de desempenho.

• Políticas de firewall hierárquicas e políticas da organização

  • As políticas de firewall hierárquicas são aplicadas no nível da organização ou da pasta e são avaliadas antes das regras de nível de VPC. Use-as para definir proteções globais (por exemplo, negar SSH de 0.0.0.0/0) que os projetos não podem substituir. As políticas pré e pós oferecem flexibilidade, mas as negações em níveis mais altos não podem ser sobrepostas.
  • Complemente com restrições da Organization Policy (por exemplo, restringir a criação de IPs externos, proibir a criação de VPC peering por projetos) para impor a governança.

• Shared VPC e segmentação

  • Use a Shared VPC para centralizar a rede em Host Projects enquanto isola as cargas de trabalho em Service Projects. Esse padrão reduz caminhos de egresso duplicados, padroniza controles e simplifica o trânsito híbrido.
  • Isole ambientes (produção, não produção) em Host Projects ou pastas separadas; imponha a segmentação com políticas hierárquicas e sub-redes distintas. Restrinja o IAM para que apenas as equipes de NetOps gerenciem os recursos do Host Project.

• VPC Network Peering

  • O peering é privado, escalável e de baixa latência, mas não é transitivo. É ideal para conectar redes autônomas ou serviços gerenciados por terceiros. Evite construir hubs de trânsito com peering; use o Network Connectivity Center para trânsito ou uma Shared VPC centralizada.
  • Limitações: não são permitidos IPs sobrepostos; certas rotas (por exemplo, a rota padrão da internet) e alguns serviços não são propagados. Entenda a importação/exportação de rotas personalizadas ao projetar.

Trade-offs e modos de falha:

• Intervalos de IP sobrepostos bloqueiam o peering e a troca de rotas híbridas; resolva com renumeração de IPs ou NAT.
• Regras de firewall excessivamente permissivas ou a falta de regras para verificação de saúde causam interrupções e comportamentos difíceis de diagnosticar.
• Rotas estáticas criam dependências frágeis; prefira o Cloud Router para failover.

Gerenciamento de Tráfego, DNS e Segurança de Borda

• Padrões do Cloud Load Balancing

  • O External HTTP(S) Load Balancer é global anycast com um único VIP anycast, failover entre regiões, roteamento por caminho e host, e integração com CDN/Armor. Use para cargas de trabalho de web e API voltadas para a internet.
  • O Internal HTTP(S) Load Balancer é regional, para tráfego de serviço a serviço dentro de uma VPC ou via Private Service Connect.
  • O External/Internal TCP/UDP Network Load Balancer é regional L4; use para protocolos não-HTTP ou onde a preservação do IP de origem é necessária.
  • Serviços de backend e Network Endpoint Groups (NEGs): use backends de grupos de instâncias zonais para pools de VMs; use NEGs zonais, regionais ou serverless para GKE, backends híbridos ou Cloud Run. Crie serviços de backend separados por classe de tráfego, perfil de verificação de integridade ou política de capacidade. Exemplo: sirva versões antigas e novas de APIs sob o mesmo hostname, roteando por caminho para serviços de backend distintos, mantendo ambos implantáveis e escaláveis de forma independente.

• Verificações de integridade e armadilhas comuns

  • As verificações de integridade devem ser permitidas pelo firewall. Para verificações de integridade de HTTP(S) externo, permita 130.211.0.0/22 e 35.191.0.0/16 para os backends. A falta de uma regra resulta em backends marcados como não íntegros e reinicializações rápidas de VMs se o autoscaling reagir aos sinais do load balancer.
  • Alinhe os caminhos e portas da verificação de integridade com os endpoints de prontidão (readiness) do contêiner; defina timeouts e limites (thresholds) para equilibrar um failover rápido com a prevenção de falsos positivos.

• Arquitetura de DNS

  • Use o Cloud DNS para zonas autoritativas. Crie zonas privadas para nomes internos; crie zonas públicas para nomes da internet.
  • Split-horizon DNS: sirva respostas diferentes internamente versus externamente criando zonas públicas e privadas separadas com nomes idênticos. Isso suporta hostnames de serviços privados e registros públicos de forma segura.
  • Zonas de encaminhamento e peering: integre com o DNS on-premises usando políticas de DNS e políticas de servidor para encaminhar consultas para domínios específicos; use o encaminhamento condicional para evitar loops de recursão.
  • Service discovery: adote convenções de nomenclatura consistentes por ambiente e serviço. Para o GKE, considere usar headless services com o Cloud DNS, ou mapear endpoints de serviço via Internal HTTP(S) Load Balancer e nomes de DNS privados.

• Cache e proteção de borda

  • O Cloud CDN descarrega conteúdo cacheável na borda, reduzindo a latência da origem e o custo de egresso. Defina chaves de cache, TTLs e cache negativo com cuidado; ignore o cache para endpoints personalizados ou dinâmicos.
  • O Cloud Armor fornece WAF, limitação de taxa (rate limiting) e controle de acesso baseado em geo/IP. Anexe políticas de segurança aos load balancers; monitore os logs de acerto das regras. Use regras pré-configuradas para CVEs comuns e assinaturas personalizadas para ameaças específicas da aplicação.
  • A terminação TLS no load balancer centraliza o gerenciamento de certificados; habilite o provisionamento automático de certificados e renovações gerenciadas sempre que possível.

Orientações operacionais:

• APIs versionadas: implemente roteamento baseado em caminho ou host para serviços de backend separados, de modo que cada versão seja lançada de forma independente com padrões blue-green ou canary.
• Use cabeçalhos de requisição e cookies para testes A/B por meio de políticas de direcionamento de tráfego; sempre valide se os logs/métricas se correlacionam com a identidade correta do backend.

Conectividade Híbrida, Acesso Privado e Trânsito

• Cloud Router e BGP

  • O Cloud Router troca rotas dinamicamente com o ambiente on-premises via BGP para túneis do Cloud VPN e anexos do Interconnect. Use o modo de roteamento dinâmico global na VPC quando for necessária conectividade spoke multirregional.
  • Anuncie apenas os prefixos necessários; filtre para evitar vazamentos de rota. Entenda as interações de MED e prioridade ao projetar caminhos primários/de backup.

• Cloud VPN, Dedicated e Partner Interconnect

  • O HA VPN fornece túneis redundantes com SLA sobre IPsec, suporta roteamento dinâmico via Cloud Router e é adequado para ambientes de produção híbridos com necessidades moderadas de largura de banda.
  • O Dedicated Interconnect fornece links físicos de 10/100 Gbps em um ou mais locais; o Partner Interconnect oferece algo semelhante por meio de um provedor de serviços. Use pelo menos dois interconnects diversos em locais metropolitanos distintos ou zonas de borda (edge zones) separadas para alta disponibilidade.
  • Caminhos redundantes e failover: projete em modo ativo/ativo com BGP em dois Cloud Routers por região e dois roteadores on-prem; valide a tolerância a roteamento assimétrico. Teste o failover regularmente; ajuste os temporizadores do BFD e os limiares de saúde (health thresholds) para a convergência desejada.
  • Modos de falha: a incompatibilidade de MTU causa fragmentação e penalidades de desempenho; garanta jumbo frames de ponta a ponta para o Interconnect. Filtros de rota mal configurados podem criar um “blackhole” para sub-redes. Circuitos de parceiro com um único link (single-homed) são um ponto único de falha comum.

• Cloud NAT, Private Google Access e Private Service Connect

  • O Cloud NAT permite a saída (egress) para a internet para VMs privadas sem IPs externos. Dimensione os IPs e as alocações de porta do NAT para os picos de conexão a fim de evitar o esgotamento de portas; habilite o logging para solução de problemas (troubleshooting).
  • O Private Google Access permite que VMs privadas acessem as APIs do Google usando IPs internos; habilite-o nas sub-redes para acesso de VMs e nos nós do GKE para acesso local às APIs pelos nós. Para clientes on-prem, use o Private Service Connect for Google APIs para expor VIPs privados que servem de front-end para as APIs do Google.
  • O Private Service Connect para serviços de produtor/consumidor fornece endpoints de IP internos e privados para publicação de serviços entre projetos ou organizações; combine-o com DNS privado para direcionar o tráfego sem expor as redes.

• Network Connectivity Center (NCC) e trânsito

  • O NCC (Network Connectivity Center) possibilita topologias hub-and-spoke onde os spokes são VPCs, HA VPNs ou anexos do Interconnect. Use um hub central para simplificar a distribuição de rotas e o trânsito multi-VPC, especialmente entre projetos ou organizações.
  • Prefira a Shared VPC para trânsito intra-organização quando a governança permitir; use o NCC quando precisar de trânsito flexível e multidomínio ou integração com SD-WAN.
  • Entenda que o VPC Peering não é transitivo; não dependa dele para trânsito. O NCC ou uma VPC centralizada com firewall/load balancer forma o núcleo de trânsito.

Opções multirregionais, latência e custos de egresso:

• Posicione a computação perto dos usuários e dos back-ends stateful para minimizar o RTT. O External HTTP(S) Load Balancing fornece ingresso (ingress) global com roteamento inteligente, mas a latência de replicação do banco de dados e a consistência continuam sendo restrições da aplicação.
• O tráfego entre zonas (cross-zone) incorre em custos dentro de uma região; a replicação entre regiões (cross-region) adiciona cobranças de egresso e latência. Use o Cloud CDN para reduzir o egresso da internet e a carga na origem, e mantenha serviços com comunicação intensa (chatty services) na mesma localidade.
• Para recuperação de desastres (disaster recovery), pondere um ambiente warm standby em outra região em relação ao egresso e à complexidade operacional. Use o balanceamento de carga global com políticas de failover e health checks que abrangem regiões somente quando o plano de dados e o plano de controle puderem tolerar o isolamento regional.

Observabilidade, Operações de Confiabilidade e Controles

• Observabilidade de rede

  • VPC Flow Logs: habilite no nível da sub-rede e ajuste as opções de amostragem e metadados. Use para criar uma linha de base de tráfego (baselining), análise de egresso e caça a ameaças (threat hunting). Exporte para o BigQuery para análises de longo prazo.
  • Logs de regras de firewall: habilite em regras críticas para capturar tráfego permitido e negado; correlacione com os flow logs para detectar configurações incorretas.
  • Connectivity Tests: modele caminhos de origem-destino para validar a alcançabilidade, a seleção de rotas e a avaliação do firewall. Integre no CI/CD para detectar desvios (drift) antes da implantação.
  • Painéis de saúde (health dashboards): monitore a saúde do backend do balanceador de carga, a utilização de portas do Cloud NAT, o status da sessão BGP do Cloud Router e a utilização do Interconnect. Alerte sobre desvios.

• Padrões de confiabilidade e modos de falha comuns

  • Resiliência zonal: distribua os backends em pelo menos duas zonas; use managed instance groups ou pools de nós do GKE multizonais. Valide se as verificações de saúde (health checks) e as tags de firewall se aplicam a todas as zonas.
  • Resiliência de roteamento: use roteamento dinâmico global e múltiplos Cloud Routers para conectividade que abrange regiões. Teste cenários de blackhole e garanta que o monitoramento cubra retiradas de rota.
  • Resiliência de DNS: implante múltiplos servidores de nome (name servers) por padrão com o Cloud DNS; para ambientes híbridos, garanta que os encaminhadores (forwarders) sejam redundantes e evite pontos únicos em resolvedores on-premise. Evite configurações incorretas de split-horizon que retornam respostas não roteáveis do lado errado.
  • Segurança na borda: aplique limites de taxa (rate limits) do Cloud Armor para proteger a origem contra inundações (floods); a falha em fazer isso pode desencadear tempestades de autoscaling e picos de custo.

• Controles de custo

  • Minimize chamadas entre regiões, prefira o balanceamento de carga interno para tráfego intra-VPC e considere o PSC para tráfego produtor-consumidor para evitar egresso de NAT.
  • Use o Cloud CDN para ativos estáticos e semiestáticos; ajuste a capacidade de cache (cacheability). Dimensione a capacidade do Interconnect para evitar pagar a mais por capacidade ociosa; use dados de tráfego para dimensionar corretamente os compromissos (commits).

Snippets operacionais:

• Permitir verificações de saúde do balanceador de carga para backends privados:

undefined

• Habilitar o Private Google Access em uma sub-rede:

undefined

• Criar um Cloud Router para HA VPN:

undefined

Cenário de Problema Prático

A Contoso Retail planeja lançar uma API de e-commerce global com versionamento sem tempo de inatividade (zero-downtime), conectividade privada estrita com sistemas de back-office e sem IPs públicos nas VMs da aplicação. A solução deve fornecer proteção contra DDoS, cache de borda e acesso híbrido confiável a partir de dois data centers.

Abordagem:

1. Projetar a VPC e a segmentação

• Crie um Projeto Host de Shared VPC no modo custom com sub-redes dedicadas por camada (tier) (web, api, data) em duas regiões. Justificativa: A Shared VPC centraliza os controles enquanto os projetos de serviço isolam as equipes. Sub-redes por camada permitem regras de firewall de menor privilégio e domínios de falha menores.
• Aplique políticas de firewall hierárquicas no nível da organização para negar SSH de entrada vindo da internet e restringir o egresso para destinos permitidos. Justificativa: Barreiras de proteção (guardrails) globais reduzem o risco de configuração incorreta nos projetos.

2. Implementar ingresso global baseado em caminho e versionamento de API

• Implante um External HTTP(S) Load Balancer com um IP anycast único e terminação HTTPS. Configure mapas de URL para rotear /v1/* e /v2/* para backend services separados, apoiados por NEGs zonais regionais. Justificativa: Backend services distintos permitem implantação e rollback independentes para cada versão da API sob um único nome de host e TLS.
• Anexe o WAF e os limites de taxa do Cloud Armor; habilite o Cloud CDN para endpoints que podem ser cacheados (por exemplo, imagens de produtos). Justificativa: Protege a origem e reduz a latência e os custos de egresso.

3. Garantir a alcançabilidade e a saúde do backend

• Crie uma regra de firewall para permitir que as verificações de saúde do balanceador de carga alcancem os instance groups da API nas portas esperadas. Justificativa: Sem isso, as verificações de saúde falham e os autoscalers podem entrar em thrashing à medida que as instâncias são consideradas não saudáveis.
• Distribua as instâncias em duas zonas por região; defina os limiares da verificação de saúde de forma conservadora para evitar instabilidade (flapping). Justificativa: A diversidade zonal e políticas de saúde estáveis melhoram a disponibilidade.

4. Construir DNS com split-horizon e descoberta de serviços

• Crie uma zona pública do Cloud DNS para contoso.com e uma zona privada com o mesmo nome para registros apenas internos (por exemplo, db.internal.contoso.com). Justificativa: O split-horizon impede o vazamento de nomes internos, mantendo uma nomenclatura consistente.
• Configure políticas de DNS para encaminhar consultas on-premises de corp.local para o DNS corporativo e importar zonas privadas para os projetos de aplicação. Justificativa: Resolução transparente através das fronteiras híbridas sem loops de recursão.

5. Estabelecer conectividade híbrida com redundância

• Em cada região, provisione dois túneis de HA VPN para cada data center, cada par em Cloud Routers separados com BGP. Se a capacidade e as necessidades de SLA justificarem, adicione o Partner Interconnect com anexos redundantes em zonas de borda (edge zones) separadas. Justificativa: Múltiplos caminhos diversos fornecem failover; o BGP permite convergência rápida e troca dinâmica de rotas.
• Use roteamento dinâmico global na Shared VPC e aplique filtros de rota para evitar que prefixos on-premises indesejados se propaguem. Justificativa: Roteamento consistente entre regiões, reduzindo o risco de vazamentos de rota (route leaks).

6. Fornecer acesso privado às APIs do Google e à internet de saída

• Habilite o Private Google Access nas sub-redes da aplicação e configure endpoints do Private Service Connect para as APIs do Google usadas por jobs em lote. Use o Cloud NAT para egresso de saída não relacionado a APIs, quando necessário. Justificativa: Os backends não mantêm IPs públicos, mas ainda conseguem alcançar os serviços necessários; o PSC simplifica a resolução de nomes com DNS privado.

7. Centralizar o trânsito e a conectividade de terceiros

• Crie um hub do Network Connectivity Center no Projeto Host; anexe HA VPNs, anexos do Interconnect e quaisquer spokes de SD-WAN. Justificativa: O trânsito hub-and-spoke simplifica a distribuição de rotas entre múltiplas VPCs e redes externas em comparação com malhas de peering.

8. Implementar observabilidade e barreiras de proteção (guardrails)

• Habilite os VPC Flow Logs em todas as sub-redes com amostragem apropriada; habilite logs de firewall em regras críticas; exporte para o BigQuery. Use Connectivity Tests no CI/CD antes de promover novas alterações de firewall ou rota. Justificativa: A visibilidade profunda apoia a solução de problemas, o planejamento de capacidade e a auditabilidade.
• Defina alertas para quedas de sessão BGP do Cloud Router, esgotamento de portas do Cloud NAT, quedas na saúde do backend e acionamentos de regras do Cloud Armor. Justificativa: A detecção precoce de falhas e ataques reduz o MTTR.

9. Otimizar para desempenho e custo

• Colocalize serviços stateful com a computação na mesma região; faça cache de conteúdo estático na borda com o Cloud CDN. Justificativa: Minimiza o RTT e o egresso entre regiões.
• Revise periodicamente os flow logs para identificar comunicação excessiva entre zonas (cross-zone chatter) e ajustar o posicionamento ou os limites do serviço. Justificativa: Reduz o egresso e a latência desnecessários.

Este design entrega um ingresso global e seguro com roteamento versionado, conectividade híbrida resiliente com failover dinâmico, acesso privado aos serviços necessários e observabilidade abrangente, ao mesmo tempo que controla a latência e os custos de egresso.

← Armazenamento de Dados · Todos os domínios · Segurança →

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

Navegar Google →