Google ACE: Redes VPC, Conectividade e Gerenciamento de Tráfego — Guia de estudos

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Faz parte do Google Associate Cloud 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

A rede Virtual Private Cloud (VPC) no Google Cloud fornece primitivos de rede globais, definidos por software, com controle granular de endereçamento, roteamento, segurança e gerenciamento de tráfego. Esta seção foca em tópicos práticos de design e operações que você usará para construir redes resilientes, seguras e observáveis que interconectam serviços do Google Cloud, ambientes on-premises e a internet pública.

Arquitetura Central da VPC e Planejamento de IP

Redes VPC e sub-redes
- Uma VPC é um recurso global; suas sub-redes são regionais e podem abranger zonas. Instâncias em qualquer zona da região podem usar uma sub-rede.
- Use VPCs no modo personalizado para produção. O modo automático pré-cria uma sub-rede por região usando um conjunto predefinido de intervalos CIDR e pode levar a restrições de sobreposição de IPs, desperdício de espaço de endereço e dificuldades de refatoração quando você expandir.
- Intervalos de IP secundários em sub-redes habilitam IPs de Pod/Serviço do GKE e IPs de alias para VMs. Planeje os CIDRs primários e secundários com antecedência para evitar a renumeração.
Planejamento de endereços IP
- Escolha um espaço RFC1918 que não se sobreponha para todas as VPCs e redes on-prem atuais e futuras que você possa conectar. Reserve blocos para crescimento futuro de regiões e serviços.
- Dimensione as sub-redes corretamente (ex: /24 a /20) para o crescimento e evite intervalos excessivamente grandes que complicam as ACLs e os diagnósticos.
- Documente o uso de IPs: intervalos primários para workloads, intervalos secundários para o GKE e blocos reservados para pools de NAT ou endpoints de serviço.
Exemplo

undefined

Roteamento, Firewalls e Hierarquia de Políticas

Rotas e modos de roteamento dinâmico
- Cada VPC tem uma tabela de roteamento composta por rotas de sub-rede geradas pelo sistema, rotas padrão e rotas personalizadas estáticas ou dinâmicas.
- Modo de roteamento dinâmico:
  - Regional: rotas dinâmicas (BGP) aprendidas via Cloud Router podem ser usadas apenas por recursos na mesma região.
  - Global: rotas dinâmicas podem ser usadas por recursos em todas as regiões da VPC. Prefira o modo global para redes híbridas que precisam alcançar o ambiente on-premises a partir de múltiplas regiões.
- Próximos saltos (Next hops): gateway de internet padrão (0.0.0.0/0), túnel de VPN, Cloud Router (BGP), instância (appliance de roteamento) ou um balanceador de carga interno como próximo salto para appliances virtuais.
- Prioridade de rota: números menores têm preferência. Prioridades mal configuradas podem causar blackhole de tráfego ou vazá-lo para um próximo salto não intencional. Use convenções claras (ex: 1000 para a saída padrão, 900 para rotas mais específicas).
Hierarquia de firewall
- As regras de firewall da VPC são stateful e avaliadas antes do encaminhamento de pacotes. Elas existem no nível da VPC e se aplicam a todas as sub-redes.
- As políticas hierárquicas de firewall (anexadas à organização, pasta ou projeto) aplicam permissões/negações antes das regras da VPC. Use-as para implementar barreiras de proteção centrais (ex: negar portas de administração expostas à internet).
- Regras implícitas: uma regra implícita de permissão de saída (egress) e uma de negação de entrada (ingress) existem com a prioridade mais baixa; elas não podem ser removidas. Toda conectividade requer permissões de entrada explícitas.
Regras de firewall, tags, contas de serviço, tags seguras
- Direcionamento (Targeting): use tags de rede ou contas de serviço para aplicar regras a VMs específicas; o direcionamento por conta de serviço oferece um controle mais rigoroso baseado em identidade.
- As tags seguras fornecem rótulos gerenciados centralmente e protegidos pelo IAM para o direcionamento de políticas; elas impedem que workloads as anexem a si mesmos e dão suporte à segmentação zero-trust.
- Logging: habilite o logging de firewall seletivamente para regras de alto valor para equilibrar a visibilidade com o custo; colete amostras de pacotes, não os payloads completos.
- Modos de falha comuns: ausência dos intervalos de origem da verificação de saúde (health check), roteamento assimétrico causando descarte de respostas, intervalos de origem excessivamente amplos criando exposição não intencional.
Exemplo

