Guia

Planeje o endereçamento IP para implantações em larga escala ou de nuvem híbrida.

→Use VPCs em modo personalizado. Aloque blocos CIDR RFC 1918 não sobrepostos (por exemplo, 172.16.0.0/12) para evitar conflitos com a rede local (geralmente 10.0.0.0/8). Use 100.64.0.0/10 para intervalos secundários de pods GKE.

Por quê: Evita conflitos de IP com a rede local para futura conectividade híbrida e oferece controle total sobre o espaço de endereçamento, o que é essencial para escala e para evitar um custoso re-endereçamento de IPs.

Referência↗

Forneça isolamento de rede para múltiplos locatários/ambientes (desenvolvimento, produção) enquanto centraliza o gerenciamento de rede e os serviços compartilhados.

→Use Shared VPC. O projeto host contém a VPC, sub-redes, firewalls e interconexões. Locatários/ambientes são projetos de serviço anexados ao projeto host.

Por quê: Centraliza a administração da rede no projeto host enquanto delega o gerenciamento de recursos aos projetos de serviço. Mais escalável e governável do que o emparelhamento de VPC para muitos projetos dentro de uma organização.

Referência↗

Planeje o endereçamento IP para grandes clusters GKE usando redes VPC-nativas.

→Em uma VPC em modo personalizado, planeje três intervalos CIDR: um intervalo primário para nós, um intervalo secundário para Pods e outro para Services. Para expansão, use CIDR multi-pod descontíguo.

Por quê: A rede VPC-nativa requer intervalos secundários dedicados e não sobrepostos para pods e serviços. O dimensionamento adequado evita o esgotamento de IP, um problema comum e disruptivo em grandes clusters.

Referência↗

VMs sem IPs externos precisam acessar APIs do Google Cloud (por exemplo, Cloud Storage, BigQuery).

→Habilite o Acesso Privado do Google na sub-rede. Opcionalmente, configure o DNS para resolver `*.googleapis.com` para `restricted.googleapis.com` (199.36.153.4/30) para impor o VPC-SC.

Por quê: Encaminha o tráfego para as APIs do Google pela rede interna do Google sem exigir IPs públicos nas VMs. O uso de `restricted.googleapis.com` adiciona uma camada de proteção contra exfiltração de dados.

Referência↗

Forneça acesso privado a um serviço na sua VPC para consumidores (parceiros, outras unidades de negócio) cujas VPCs possuem intervalos de IP sobrepostos.

→Publique o serviço (via um Internal Load Balancer) usando um anexo de serviço Private Service Connect (PSC). Consumidores criam um endpoint PSC em suas VPCs com um IP do seu próprio intervalo.

Por quê: PSC desacopla as redes do produtor e do consumidor, usando NAT para lidar com IPs sobrepostos. Ele fornece acesso seguro em nível de serviço, não conectividade de rede completa como o emparelhamento de VPC.

Referência↗

Conecte um grande número (50+) de VPCs e/ou sites locais em uma topologia hub-and-spoke para gerenciamento e conectividade centralizados.

→Use o Network Connectivity Center. Configure o hub e anexe as VPCs como spokes de VPC e as conexões locais (VPN/Interconnect) como spokes híbridos.

Por quê: O NCC é a solução gerenciada do Google para topologias hub-and-spoke em larga escala, simplificando o gerenciamento de rotas e escalando além do limite de 25 emparelhamentos da VPC peering.

Implante um cluster GKE onde os nós e o plano de controle não possuam endereços IP públicos para maior segurança.

→Crie um cluster GKE Privado. Isso atribui apenas IPs internos aos nós e cria um endpoint privado para o plano de controle. Configure redes autorizadas para restringir o acesso ao plano de controle.

Por quê: Um cluster privado remove o plano de controle e os nós da internet pública, reduzindo significativamente a superfície de ataque. Todo o tráfego de gerenciamento e de carga de trabalho permanece na rede privada.

Cargas de trabalho serverless (Cloud Run, Functions) precisam acessar recursos (por exemplo, Cloud SQL, Memorystore) dentro de uma VPC.

→Crie um conector de Acesso Serverless VPC na VPC de destino. Configure o serviço serverless para usar este conector para o tráfego de saída.

