Ao projetar a zona de destino, você precisará escolher um design de rede que funcione para sua organização. Este documento descreve quatro projetos de rede comuns e ajuda você a escolher a melhor opção para os requisitos da organização, além da preferência da organização por controle centralizado ou descentralizado. Ele é destinado a engenheiros, arquitetos e profissionais técnicos de rede envolvidos na criação do design de rede para a zona de destino da sua organização.
Este artigo faz parte de uma série sobre zonas de destino.
Escolher o design da rede
O design de rede escolhido depende principalmente dos seguintes fatores:
- Controle centralizado ou descentralizado: dependendo das
preferências da sua organização, escolha uma das seguintes opções:
- Centralize o controle sobre a rede, incluindo endereçamento IP, roteamento e firewall entre diferentes cargas de trabalho.
- Ofereça às suas equipes maior autonomia para executar os próprios ambientes e criar elementos de rede dentro dos próprios ambientes.
- Opções de conectividade na nuvem local ou híbrida: todos os designs de rede discutidos neste documento fornecem acesso do ambiente local ao nuvem por meio do Cloud VPN ou Cloud Interconnect. No entanto, alguns designs exigem que você configure várias conexões em paralelo, enquanto outros usam a mesma conexão para todas as cargas de trabalho.
- Requisitos de segurança: sua organização pode exigir que o tráfego entre diferentes cargas de trabalho no Google Cloud seja transmitido por dispositivos de rede centralizados, como: Firewalls de última geração (NGFW) de dados. Essa restrição influencia o design da rede da nuvem privada virtual (VPC).
- Escalonabilidade: alguns designs podem ser melhores para sua organização do que outros, com base no número de cargas de trabalho que você quer implantar e no número de máquinas virtuais (VMs), carga interna balanceadores de carga e outros recursos que consumirão.
Pontos de decisão para o design da rede
O fluxograma a seguir mostra as decisões que você precisa tomar para escolher o melhor design de rede para sua organização.
O diagrama anterior orienta você nas seguintes perguntas:
- Você precisa da inspeção da
camada 7
usando dispositivos de rede entre diferentes cargas de trabalho no
Google Cloud?
- Em caso afirmativo, consulte Topologia "hub and spoke" com dispositivos centralizados.
- Se não, vá para a próxima pergunta.
- Muitas das suas cargas de trabalho exigem conectividade local?
- Em caso afirmativo, avance para o ponto de decisão 4.
- Se não, vá para a próxima pergunta.
- Suas cargas de trabalho podem se comunicar usando endpoints particulares em um modelo de
produtor e consumidor de serviços?
- Em caso afirmativo, consulte Expor serviços em um modelo de produtor-consumidor com o Private Service Connect.
- Se não, vá para a próxima pergunta.
- Você quer administrar o firewall e o roteamento de forma centralizada?
- Em caso afirmativo, consulte Rede VPC compartilhada para cada ambiente.
- Caso contrário, consulte Topologia hub e spoke sem dispositivos.
O objetivo desse gráfico é ajudar você a tomar uma decisão. No entanto, muitas vezes é possível que vários designs sejam adequados para sua organização. Nessas instâncias, recomendamos que você escolha o design mais adequado ao seu caso de uso.
Opções de design de rede
As seções a seguir descrevem quatro opções comuns de design. Recomendamos a opção 1 para a maioria dos casos de uso. Os outros designs discutidos nesta seção são alternativas que se aplicam a requisitos organizacionais específicos de caso extremo.
A melhor opção para seu caso de uso também pode ser uma rede que combina elementos de várias opções de design discutidas nesta seção. Por exemplo, é possível usar redes VPC compartilhadas em topologias hub e spoke para melhor colaboração, controle centralizado e para limitar o número de spokes VPC. Outra possibilidade é projetar a maioria das cargas de trabalho em uma topologia de VPC compartilhada, mas isolar um pequeno número delas em redes VPC separadas que expõem apenas serviços por meio de alguns endpoints definidos usando o Private Service Connect.
Opção 1: rede VPC compartilhada para cada ambiente
Recomendamos o design dessa rede para a maioria dos casos de uso. Esse design usa redes VPC compartilhadas separadas para cada ambiente de implantação que você tem no Google Cloud (desenvolvimento, teste e produção). Esse design permite gerenciar centralmente os recursos de rede em uma rede comum e fornece isolamento de rede entre os diferentes ambientes.
Use esse design quando o seguinte for verdadeiro:
- Você quer controle central sobre as regras de firewall e roteamento.
- Você precisa de uma infraestrutura simples e escalonável.
- Você precisa de um gerenciamento centralizado de espaço de endereço IP.
Evite esse design quando o seguinte for verdadeiro:
- Você quer que as equipes de desenvolvedores tenham autonomia total, incluindo a capacidade de gerenciar as próprias regras de firewall, roteamento e peering para outras redes de equipe.
- Você precisa da inspeção da camada 7 usando dispositivos NGFW.
O diagrama a seguir mostra um exemplo de implementação desse design.
O diagrama anterior mostra o seguinte:
- A rede local está distribuída entre duas localizações geográficas.
- A rede local se conecta por meio de instâncias redundantes do Cloud Interconnect a duas redes VPC compartilhadas separadas, uma para produção e outra para desenvolvimento.
- Os ambientes de produção e desenvolvimento estão conectados às duas instâncias do Cloud Interconnect com diferentes anexos da VLAN.
- Cada VPC compartilhada tem projetos de serviço que hospedam as cargas de trabalho.
- As regras de firewall são administradas centralmente no projeto host.
- O ambiente de desenvolvimento tem a mesma estrutura de VPC do ambiente de produção.
Por padrão, o tráfego de um ambiente não pode chegar a outro. No entanto, quando cargas de trabalho específicas precisam se comunicar umas com as outras, é possível permitir a transferência de dados por canais controlados no local ou compartilhar dados entre aplicativos com os serviços do Google Cloud, como o Cloud Storage ou o Pub/Sub. Recomendamos que você evite conectar diretamente ambientes separados por meio do peering de rede VPC, porque isso aumenta o risco de misturar dados acidentalmente entre os ambientes. O uso do peering de rede VPC entre ambientes grandes também aumenta o risco de atingir limites de cotas VPC em torno do peering e dos grupos de peering.
Para ver mais informações, consulte os seguintes tópicos:
- Visão geral de VPC compartilhada
- Arquitetura de VPC compartilhada no guia de bases empresariais
- Arquitetura de referência nas práticas recomendadas de design de VPC
- Estágio de implantação do Terraform: rede com ambientes separados como parte do framework Fabric FAST
- Estágio de rede para a base de exemplo do Terraform usando kit de ferramentas do Cloud Foundation
Para implementar essa opção de design, consulte Criar opção 1: rede VPC compartilhada para cada ambiente.
Opção 2: topologia de hub e spoke com dispositivos centralizados
Esse design de rede usa a topologia "hub and spoke". Uma rede VPC hub contém um conjunto de VMs de dispositivo, como NGFWs, que estão conectadas às redes VPC spoke que contêm as cargas de trabalho. O tráfego entre as cargas de trabalho, as redes locais ou a Internet é roteado pelas VMs de dispositivo para inspeção e filtragem.
Use esse design quando o seguinte for verdadeiro:
- A inspeção da camada 7 é necessária entre diferentes cargas de trabalho ou aplicativos.
- Você tem uma autorização corporativa que especifica o fornecedor do dispositivo de segurança para todo o tráfego.
Evite esse design quando o seguinte for verdadeiro:
- A inspeção da camada 7 não é necessária para a maioria das suas cargas de trabalho.
- Você quer que as cargas de trabalho no Google Cloud não se comuniquem entre si.
- Você só precisa da inspeção da camada 7 para o tráfego que vai para redes locais, conforme descrito em Caso de uso especial com uma rede VPC compartilhada no Google Cloud.
O diagrama a seguir mostra um exemplo de implementação desse padrão.
O diagrama anterior mostra o seguinte:
- Um ambiente de produção que inclui uma rede VPC hub e várias redes VPC spoke que contêm as cargas de trabalho.
- As redes VPC spoke são conectadas com a rede VPC hub usando o peering de rede VPC.
- A rede VPC hub tem várias instâncias de um dispositivo virtual em um grupo de instâncias gerenciadas. O tráfego para o grupo gerenciado de instâncias passa por um balanceador de carga de rede de passagem interna.
- As redes VPC spoke se comunicam entre si por meio de dispositivos virtuais usando rotas estáticas com o balanceador de carga interno como o próximo salto.
- O Cloud Interconnect conecta as redes VPC de transporte público aos locais.
- As redes locais são conectadas por meio das mesmas Cloud Interconnects usando anexos da VLAN separados.
- As redes VPC de transporte público estão conectadas a uma interface de rede separada nos dispositivos virtuais. Isso permite inspecionar e filtrar todo o tráfego de entrada e saída dessas redes usando o dispositivo.
- O ambiente de desenvolvimento tem a mesma estrutura de VPC do ambiente de produção.
- Essa configuração não usa a conversão de endereços de rede de origem (SNAT). A SNAT não é necessária porque o Google Cloud usa hash simétrico. Para mais informações, consulte Hash simétrico.
Por padrão, o tráfego de uma rede spoke não pode chegar a outra rede spoke. No entanto, quando cargas de trabalho específicas precisam se comunicar umas com as outras, é possível configurar o peering direto entre as redes spoke usando o peering de rede VPC ou compartilhar dados entre aplicativos com os serviços do Google Cloud, como o Cloud Storage ou o Pub/Sub.
Para manter a baixa latência quando o dispositivo se comunica entre cargas de trabalho, o dispositivo precisa estar na mesma região das cargas de trabalho. Se você usar várias regiões na sua implantação na nuvem, poderá ter um conjunto de dispositivos e uma VPC hub para cada ambiente em cada região. Como alternativa, use tags de rede com rotas para que todas as instâncias se comuniquem com o dispositivo mais próximo.
As regras de firewall podem restringir a conectividade nas redes VPC spoke que contêm cargas de trabalho. Muitas vezes, as equipes que administram as cargas de trabalho também gerenciam essas regras de firewall. Para políticas centrais, use as políticas hierárquicas de firewall. Se você precisar que uma equipe de rede central tenha controle total sobre as regras de firewall, implante-as de maneira centralizada em todas as redes VPC usando uma abordagem de GitOps. Nesse caso, restrinja as permissões do IAM apenas aos administradores que podem alterar as regras de firewall. Redes VPC spoke também podem ser redes VPC compartilhadas se várias equipes forem implantadas nos spokes.
Nesse design, recomendamos que você use o peering de rede VPC para conectar a rede VPC hub e as redes VPC spoke, porque isso aumenta a complexidade. No entanto, o número máximo de spokes é limitado pelo seguinte:
- O limite em conexões de peering de rede VPC de uma única rede VPC.
- Limites de grupos de peering, como o número máximo de regras de encaminhamento para o balanceamento de carga TCP/UDP interno de cada grupo de peering.
Se você espera alcançar esses limites, conecte as redes spoke pelo Cloud VPN. O uso do Cloud VPN adiciona custos e complexidades extras e cada túnel do Cloud VPN tem um limite de largura de banda.
Para ver mais informações, consulte os seguintes tópicos:
- Appliances de rede centralizados no Google Cloud
- Arquitetura de conectividade do hub e spoke no guia "Princípios básicos empresariais"
- Estágio de implantação do Terraform: rede com dispositivo virtual de rede como parte do framework FAST do Fabric
- Módulo de trânsito hub e spoke como parte do exemplo de base
Para implementar essa opção de design, consulte Criar opção 2: topologia de hub e spoke com dispositivos centralizados.
Opção 3: topologia de hub e spoke sem dispositivos
Esse design de rede também usa uma topologia "hub and spoke", com uma rede VPC hub que se conecta a redes locais e redes VPC spoke que contêm as cargas de trabalho. Como o peering de rede VPC não é transitivo, as redes spoke não podem se comunicar diretamente entre si.
Use esse design quando o seguinte for verdadeiro:
- Você quer que cargas de trabalho ou ambientes no Google Cloud não se comuniquem usando endereços IP internos, mas que eles compartilhem conectividade local.
- Você quer dar autonomia às equipes no gerenciamento das próprias regras de firewall e roteamento.
Evite esse design quando o seguinte for verdadeiro:
- A inspeção da camada 7 é necessária entre as cargas de trabalho.
- Você quer gerenciar de modo centralizado as regras de roteamento e firewall.
- Você precisa de comunicações de serviços locais para serviços gerenciados conectados aos spokes por meio de outro peering de rede VPC, porque o peering de rede VPC não é transitivo.
O diagrama a seguir mostra um exemplo de implementação desse design.
O diagrama anterior mostra o seguinte:
- Um ambiente de produção que inclui uma rede VPC hub e várias redes VPC spoke que contêm as cargas de trabalho.
- As redes VPC spoke são conectadas com a rede VPC hub usando o peering de rede VPC.
- A conectividade com locais no local passa por conexões do Cloud Interconnect na rede VPC hub.
- As redes locais são conectadas por meio das instâncias do Cloud Interconnect usando anexos da VLAN separados.
- O ambiente de desenvolvimento tem a mesma estrutura de VPC do ambiente de produção.
Por padrão, o tráfego de uma rede spoke não pode chegar a outra rede spoke. No entanto, quando cargas de trabalho específicas precisam se comunicar umas com as outras, é possível configurar o peering direto entre as redes spoke usando o peering de rede VPC ou compartilhar dados entre aplicativos com os serviços do Google Cloud, como o Cloud Storage ou o Pub/Sub.
Esse design de rede geralmente é usado em ambientes em que as equipes atuam de maneira autônoma, e não há controle centralizado sobre regras de firewall e roteamento. No entanto, a escala desse design é limitada pelo seguinte:
O limite em conexões de peering de rede VPC de uma única rede VPC
Limites de grupos de peering, como o número máximo de regras de encaminhamento para o balanceamento de carga de rede de passagem interna de cada grupo de peering
Portanto, esse design geralmente não é usado em grandes organizações que têm muitas cargas de trabalho separadas no Google Cloud.
Como variação do design, é possível usar o Cloud VPN em vez do peering de rede VPC. O Cloud VPN permite aumentar o número de spokes, mas adiciona um limite de largura de banda para cada túnel e aumenta a complexidade e os custos. Quando você usa divulgações de rota personalizadas, o Cloud VPN também permite a transitividade entre os spokes, sem exigir que você conecte diretamente todas as redes spoke.
Para ver mais informações, consulte os seguintes tópicos:
- Arquitetura de rede hub-and-spoke
- Arquitetura hub e spoke no guia de bases empresariais
- Estágio de implantação do Terraform: rede com peering de rede VPC como parte do framework FAST do Fabric
- Estágio de implantação do Terraform: rede com o Cloud VPN como parte do framework FAST do Fabric
Para implementar essa opção de design, consulte Criar opção 3: topologia de hub e spoke sem dispositivos.
Opção 4: expor serviços em um modelo de produtor-consumidor com o Private Service Connect
Nesse design de rede, cada equipe ou carga de trabalho recebe a própria rede VPC, que pode ser uma rede VPC compartilhada. Cada rede VPC é gerenciada de maneira independente e usa o Private Service Connect para expor todos os serviços que precisam ser acessados de fora da rede VPC.
Use esse design quando o seguinte for verdadeiro:
- As cargas de trabalho só se comunicam entre si e com o ambiente local por meio de endpoints definidos.
- Você quer que as equipes sejam independentes umas das outras e gerenciem o próprio espaço de endereço IP, os firewalls e as regras de roteamento.
Evite esse design quando o seguinte for verdadeiro:
- A comunicação entre serviços e aplicativos usa muitas portas ou canais diferentes, ou as portas e os canais mudam com frequência.
- A comunicação entre cargas de trabalho usa protocolos diferentes de TCP ou UDP.
- A inspeção da camada 7 é necessária entre as cargas de trabalho.
O diagrama a seguir mostra um exemplo de implementação desse padrão.
O diagrama anterior mostra o seguinte:
- Cargas de trabalho separadas estão localizadas em projetos e redes VPC diferentes.
- Uma VM cliente em uma rede VPC pode se conectar a uma carga de trabalho em outra rede VPC por meio de um endpoint do Private Service Connect.
- O endpoint é anexado a um anexo de serviço na rede VPC em que o serviço está localizado. Se o endpoint estiver configurado para acesso global, o anexo de serviço poderá estar em uma região diferente da dele.
- O anexo do serviço se conecta à carga de trabalho pelo Cloud Load Balancing.
- Os clientes na VPC de carga de trabalho podem alcançar cargas de trabalho localizadas no local da seguinte maneira:
- O endpoint é conectado a um anexo de serviço em uma rede VPC de trânsito.
- O anexo do serviço é conectado à rede local por meio do Cloud Interconnect.
- Um balanceador de carga de aplicativo interno é associado ao anexo do serviço e usa um grupo de endpoints de rede híbrido para equilibrar a carga de tráfego entre os endpoints localizados no local.
- Os clientes locais também podem alcançar os endpoints na rede VPC de transporte público que se conectam a anexos de serviço nas redes VPC de carga de trabalho.
Para ver mais informações, consulte os seguintes tópicos:
- Publicar serviços gerenciados sando o Private Service Connect
- Acessar serviços publicados por meio de endpoints
Para implementar essa opção de design, consulte Criar opção 4: expor serviços em um modelo de produtor-consumidor com o Private Service Connect.
Práticas recomendadas para implantação de rede
Depois de escolher o melhor design de rede para seu caso de uso, recomendamos que você implemente as seguintes práticas recomendadas:
- Use redes VPC de modo personalizado e exclua a rede padrão para ter mais controle sobre os endereços IP dela.
Limitar o acesso externo usando o Cloud NAT para recursos que precisam de acesso à Internet e reduzindo o uso de endereços IP públicos a recursos acessíveis por meio do Cloud Load Balancing. Para mais informações, consulte Como criar conectividade com a Internet para VMs privadas.
Se você usa o Cloud Interconnect, siga as topologias recomendadas para aplicativos não críticos ou para envolvidos na produção. Use conexões redundantes para atender ao SLA do serviço. Como alternativa, conecte o Google Cloud a redes locais por meio do Cloud VPN.
Aplique as políticas apresentadas em Limitar o acesso externo usando uma política da organização para restringir o acesso direto da VPC à Internet.
Use políticas de firewall hierárquicas para herdar políticas de firewall de maneira consistente em toda a organização ou em todas as pastas.
Siga as práticas recomendadas de DNS para DNS híbrido entre sua rede local e o Google Cloud.
Para mais informações, consulte Práticas recomendadas e arquiteturas de referência para o design da VPC.
A seguir
- Implementar o design de rede de zona de destino do Google Cloud
- Decida a segurança da sua zona de destino do Google Cloud (próximo documento desta série).
- Leia Práticas recomendadas para o design de redes VPC.
- Saiba como usar dispositivos de rede centralizados no Google Cloud.
- Leia mais sobre o Private Service Connect.