undefined

Balanceamento de Carga, IPs, DNS e Gerenciamento de Tráfego

Tipos e comportamento do Cloud Load Balancing
- Baseado em proxy global: External HTTP(S), External TCP Proxy, External SSL Proxy. Encerram as conexões do cliente na borda do Google, suportam VIPs globais anycast e inserem cabeçalhos (ex: X-Forwarded-For). O IP original do cliente está disponível através de cabeçalhos ou do protocolo PROXY (para TCP), em vez de ser preservado como a origem L3.
- Passthrough regional: External Network Load Balancer e Internal TCP/UDP Load Balancer roteiam o tráfego na L4 e preservam o IP do cliente. Use quando você precisar de visibilidade do IP de origem nos backends sem o protocolo PROXY.
- Internal HTTP(S) Load Balancer: proxy L7 regional para serviços internos com roteamento avançado e opções de mTLS.
Serviços de backend, verificações de integridade e políticas de tráfego
- Serviços de backend definem os backends (grupos de instâncias, NEG/VM/Endpoint, serviços GKE), o modo de balanceamento (UTILIZATION ou RATE), limites de capacidade, afinidade de sessão e drenagem de conexão.
- As verificações de integridade devem ser permitidas através dos firewalls a partir dos verificadores de integridade do Google. Backends não íntegros são removidos automaticamente; verificações de integridade mal configuradas podem causar uma interrupção total.
- As políticas de tráfego incluem localidade (região/zona), backends de overflow e failover, e divisão de tráfego ponderada para lançamentos graduais em alguns tipos de LB.
IPs externos e internos, regras de encaminhamento
- Endereços externos e internos podem ser efêmeros ou estáticos reservados. Endereços externos estáticos globais são usados por LBs globais; a maioria dos outros são regionais.
- Regras de encaminhamento mapeiam um IP:porta para um destino (ex: targetHttpProxy ou serviço de backend). Escolha regras globais ou regionais para corresponder ao tipo de LB; uma incompatibilidade impede a criação.
Cloud DNS
- Zonas: zonas públicas resolvem na internet pública; zonas privadas são resolvíveis apenas a partir de VPCs autorizadas. Use registros gerenciados (A/AAAA, CNAME, TXT, MX, SRV, etc.).
- Split-horizon: crie zonas públicas e privadas para o mesmo domínio para que resolvedores internos recebam respostas privadas (ex: IP de um ILB) enquanto usuários públicos obtêm IPs voltados para a internet.
- Encaminhamento de DNS privado: use políticas do Cloud DNS para encaminhamento de entrada e saída para integrar com resolvedores on-premise; use o peering de DNS entre VPCs para compartilhar zonas privadas sem conectividade de peering completa.
Exemplo
- gcloud compute forwarding-rules create web-ilb –region=us-central1 –load-balancing-scheme=INTERNAL_MANAGED –ports=80 –backend-service=web-be

Conectividade Híbrida e Privada