Por quê: O conector atua como um proxy, permitindo que serviços serverless (que rodam em um ambiente gerenciado pelo Google) enviem tráfego para uma VPC gerenciada pelo cliente usando IPs internos.

Uma aplicação (por exemplo, HPC, trading financeiro) requer a latência de rede mais baixa possível entre um grupo de VMs.

→Crie uma política de posicionamento compacto e aplique-a às VMs. Use tipos de máquina com rede Tier_1.

Por quê: Colocar VMs no mesmo rack de rede minimiza saltos de rede e distância física, reduzindo significativamente a latência em comparação com o posicionamento padrão de VMs.

Implemente um modelo de segurança de confiança zero para microsserviços, exigindo identidade forte, comunicação criptografada (mTLS) e autorização granular.

→Implante o Anthos Service Mesh. Habilite o mTLS automático para toda a comunicação serviço-a-serviço. Use recursos `AuthorizationPolicy` para definir a comunicação permitida.

Por quê: Uma malha de serviço desacopla a segurança da rede subjacente, fornecendo identidade da carga de trabalho, mTLS transparente e autorização L7, que são pilares centrais de uma arquitetura de confiança zero.

Cargas de trabalho (VMs, pods GKE) sem IPs públicos precisam de um IP de origem estável e previsível para conexões de saída para APIs externas que usam listas de permissão.

→Implante o Cloud NAT. Use a opção "manual NAT IP allocation" e atribua endereços IP externos estáticos reservados ao gateway NAT.

Por quê: O Cloud NAT com alocação manual fornece um pool compartilhado de IPs de saída estáticos. Isso desacopla a carga de trabalho do IP, permitindo escalar sem a necessidade de atualizar listas de permissão externas.

O emparelhamento de VPC está estabelecido, mas as VMs não conseguem se comunicar entre as VPCs emparelhadas.

→Verifique se as regras de firewall em *ambas* as VPCs permitem o tráfego de entrada do intervalo de IP da outra VPC. A conexão de emparelhamento apenas estabelece o roteamento; ela não cria implicitamente permissões de firewall.

Por quê: Um erro comum é supor que o emparelhamento abre portas de firewall. A regra implícita de negar todo o tráfego de entrada bloqueia o tráfego até que uma regra de permissão explícita seja criada.

Em uma Shared VPC, conceda permissão a uma equipe/projeto de serviço para usar apenas uma sub-rede específica, não toda a VPC.

→No projeto host, conceda a função IAM `compute.networkUser` à identidade do projeto de serviço (por exemplo, conta de serviço, grupo) no recurso de nível de sub-rede.

Por quê: As funções IAM podem ser restritas a recursos específicos. Aplicar `compute.networkUser` no nível da sub-rede impõe o princípio do menor privilégio, permitindo o uso apenas dessa sub-rede.

Implemente microsegmentação para uma aplicação multi-tier (por exemplo, web, app, db) no Compute Engine.

→Atribua tags de rede às VMs com base em sua tier (por exemplo, `web-server`). Crie regras de firewall que usem essas tags como especificadores de origem e destino.

Por quê: Tags fornecem uma alternativa flexível e escalável às regras baseadas em IP. A política de firewall é independente do número ou dos IPs das VMs em uma tier.

Capture metadados de tráfego para conformidade/auditoria enquanto minimiza o volume de logs e os custos de armazenamento.

→Habilite o VPC Flow Logs com um intervalo de agregação mais longo (por exemplo, 10 minutos), uma taxa de amostragem reduzida (por exemplo, 0,5) e filtragem de metadados para excluir campos desnecessários.

Por quê: As configurações padrão geram grandes quantidades de dados. Ajustar esses parâmetros reduz significativamente o custo, ao mesmo tempo em que fornece visibilidade suficiente para a maioria dos casos de uso de auditoria.

Entregue uma aplicação global com baixa latência, roteando usuários para o backend saudável mais próximo com failover automático.

→Use um Global External Application Load Balancer (ou TCP/SSL Proxy LB para não-HTTP). Configure serviços de backend/NEGs em múltiplas regiões. Use rede Premium Tier.

Por quê: O IP anycast do balanceador de carga direciona os usuários para o PoP de borda do Google mais próximo. O tráfego então viaja pela rede backbone privada do Google para o backend saudável mais próximo para um desempenho ideal.

Referência↗