Cloud Router, Cloud NAT e Private Google Access
- O Cloud Router troca rotas com o ambiente on-premise via BGP, anuncia sub-redes da VPC e importa prefixos on-premise. Use o roteamento dinâmico global quando várias regiões precisarem de alcançabilidade ao ambiente on-premise.
- O Cloud NAT fornece saída para a internet para VMs privadas e nós do GKE sem IPs externos. Dimensione os pools de IP do NAT para evitar o esgotamento de portas; monitore os logs em busca de conexões descartadas e escale os endereços conforme necessário.
- O Private Google Access (PGA) permite que VMs privadas acessem as APIs do Google sem IPs externos pelo caminho de roteamento padrão. O Private Service Connect (PSC) para APIs do Google fornece endpoints de IP privado em sua VPC com controle de políticas e evita completamente a saída pública; prefira endpoints PSC para um controle de saída mais rigoroso e DNS consistente.
Private Service Connect (serviços produtores e consumidores)
- Exponha serviços internos por trás de um anexo de serviço em um projeto produtor e consuma através de endpoints privados em projetos consumidores. O mapeamento de DNS e políticas de permissão explícitas controlam o acesso. Isso melhora o isolamento em comparação com o VPC Peering e centraliza a publicação de serviços.
VPC Network Peering, Shared VPC e segmentação
- O VPC Peering oferece conectividade privada entre VPCs com baixa latência. Ele é não transitivo e não permite IPs sobrepostos. A importação/exportação opcional de rotas personalizadas estende a alcançabilidade, mas ainda não cria roteamento transitivo; planeje o modelo hub-and-spoke de forma deliberada.
- O Shared VPC centraliza sub-redes em um projeto host para uso por projetos de serviço. Isso permite roteamento, firewalls, NAT e LBs centralizados, enquanto delega o IAM por aplicação. Combine com firewalls hierárquicos e tags seguras para segmentação.
- O Network Connectivity Center (NCC) fornece um hub para orquestrar spokes (VPN, Interconnect, dispositivo de roteador, VPC spokes) e gerenciar topologias de WAN corporativas de forma consistente.
Cloud VPN, Cloud Interconnect e BGP
- Cloud VPN: use o HA VPN com roteamento dinâmico (BGP) para disponibilidade e failover automático de rotas. Construa dois túneis por peer através de interfaces do Cloud VPN independentes e dispositivos/links on-premise distintos, quando possível.
- Cloud Interconnect: O Dedicated Interconnect fornece links privados de 10–100 Gbps; o Partner Interconnect usa um provedor de serviços. Para resiliência, implante interconexões redundantes em domínios de disponibilidade de borda diversos e use BFD com BGP onde for suportado.
- Domínios de falha: isole por região, zona, dispositivo e provedor. Teste o failover regularmente; caminhos assimétricos podem quebrar firewalls stateful on-premise.
Exemplos
- gcloud compute routers create corp-router –region=us-central1 –network=prod-net –asn=64514
- gcloud compute routers nats create nat-us-central1 –router=corp-router –nat-all-subnet-ip-ranges –auto-allocate-nat-external-ips
- gcloud compute vpn-gateways create ha-gw –region=us-central1 –network=prod-net

Observabilidade e Solução de Problemas

Testes de Conectividade
- Simula e verifica a alcançabilidade entre origens e destinos através de VPCs, on-prem (via links híbridos) e load balancers. A ferramenta avalia rotas, regras de firewall e configurações para localizar quedas ou tráfego mal roteado antes de alterações em produção.
- Exemplo:

undefined

VPC Flow Logs
- Habilite no nível da sub-rede para obter insights em tempo real sobre fluxos de 5-tuplas, bytes, quedas e latência. Exporte para o Cloud Logging, Pub/Sub ou BigQuery para análise. Ajuste a amostragem e os níveis de metadados para controlar os custos.
- Casos de uso: validar a eficácia do firewall, detectar exfiltração, planejamento de capacidade e monitoramento de SLO.
Packet Mirroring
- Espelhe o tráfego de VMs ou GKE para endpoints coletores para inspeção profunda de pacotes (DPI) ou IDS. Defina o escopo dos espelhamentos por sub-rede, tag ou instância. Entenda a sobrecarga de desempenho e garanta que os coletores possam lidar com o volume espelhado. Evite espelhar o tráfego pós-NAT quando precisar dos cabeçalhos originais.
Padrões comuns de diagnóstico
- Blackhole: a rota existe, mas o caminho de resposta está bloqueado por um firewall ou roteamento assimétrico; valide com os Testes de Conectividade e flow logs em ambos os lados.
- Falhas de verificação de integridade (health check): confirme se o firewall permite tráfego dos verificadores de integridade e se os backends estão escutando nas portas corretas; teste localmente a partir de uma VM na mesma sub-rede.
- Esgotamento de NAT: procure por fluxos negados com o motivo “no available NAT ports” (sem portas NAT disponíveis); adicione mais IPs de NAT ou reduza os limites de portas por VM.

Cenário de Problema Prático

A Acme Retail opera uma plataforma de e-commerce multirregional com backends privados, entrada web pública e um ERP on-prem. Eles precisam segmentar as cargas de trabalho, fornecer saída (egress) privada para as APIs do Google, habilitar a alcançabilidade híbrida de todas as regiões e reforçar a segurança, mantendo a observabilidade.

Criar uma Shared VPC em modo custom para controle centralizado

undefined

Justificativa: O modo custom evita CIDRs atribuídos automaticamente e permite um planejamento deliberado de IPs. A Shared VPC centraliza o roteamento, firewalls e NAT em um projeto host, permitindo que os projetos de serviço façam deploy com segurança.

Planejar e criar sub-redes com intervalos secundários para o GKE

undefined

Justificativa: Intervalos primários e secundários que não se sobrepõem evitam futuros conflitos de peering e permitem o uso de Alias IPs para o GKE sem esgotamento de IPs.

Definir o roteamento dinâmico da VPC como global e implantar o Cloud Router

undefined

Justificativa: O modo global torna as rotas on-prem aprendidas via BGP utilizáveis de todas as regiões, simplificando a alcançabilidade híbrida e o failover.

Estabelecer uma HA VPN para o ambiente on-prem e anunciar as sub-redes

Crie dois túneis de HA VPN através de dispositivos on-prem diversos. Use BGP para trocar prefixos e habilitar um failover suave.
Justificativa: Túneis duplos eliminam pontos únicos de falha; o BGP converge as rotas rapidamente durante manutenções ou interrupções.

Implantar o Cloud NAT para saída privada e o PSC para as APIs do Google

undefined

Crie endpoints do Private Service Connect para as APIs do Google e atualize o DNS privado para mapear os endpoints da API para o PSC.
Justificativa: O NAT permite a saída para a internet sem IPs externos nas VMs; o PSC mantém o tráfego da API em IPs privados e sob controle de políticas explícitas, eliminando caminhos de saída públicos.

Frontend com um External HTTP(S) Load Balancer global; serviços internos via Internal HTTP(S)

Crie um External HTTP(S) LB global com um certificado gerenciado e um serviço de backend apontando para backends NEG.
Crie Internal HTTP(S) LBs regionais para o tráfego entre serviços com mTLS entre microsserviços.
Justificativa: O LB de proxy global fornece anycast, autoescalonamento e CDN; o LB L7 interno oferece roteamento rico e segurança para o tráfego leste-oeste.

Implementar políticas de firewall hierárquicas e direcionamento por identidade da carga de trabalho (workload identity)

Anexe uma política no nível da organização negando portas administrativas da internet; permita apenas as origens de health-check do LB.
Crie regras de VPC direcionadas a contas de serviço para acesso de privilégio mínimo entre as camadas; use secure tags para segmentação dinâmica.
Justificativa: A hierarquia impõe barreiras de proteção (guardrails) de forma centralizada; o direcionamento baseado em identidade resiste à falsificação de tags (tag spoofing) e simplifica a automação.

Configurar o Cloud DNS com split-horizon e encaminhamento

Crie a zona pública acme.com para o VIP da web e a zona privada acme.com para nomes de serviços internos mapeados para ILBs.
Configure o encaminhamento de saída (outbound) para o DNS on-prem e de entrada (inbound) para que o on-prem resolva as zonas privadas.
Justificativa: O split-horizon evita o vazamento de dados e garante a resolução de nomes correta com base na rede de origem; o encaminhamento integra namespaces legados.

Usar Testes de Conectividade, flow logs e packet mirroring para visibilidade

Crie testes para caminhos críticos (usuário para o LB da web, web para serviços internos, serviços para o ERP on-prem).
Habilite os flow logs nas sub-redes; exporte para o BigQuery para análise de tendências. Habilite o packet mirroring temporariamente durante a resposta a incidentes.
Justificativa: Validação proativa e telemetria reduzem o MTTR, revelam configurações incorretas e fornecem insights de capacidade.

Documentar e testar cenários de falha

Simule a perda de um túnel VPN, de uma região e de um MIG de backend. Verifique o failover do BGP, a remoção pelo health-check do LB e a correção do DNS.
Justificativa: Game days regulares confirmam as premissas sobre redundância e expõem desvios de configuração (configuration drift) antes que causem interrupções.

← Contêineres · Todos os domínios · Armazenamento →

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