Encaminhe o tráfego interno com base no caminho da URL ou nome do host, com terminação SSL, acessível apenas dentro da VPC ou de redes locais.

→Use um Regional Internal Application Load Balancer. Configure um mapa de URL para direcionar o tráfego com base em regras de host/caminho. Requer uma sub-rede apenas para proxy.

Por quê: Este é o balanceador de carga interno L7 gerenciado do Google. Ele fornece recursos avançados de roteamento não disponíveis com o Internal Passthrough Network LB L4.

Use o Cloud CDN para armazenar em cache e servir conteúdo privado ou específico do usuário sem torná-lo público.

→Habilite o Cloud CDN em um backend privado (por exemplo, bucket GCS). Gere URLs assinadas ou Cookies assinados do Cloud CDN em sua aplicação para conceder aos usuários acesso temporário e autenticado.

Por quê: URLs/Cookies assinados fornecem um token seguro que o Cloud CDN valida antes de servir um objeto em cache, aproveitando o cache de borda enquanto mantém controle de acesso rigoroso.

Habilite a resolução DNS bidirecional entre uma rede local e uma VPC GCP.

→1) Rede local resolve GCP: Crie uma política de servidor de entrada do Cloud DNS. Configure o DNS local para encaminhar para os IPs do encaminhador de entrada. 2) GCP resolve rede local: Crie uma zona de encaminhamento do Cloud DNS que aponte para os servidores DNS locais.

Por quê: Esta configuração padrão em duas partes fornece resolução de nomes privada e contínua para ambientes híbridos, um componente crítico para a interoperabilidade de aplicações.

A taxa de acertos do cache do Cloud CDN é baixa devido a variações desnecessárias de URL (por exemplo, parâmetros de rastreamento).

→Configure uma política de chave de cache personalizada para o serviço de backend. Exclua parâmetros de consulta não essenciais, cookies e cabeçalhos da chave de cache.

Por quê: Por padrão, a URL completa é a chave de cache. Normalizar a chave excluindo parâmetros irrelevantes evita a fragmentação do cache e melhora drasticamente a taxa de acertos.

Resolva um nome DNS para um IP interno para clientes internos e um IP público para clientes externos.

→Crie uma zona privada do Cloud DNS para o domínio (visível para sua VPC) com o registro IP interno. Crie uma zona pública correspondente do Cloud DNS com o registro IP público.

Por quê: O Cloud DNS serve automaticamente a resposta da zona privada para clientes dentro da VPC autorizada, e a resposta da zona pública para todos os outros.

Uma aplicação interna em uma região precisa ser acessível por clientes (VMs, rede local) em outras regiões.

→Habilite a opção "Acesso Global" na regra de encaminhamento do Internal TCP/UDP Load Balancer ou Internal Application Load Balancer.

Por quê: Por padrão, LBs internos são regionais. O Acesso Global os torna acessíveis de qualquer região dentro da rede VPC, simplificando arquiteturas de serviço internas multi-região.

Estabeleça conectividade de alta disponibilidade (SLA de 99,99%), alta largura de banda (10G+) entre a rede local e o GCP.

→Provisione um mínimo de quatro conexões Dedicated Interconnect, duas em uma metrópole e duas em outra, com cada par de metrópoles em diferentes domínios de disponibilidade de borda. Configure o BGP.

Por quê: Redundância em áreas metropolitanas separadas e domínios de falha (domínios de disponibilidade de borda) é necessária para o SLA de 99,99%.

Referência↗

Precisa de uma conexão híbrida criptografada, confiável (SLA de 99,9% ou 99,99%) e rapidamente implantável com largura de banda moderada (< 6 Gbps).

→Use HA VPN com BGP para roteamento dinâmico. Para SLA de 99,99%, use dois gateways HA VPN. Para SLA de 99,9%, use um único gateway com dois túneis.

Por quê: A HA VPN é mais rápida de configurar do que o Interconnect, fornece um SLA robusto e oferece largura de banda suficiente para muitos casos de uso, tornando-a a escolha padrão para conexões não físicas.

Criptografe todo o tráfego que atravessa um link Dedicated ou Partner Interconnect para conformidade.

→Configure HA VPN sobre Interconnect. Crie túneis HA VPN que usam os anexos VLAN do Interconnect para seu transporte subjacente.

Por quê: Este padrão combina a alta largura de banda e baixa latência do Interconnect com a criptografia IPsec da HA VPN, proporcionando o melhor dos dois mundos.

Estabeleça conectividade dedicada, privada e de alta largura de banda entre o GCP e outro grande provedor de nuvem (AWS, Azure, OCI).

→Use o Cross-Cloud Interconnect. Provisione uma conexão física dedicada entre a rede do Google e a rede do outro provedor de nuvem. Configure o BGP com o Cloud Router.

Por quê: Fornece um caminho direto, com SLA garantido e de baixa latência entre nuvens, evitando a internet pública e o desempenho variável das VPNs.

Uma rede local conectada via Interconnect a uma região GCP precisa acessar recursos em todas as outras regiões GCP.

→Habilite o modo de roteamento dinâmico "Global" na VPC. O Cloud Router então anunciará rotas para todas as sub-redes na VPC, não apenas para aquelas em sua região local.

Por quê: O roteamento global permite que um único ponto de conexão híbrida sirva como uma porta de entrada para toda a rede global do Google, simplificando o acesso multi-região.

Influenciar a seleção do caminho do tráfego em conexões híbridas redundantes (VPN/Interconnect) usando BGP.

→Para influenciar o tráfego de GCP para a rede local, faça com que a rede local anuncie rotas mais específicas ou use um AS_PATH mais curto para o caminho preferencial. Para influenciar o tráfego da rede local para o GCP, anuncie do Cloud Router com um valor MED mais baixo para o caminho preferencial.

Por quê: A seleção de caminho BGP segue um algoritmo claro. A correspondência de prefixo mais longo é fundamental para o tráfego de saída, enquanto o MED influencia as decisões de tráfego de entrada.

Configure um failover ativo/passivo entre um Dedicated Interconnect primário e um HA VPN de backup.

→Use BGP em ambos. No Cloud Router, anuncie rotas sobre o Interconnect com uma prioridade base mais baixa (por exemplo, 100) e sobre a VPN com uma prioridade base mais alta (por exemplo, 200).

Por quê: O GCP prefere rotas BGP com um valor de prioridade mais baixo (preferência mais alta). O tráfego usa o Interconnect primário. Em caso de falha, suas rotas são retiradas e as rotas da VPN de backup tornam-se ativas.

Evite a exfiltração de dados de serviços sensíveis do Google Cloud (por exemplo, BigQuery, GCS), garantindo acesso apenas de redes autorizadas.

→Implemente o VPC Service Controls. Crie um perímetro de serviço em torno de projetos com dados sensíveis. Configure níveis de acesso para definir fontes autorizadas (intervalos de IP, estado do dispositivo, identidade).

Por quê: O VPC-SC cria um limite de rede virtual em torno dos serviços gerenciados pelo Google, bloqueando o acesso de fora do perímetro mesmo com credenciais válidas. Um controle crítico de governança de dados.

Referência↗

Aplique regras de firewall de linha de base consistentes e não substituíveis em toda uma organização, permitindo personalização em nível de projeto.

→Implemente Políticas de Firewall Hierárquicas no nível da organização ou pasta. Coloque as regras críticas aqui. Use a ação `goto_next` para delegar a avaliação a políticas de nível inferior.

Por quê: As políticas hierárquicas são avaliadas antes das regras em nível de VPC e não podem ser modificadas pelos proprietários do projeto, garantindo governança centralizada. `goto_next` oferece flexibilidade.

Proteja uma aplicação web contra vulnerabilidades do OWASP Top 10 e aplique limitação de taxa por IP de cliente.

→Anexe uma política de segurança do Cloud Armor ao Global External Application LB. Aplique regras WAF pré-configuradas (por exemplo, `sqli-v3.3-stable`) e adicione uma regra baseada em taxa.

Por quê: O Cloud Armor oferece segurança de borda. Regras WAF pré-configuradas fornecem proteção gerenciada, enquanto regras baseadas em taxa mitigam ataques DoS e de força bruta.

Implemente segurança de rede granular, em nível de pod, dentro de um cluster GKE com base em rótulos.

→Habilite a aplicação de Network Policy no cluster GKE. Crie recursos `NetworkPolicy` do Kubernetes que definem regras de entrada/saída para pods usando seletores de rótulo.

Por quê: NetworkPolicy do Kubernetes é a forma nativa de implementar microsegmentação no nível do pod, oferecendo mais granularidade do que as regras de firewall de VPC que operam no nível do nó.

Inspecione todo o tráfego inter-VPC ou VPC-para-internet usando um firewall/NVA centralizado de terceiros.

→Crie uma topologia hub-and-spoke. Implante o(s) NVA(s) em uma VPC hub. Configure rotas personalizadas nos spokes que direcionam o tráfego para um Internal Load Balancer no hub como o próximo salto.

Por quê: Este padrão força o tráfego através de um ponto de inspeção central. O ILB fornece um IP de próximo salto estável e altamente disponível para os NVAs.

Forneça acesso seguro, baseado em identidade, de confiança zero para usuários a aplicações web internas ou VMs sem usar uma VPN.

→Para aplicações web, habilite o IAP em um serviço de backend do External HTTPS LB. Para SSH/RDP, use o IAP para encaminhamento TCP. Conceda as funções IAM de IAP apropriadas aos usuários.

Por quê: O IAP move o controle de acesso do perímetro da rede para a identidade do usuário, autenticando e autorizando cada solicitação. É um componente central do modelo de confiança zero BeyondCorp do Google.

Implemente prevenção de ameaças (IDS/IPS) para tráfego inter-VPC ou VPC-para-internet, incluindo detecção de malware e inspeção TLS.

→Use o Cloud NGFW. Associe uma política de firewall à VPC, crie regras com perfis de segurança para prevenção de ameaças e, opcionalmente, habilite a inspeção TLS.

Por quê: O Cloud NGFW é o serviço de firewall distribuído e gerenciado do Google que oferece recursos avançados de inspeção L7 da Palo Alto Networks, integrado diretamente na VPC.

Inspecione, registre e controle centralmente todo o tráfego de saída da VPC para a internet para segurança e conformidade.

→Implante o Secure Web Proxy. Configure políticas de segurança para filtragem de URL e inspeção TLS. Encaminhe o tráfego das sub-redes para o proxy usando rotas personalizadas.

Por quê: Esta é a solução gerenciada do Google para saída segura, fornecendo visibilidade e controle L7 sem a necessidade de frotas de proxy auto-gerenciadas.

Diagnostique rapidamente uma falha de conectividade entre dois endpoints dentro do GCP (por exemplo, VM-para-VM, VM-para-Cloud SQL).

→Use os Testes de Conectividade do Network Intelligence Center. Especifique a origem e o destino, e ele analisará todo o caminho configurado em busca de problemas.

Por quê: Esta ferramenta não intrusiva fornece uma análise definitiva do caminho, identificando o ponto exato de falha (firewall, rota, etc.) muito mais rápido do que a inspeção manual.

Uma sessão BGP em uma conexão híbrida está reiniciando intermitentemente ("flapping").

→Verifique por uma incompatibilidade nos temporizadores BGP keepalive/hold. Se os temporizadores expirarem sob carga, aumente-os (por exemplo, 60s keepalive, 180s hold). Além disso, verifique as configurações de MTU e habilite o BFD.

Por quê: Temporizadores incompatíveis ou excessivamente agressivos são uma causa comum de "flaps" de BGP, pois o congestionamento transitório da rede pode atrasar os pacotes keepalive além do tempo de espera.

Investigue relatórios de aumento de latência para o tráfego entre regiões GCP.

→Use o Painel de Desempenho do Network Intelligence Center para visualizar métricas históricas e em tempo real de latência e perda de pacotes entre todos os pares de zonas GCP.

Por quê: Esta ferramenta oferece visibilidade direta do desempenho da rede backbone do Google, ajudando a distinguir entre um problema de aplicação e um problema de infraestrutura de rede.

VMs usando Cloud NAT experimentam falhas intermitentes de conexão de saída, e os logs NAT mostram quedas `OUT_OF_RESOURCES`.

→Isso é provavelmente exaustão de portas NAT. Aumente o número de IPs NAT alocados, aumente o "Minimum ports per VM instance" e/ou habilite a Alocação Dinâmica de Portas.

Por quê: Altas taxas de conexão de muitas VMs podem esgotar o pool de portas de origem alocadas por IP NAT. Alocar mais recursos é a correção necessária.