Neste guia, apresentamos as práticas recomendadas e as arquiteturas empresariais comuns para o projeto de nuvem privada virtual (VPC) com o Google Cloud. Ele é destinado a arquitetos de rede de nuvem e arquitetos de sistemas que já estão familiarizados com os conceitos de rede Google Cloud .
Princípios gerais e primeiras etapas
identifique tomadores de decisão, cronogramas e pré-trabalho.
Considerar o design da rede VPC antecipadamente.
Simplificar.
Usar convenções de nomenclatura claras.
Identificar tomadores de decisão, cronogramas e trabalhos preliminares
Como primeiro passo no design da rede VPC, identifique os tomadores de decisão, os cronogramas e o pré-trabalho necessários para garantir que você atenda aos requisitos das partes interessadas.
As partes interessadas incluem proprietários de aplicativos, arquitetos de segurança ou de soluções e gerentes de operações. As próprias partes interessadas podem mudar dependendo do objetivo da rede VPC: para um projeto, uma linha de negócios ou toda a organização.
Parte do pré-trabalho é familiarizar a equipe com os conceitos e a terminologia do design da rede VPC. Veja alguns documentos úteis:
- Documentação do Resource Manager
- Documentação do Identity and Access Management (IAM)
- Documentação da nuvem privada virtual
Considerar o design da rede VPC antecipadamente
Faça do design de rede VPC uma parte inicial da criação da configuração organizacional no Google Cloud. Isso pode ser prejudicial para sua organização se você precisar alterar itens fundamentais, por exemplo, a forma como sua rede é segmentada ou onde suas cargas de trabalho estão localizadas.
Diferentes configurações de rede VPC podem ter implicações significativas no roteamento, no escalonamento e na segurança. Planeje com cuidado suas especificações e as entenda profundamente para criar uma base arquitetônica sólida para cargas de trabalho incrementais.
Simplifique
Manter o design da topologia de rede VPC simples é a melhor maneira de garantir uma arquitetura gerenciável, confiável e bem compreendida.
Usar convenções de nomenclatura claras
Use convenções de nomenclatura simples, intuitivas e consistentes. Isso garante que os administradores e usuários finais entendam a finalidade de todos os recursos, onde eles estão localizados e quais as diferenças entre eles.
Use abreviaturas comuns de palavras grandes para aumentar a simplicidade. Para melhorar a legibilidade, utilize terminologias conhecidas sempre que possível.
Pense nos componentes ilustrados no exemplo a seguir ao estabelecer as convenções de nomenclatura:
- Nome da empresa: Acme Company –
acmeco - Unidade de negócios: Recursos humanos –
hr - Código do aplicativo: sistema de compensação –
comp - Código da região: northamerica-northeast1 –
na-ne1, europe-west1 –eu-we1 - Códigos de ambiente:
dev,test,uat,stage,prod
Neste exemplo, o ambiente de desenvolvimento do sistema de remuneração do departamento de recursos humanos é chamado de acmeco-hr-comp-eu-we1-dev.
Para outros recursos de rede comuns, pense em padrões como estes:
Rede VPC
sintaxe:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
exemplo:acmeco-hr-dev-vpc-1Sub-rede
sintaxe:{company-name}-{description(App or BU)-label}-{region-label}-{environment-label}-{subnet-label}
exemplo:acmeco-hr-na-ne1-dev-vpc-1-subnet-1
observação: se uma sub-rede tiver recursos em apenas uma zona, use "zone-label" em vez de "region-label".Regra de firewall
sintaxe:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
exemplo:acmeco-hr-internet-internal-tcp-80-allow-ruleRota de IP
sintaxe:{priority}-{VPC-label}-{tag}-{next hop}
exemplo:1000-acmeco-hr-dev-vpc-1-int-gw
Endereços e sub-redes
use sub-redes de modo personalizado nas redes VPC empresariais.
Agrupar aplicativos em menos sub-redes com intervalos de endereços maiores.
Usar redes VPC de modo personalizado
As redes VPC de modo automático são mais úteis na exploração inicial. Já as de modo personalizado são mais adequadas para a maioria dos ambientes de produção.
Recomendamos que as empresas usem redes VPC de modo personalizado desde o início do processo pelos seguintes motivos:
- As redes VPC de modo personalizado se integram melhor aos esquemas atuais de gerenciamento de endereços IP. Como todas as redes de modo automático usam o mesmo conjunto de intervalos IP internos, os intervalos nesse modo podem se sobrepor quando conectados às redes corporativas locais.
- Não é possível conectar duas redes VPC de modo automático usando o Peering de rede VPC porque as sub-redes delas usam intervalos IP primários idênticos.
- Todas as sub-redes de modo automático têm o mesmo nome da rede. É possível escolher nomes exclusivos e descritivos para sub-redes de modo personalizado. Isso facilita a compreensão e a manutenção das redes VPC.
- Quando uma nova Google Cloud região é introduzida, as redes VPC de modo automático recebem automaticamente uma nova sub-rede nessa região. As redes VPC de modo personalizado só receberão novas sub-redes se você as especificar. Isso pode ser importante por motivos de soberania e gerenciamento de endereços IP.
Se não houver recursos, exclua a rede default. Não é possível excluir uma rede VPC até que todos os recursos, incluindo instâncias de máquina virtual (VM) que dependem dela sejam removidos.
Para detalhes sobre as diferenças entre as redes VPC de modo automático e personalizado, consulte a respectiva página visão geral.
Agrupe aplicativos em menos sub-redes com intervalos de endereços maiores
Por convenção, algumas redes empresariais são separadas em vários intervalos de endereços pequenos por diversos motivos. Por exemplo, para identificar ou isolar um aplicativo ou manter um domínio pequeno de broadcast.
No entanto, recomendamos que você agrupe aplicativos do mesmo tipo em menos sub-redes que sejam mais gerenciáveis, com intervalos de endereços maiores nas regiões que você pretende operar.
Ao contrário de outros ambientes de rede em que uma máscara de sub-rede é usada, oGoogle Cloud usa uma abordagem de rede definida por software (SDN, na sigla em inglês) para fornecer uma malha completa de alcance entre todas as VMs na rede VPC global. O número de sub-redes não afeta o comportamento de roteamento.
Use contas de serviço ou tags de rede para aplicar regras de firewall e políticas de roteamento específicas. A identidade no Google Cloud não se baseia exclusivamente no endereço IP de sub-rede.
Alguns recursos da VPC são configurados por sub-rede. Isso inclui o Cloud NAT, o Acesso privado do Google, os registros de fluxo da VPC e os intervalos de IP do alias. Se você precisa de um controle mais refinado desses recursos, use mais sub-redes.
Rede VPC única e VPC compartilhada
comece com uma única rede VPC para recursos que têm requisitos comuns.
Usar a VPC compartilhada na administração de vários grupos de trabalho.
Conceder o papel de usuário da rede no nível da sub-rede.
Usar um único projeto de host se os recursos exigirem várias interfaces de rede.
Usar vários projetos de host se os requisitos dos recursos excederem a cota de um projeto.
Usar vários projetos de host se precisar de políticas de administração separadas em cada VPC.
Começar com uma única rede VPC para recursos que têm requisitos comuns
Para muitos casos de uso simples, uma única rede VPC fornece os recursos necessários, além de ser mais fácil de criar, manter e entender do que as alternativas mais complexas. Ao agrupar recursos com requisitos e características comuns em uma rede VPC única, você começa a estabelecer a borda dela como perímetro para possíveis problemas.
Para um exemplo dessa configuração, consulte a arquitetura de referência de projeto único, rede VPC única.
Os fatores que podem levar você a criar redes VPC extras incluem escala, segurança de rede, considerações financeiras, requisitos operacionais e gerenciamento de identidade e acesso (IAM, na sigla em inglês).
Usar a VPC compartilhada na administração de vários grupos de trabalho
Para organizações com várias equipes, a VPC compartilhada oferece uma ferramenta eficaz para aprimorar a simplicidade arquitetônica de uma única rede VPC em vários grupos de trabalho. A abordagem mais simples é implantar um projeto de host com uma rede VPC compartilhada. Depois, você anexa os projetos de serviço da equipe à rede do projeto de host.
Nessa configuração, o controle e a política de rede de todos os recursos relacionados são centralizados e mais fáceis de gerenciar. Os departamentos do projeto de serviço podem configurar e gerenciar os recursos que não sejam de rede. Isso proporciona uma separação clara das responsabilidades de diferentes equipes na organização.
Os recursos nesses projetos podem se comunicar de maneira segura e eficiente entre os limites do projeto usando endereços IP internos. É possível gerenciar recursos de rede compartilhados em um projeto de host central, como sub-redes, rotas e firewalls. Isso possibilita que você aplique políticas de rede consistentes nos projetos.
Para conferir um exemplo dessa configuração, consulte a arquitetura de referência de projeto de host único, vários projetos de serviço e VPC compartilhada única.
Conceder o papel de usuário da rede no nível da sub-rede
O administrador da VPC compartilhada centralizada pode conceder aos membros o papel de usuário da rede (networkUser). Isso pode ser feito no nível da sub-rede, para garantir a autorização refinada de projetos de serviços, ou em todas as sub-redes no nível do projeto de host.
Seguindo o princípio do menor privilégio, recomendamos que você conceda ao grupo, conta de serviço ou usuário associado o papel de usuário da rede no nível da sub-rede.
Como as sub-redes são regionais, esse controle granular permite especificar quais regiões cada projeto de serviço pode usar para implantar recursos.
Com arquiteturas de VPC compartilhada, você também tem flexibilidade para implantar vários projetos de host com esse tipo de VPC na organização. Cada projeto de host com VPC compartilhada pode acomodar uma ou várias dessas redes. Nessa configuração, é possível aplicar com facilidade diferentes especificações de política de acordo com ambientes distintos.
Para mais informações, consulte Papéis do IAM para redes.
Usar um único projeto de host se os recursos exigirem várias interfaces de rede
Se você tiver um projeto de serviço que precise implantar recursos em várias redes VPC isoladas (por exemplo, instâncias de VM com várias interfaces de rede), seu projeto host precisará conter todas as redes VPC que fornecem os serviços. Isso acontece porque um projeto de serviço pode ser anexado a apenas um de host.
Usar vários projetos de host se os requisitos dos recursos excederem a cota de um projeto
Nos casos em que os requisitos de recursos agregados de todas as redes VPC não podem ser atendidos na cota de um projeto, use uma arquitetura com vários projetos host com uma única rede VPC compartilhada por projeto host, em vez de um único projeto host com várias redes VPC compartilhadas. É importante avaliar os requisitos de escala, já que o uso de um único projeto de host requer várias redes VPC no projeto de host e as cotas são aplicadas no nível do projeto.
Para conferir um exemplo dessa configuração, consulte a arquitetura de referência Vários projetos de host, vários projetos de serviço e várias VPCs compartilhadas.
Usar vários projetos de host se precisar de políticas de administração separadas para cada rede VPC
Como cada projeto tem a própria cota, use um projeto de host com VPC compartilhada separado para que todas as VPCs escalonem os recursos agregados. Assim, cada VPC tem permissões do IAM separadas para a realização do gerenciamento de rede e segurança. Isso acontece porque as permissões do IAM também são implementadas no nível do projeto. Por exemplo, se você implantar duas VPCs, A e B, no mesmo projeto de host, o papel de administrador de rede (networkAdmin) será aplicado a ambas.
Como decidir se você quer criar várias redes VPC
crie uma única rede VPC por projeto para mapear cotas de rede VPC para projetos.
Criar uma rede VPC para cada equipe autônoma, com serviços compartilhados em uma rede VPC comum.
Criar redes VPC em projetos diferentes para controles IAM independentes.
Isolar dados confidenciais na própria rede VPC.
Criar uma única rede VPC por projeto para mapear cotas de recursos da VPC para projetos
Cotas são restrições aplicadas no nível do projeto ou da rede. Todos os recursos têm uma cota padrão inicial que protege você do uso inesperado de recursos. No entanto, muitos fatores podem levar você a querer mais cota. Para a maioria dos recursos, é possível solicitar mais cota.
Se você espera que seu crescimento vá além das cotas de recursos padrão da VPC, recomendamos a criação de uma única VPC por projeto. Isso facilita o mapeamento de aumentos de cota no nível do projeto para cada rede VPC, em vez de uma combinação de redes VPC no mesmo projeto.
Limites são projetados para proteger os recursos agregados do sistema. Geralmente, eles não são gerados com facilidade. No entanto, as equipes de vendas e suporte doGoogle Cloud podem trabalhar com você para aumentar alguns limites.
Acesse Cotas e limites de recursos da VPC para conferir os valores atuais.
O suporte do Google pode aumentar alguns limites de escalonamento, mas pode haver momentos em que você precise criar várias redes VPC para atender aos requisitos de escalonamento. Se sua rede VPC tiver um requisito para escalonar além dos limites, fale sobre seu caso com as equipes de vendas e suporte doGoogle Cloud sobre a melhor abordagem para suas necessidades.
Criar uma rede VPC para cada equipe autônoma, com serviços compartilhados em uma rede VPC comum
Algumas implantações corporativas grandes envolvem equipes autônomas que exigem controle total sobre as respectivas redes VPC. Para atender a esse requisito, crie uma VPC para cada unidade de negócios, com serviços compartilhados em uma rede VPC comum. Por exemplo, ferramentas de análise, máquinas de compilação e pipelines de CI/CD e serviços de DNS/Directory.
Criar redes VPC em projetos diferentes para controles IAM independentes
Uma rede VPC é um recurso para envolvidos no projeto com controles de gerenciamento de identidade e acesso (IAM, na sigla em inglês) detalhados, incluindo os seguintes papéis:
networkAdminsecurityAdminnetworkUsernetworkViewer
Por padrão, os controles do IAM são implantados no nível do projeto, e cada papel do IAM se aplica a todas as redes VPC no projeto.
Se você precisar de controles independentes do IAM por rede VPC, crie as VPCs em projetos diferentes.
Se você precisar de papéis do IAM definidos para recursos específicos do Compute Engine, como instâncias de VM, discos e imagens, use as políticas do IAM para recursos do Compute Engine.
Isolar dados confidenciais na própria rede VPC
É recomendável aplicar medidas extras de segurança nas empresas que lidam com iniciativas de conformidade, dados confidenciais ou informações altamente regulamentadas que estejam vinculadas por padrões como HIPAA ou PCI-DSS. Um método que pode melhorar a segurança e facilitar a comprovação da conformidade é isolar cada um desses ambientes na própria rede VPC.
Como conectar várias redes VPC
escolha o método de conexão VPC que atenda às suas necessidades de custo, desempenho e segurança.
Usar spokes VPC do Network Connectivity Center.
Use o peering de rede VPC se precisar inserir NVAs ou se o aplicativo não for compatível com o Private Service Connect.
Use o roteamento externo se você não precisa da comunicação de endereço IP particular.
Use o Cloud VPN para conectar redes VPC que hospedam pontos de acesso a serviços não acessíveis transitivamente pelo Network Connectivity Center.
Usar dispositivos virtuais multi-NIC para controlar o tráfego entre redes VPC por meio de um dispositivo na nuvem.
Escolher o método de conexão da VPC que atenda às necessidades de custo, desempenho e segurança
A próxima etapa depois de decidir implementar várias redes VPC é conectá-las. As redes VPC são espaços de locatário isolados na SDN Andromeda do Google, mas há várias maneiras de ativar a comunicação entre elas. Nas próximas seções, você verá práticas recomendadas para escolher um método de conexão da VPC.
As vantagens e desvantagens de cada opção são resumidas na tabela a seguir. Nas próximas seções, você vê práticas recomendadas para escolher um método de conexão da VPC.
| Vantagens | Desvantagens | |
|---|---|---|
| Spokes de VPC do Network Connectivity Center |
|
|
| Peering de rede VPC |
|
|
| Roteamento externo (IP público ou gateway NAT) |
|
|
| Cloud VPN |
|
|
| Várias interfaces de rede (multi-NIC, na sigla em inglês) |
|
|
Usar spokes VPC do Network Connectivity Center
Recomendamos que você use spokes de VPC do Network Connectivity Center quando precisar conectar redes VPC. Os spokes de VPC do Network Connectivity Center permitem a reutilização de endereços em várias VPCs no mesmo projeto e organização ou em um projeto e organização diferentes.
Os spokes VPC do Network Connectivity Center são o método preferido para conectar redes VPC pelos seguintes motivos:
- O plano de dados é distribuído, então não há gargalo de gateway. O tráfego viaja entre as redes VPC como se as VMs estivessem na mesma rede VPC.
- Conectividade entre redes em diferentes organizações. As redes incluem VPCs e redes externas.
- Até 250 redes VPC por hub.
- Acessibilidade transitiva entre VPCs de pontos de acesso ao serviço.
- Integração do Cloud NAT entre VPCs para permitir a reutilização de endereços IP em várias VPCs.
- Definidas regras de acessibilidade de rede usando topologias predefinidas e filtros de prefixo.
Use o peering de rede VPC se precisar inserir NVAs ou se o aplicativo não for compatível com o Private Service Connect.
Recomendamos usar o peering de rede VPC se você precisar inserir dispositivos virtuais de rede (NVAs), como VMs de firewall. Talvez seja necessário inserir NVAs para tráfego que atravessa várias redes VPC ou para conectividade particular com serviços que não são publicados usando o Private Service Connect.
Ao usar o Peering de rede VPC, verifique se os totais dos recursos necessários para todos os peers conectados diretamente não excedem os limites em instâncias de VM, número de conexões de peering e regras de encaminhamento interno.
O peering de rede VPC permite que duas redes VPC se conectem internamente pelo SDN do Google, independentemente de pertencerem ao mesmo projeto ou à mesma organização. O peering de rede VPC mescla o plano de controle e a propagação de fluxo entre cada peering, permitindo as mesmas características de encaminhamento como se todas as VMs estivessem na mesma rede VPC. Quando as redes VPC são pareadas, todas as sub-redes, intervalos de IP de alias e regras de encaminhamento internas ficam acessíveis. Além disso, cada rede VPC mantém o próprio firewall distribuído. O peering de rede VPC não é transitivo.
Usar o roteamento externo se você não precisa da comunicação de endereço IP particular
Se você não precisa da comunicação de endereços IP privados, use o roteamento externo com endereços IP externos ou um gateway NAT.
Quando uma rede VPC é implantada, uma rota para o gateway de Internet padrão do Google é provisionada com uma prioridade de 1.000. Se essa rota já existir e uma VM receber um endereço IP externo, as VMs podem enviar o tráfego de saída usando o gateway de Internet do Google. Também é possível implantar serviços em uma das várias ofertas públicas de balanceamento de carga do Google, garantindo que os serviços sejam acessados externamente.
As VMs com endereço externo se comunicam de maneira privada pelo backbone do Google, seja qual for a região e o nível do serviço de rede. Use regras de firewall Google Cloud para controlar o tráfego de entrada externo (entrada) nas VMs.
O roteamento externo é uma ótima opção para fins de dimensionamento. No entanto, é importante entender como o roteamento público afeta os custos. Para detalhes, consulte a documentação sobre preços de rede.
Use o Cloud VPN para conectar redes VPC que hospedam pontos de acesso a serviços não acessíveis de maneira transitiva pelo Network Connectivity Center.
A VPN de alta disponibilidade fornece um serviço gerenciado para conectar redes VPC criando túneis IPsec entre conjuntos de endpoints. Se você configurar os Cloud Routers com divulgações de rota personalizadas, poderá ativar o roteamento transitivo nas redes VPC e nas topologias "hub and spoke", conforme descrito posteriormente neste documento. Com o Network Connectivity Center, é possível usar túneis de alta disponibilidade como uma rede de trânsito entre redes locais, conforme explicado na documentação do Cloud VPN.
O Cloud VPN não oferece suporte a MTUs grandes. Para detalhes, consulte Considerações sobre MTU.
Usar dispositivos virtuais para controlar o tráfego entre redes VPC usando um dispositivo na nuvem
Várias VMs de interface de rede são comuns para redes VPC que exigem segurança ou serviços extras entre elas. Isso acontece porque elas permitem que as instâncias de VM conectem a comunicação entre redes VPC.
Uma VM pode ter apenas uma interface para cada rede VPC à qual se conecta. Para implantar uma VM em várias redes VPC, você precisa ter a permissão de IAM apropriada para cada rede VPC à qual a VM se conecta.
Lembre-se destas características quando implantar uma VM multi-NIC:
- Uma VM multi-NIC pode ter até oito interfaces.
- Os intervalos de IP da sub-rede das interfaces não podem se sobrepor.
Conectividade do serviço
O Private Service Connect permite que os consumidores acessem serviços de maneira particular na rede VPC sem precisar de um modelo de implantação orientado à rede. Da mesma forma, ele permite que produtores hospedem esses serviços em redes VPC separadas e ofereçam uma conexão particular aos consumidores na mesma organização ou em organizações diferentes. O Private Service Connect permite a conectividade com serviços gerenciados próprios e de terceiros, o que elimina a necessidade de alocação de sub-rede para acesso a serviços particulares e peering de rede VPC.
O Private Service Connect oferece um modelo de segurança centrado em serviços com os seguintes benefícios:
- Sem dependências compartilhadas
- Autorização explícita
- Performance de taxa de linha
O Private Service Connect está disponível em diferentes tipos que oferecem recursos e modos de comunicação distintos:
- Endpoints do Private Service Connect: os endpoints são implantados usando regras de encaminhamento que fornecem ao consumidor um endereço IP mapeado para o serviço do Private Service Connect.
- Back-ends do Private Service Connect: os back-ends são implantados usando grupos de endpoints de rede (NEGs) que permitem aos consumidores direcionar o tráfego para o balanceador de carga antes que ele chegue a um serviço do Private Service Connect. Se os back-ends forem implantados com um balanceador de carga HTTPS, eles poderão aceitar certificados.
- Interfaces do Private Service Connect: as interfaces permitem que o consumidor e o produtor originem tráfego, o que possibilita a comunicação bidirecional. As interfaces podem ser usadas na mesma rede VPC que endpoints e back-ends.
Uma alternativa ao Private Service Connect é o acesso a serviços particulares, que permite que os consumidores conectem os serviços do produtor por peering de rede VPC. Ao usar o acesso a serviços particulares, recomendamos que você considere a alocação de IP para cada serviço do produtor, a sobreposição de IP e a cota compartilhada.
Design híbrido: como conectar um ambiente no local
use o roteamento dinâmico quando possível.
Usar uma rede VPC de conectividade para escalonar uma arquitetura "hub and spoke" com várias redes VPC.
Depois que você identificar a necessidade de usar a conectividade híbrida e escolher uma solução que atenda aos requisitos de largura de banda, desempenho e segurança, pense em como integrá-la ao design da VPC.
O uso da VPC compartilhada diminui a necessidade de que cada projeto replique a mesma solução. Por exemplo, quando você integra uma solução do Cloud Interconnect a uma VPC compartilhada, todas as VMs podem acessar a conexão do Cloud Interconnect seja qual for a região ou projeto de serviço.
Usar o roteamento dinâmico quando possível
O roteamento dinâmico está disponível em todas as soluções híbridas, incluindo a VPN de alta disponibilidade, a VPN clássica, a Interconexão dedicada e o Partner Interconnect. Ele usa o Cloud Router do Google como locutor do protocolo de gateway de borda (BGP, na sigla em inglês) para fornecer roteamento dinâmico de BGP externo (eBGP, na sigla em inglês).
O Cloud Router não está no plano de dados, ele só cria rotas na SDN.
O roteamento dinâmico não usa tags, e o Cloud Router nunca publica novamente os prefixos aprendidos.
É possível ativar os dois modos do Cloud Router, regional ou global, em cada rede VPC. Se você escolher o roteamento regional, o Cloud Router divulgará apenas as sub-redes que co-residem na região em que o Cloud Router é implantado. Por outro lado, o roteamento global divulga todas as sub-redes da rede VPC fornecida, independentemente da região, mas penaliza as rotas divulgadas e aprendidas fora da região. Isso mantém a simetria dentro da região ao sempre dar preferência a uma interconexão local. A penalidade é calculada adicionando uma métrica MED igual a 200 mais o TTL em milissegundos entre as regiões.
Roteamento estático
O roteamento estático só está disponível na VPN clássica. Ele oferece a capacidade de definir uma rota de próximo salto que aponte para um túnel do Cloud VPN.
Por padrão, uma rota estática se aplica a todas as VMs na rede, independentemente da região. O roteamento estático também permite que os administradores de rede definam seletivamente a quais VMs a rota se aplica. Para isso, são usadas tags de instância, que podem ser especificadas quando você cria uma rota.
As rotas estáticas se aplicam globalmente na rede VPC, com a mesma prioridade de rota. Portanto, se você tiver vários túneis em diversas regiões com o mesmo prefixo e a mesma prioridade, a VM usará o ECMP baseado em hash e de cinco tuplas em todos os túneis. Para otimizar essa configuração, crie uma rota preferencial na região. Basta mencionar as tags de instância de cada região e criar as rotas preferenciais de acordo com isso.
Se você não quiser que o tráfego de saída passe pelo gateway de Internet padrão do Google, defina uma rota estática padrão preferencial para enviar todo o tráfego de volta ao local por meio de um túnel.
Usar uma rede VPC de conectividade para escalonar uma arquitetura "hub and spoke" com várias redes VPC
Se você precisar escalonar uma arquitetura "hub and spoke" com várias redes VPC, configure a conectividade híbrida centralizada em uma ou mais redes VPC dedicadas e adicione as conexões híbridas e todos os spokes da VPC a um hub do Network Connectivity Center. É necessário ativar a troca de rotas com spokes de VPC. Essa configuração permite que rotas estáticas ou aprendidas dinamicamente sejam exportadas para spokes da VPC, oferecendo configuração centralizada e escalonabilidade ao design da rede VPC.
O diagrama a seguir ilustra um design de conectividade híbrida centralizada usando o Network Connectivity Center:
Como alternativa, use o peering de rede VPC e rotas anunciadas personalizadas para fornecer acesso a conexões híbridas compartilhadas, se você não exceder os limites de recursos e precisar usar NVAs.
O diagrama a seguir ilustra a conectividade híbrida centralizada com rotas personalizadas de peering de rede VPC:
Esse design centralizado contrasta com a implantação de conectividade híbrida convencional, que usa túneis VPN ou anexos da VLAN em cada rede VPC individual.
Segurança de rede
identifique objetivos claros de segurança.
Limitar o acesso externo
Definir perímetros de serviço para dados confidenciais.
Gerencie o tráfego com Google Cloud regras de firewall quando possível.
Use conjuntos de regras de firewall mais amplos e em menos quantidade quando possível.
Isole as VMs usando contas de serviço quando possível.
Use a automação para monitorar as políticas de segurança ao utilizar tags.
Use ferramentas extras para proteger os aplicativos.
OGoogle Cloud fornece recursos robustos de segurança em toda a infraestrutura e serviços, desde a segurança física de data centers e hardware de segurança personalizado até equipes dedicadas de pesquisadores. No entanto, proteger os recursos doGoogle Cloud é uma responsabilidade compartilhada. Tome as medidas apropriadas para garantir que os aplicativos e os dados estejam protegidos.
Identifique objetivos claros de segurança
Antes de avaliar os controles de segurança nativos da nuvem ou capacitados para ela, comece com um conjunto de objetivos claros de segurança que todas as partes interessadas definam como parte fundamental do produto. Esses objetivos precisam enfatizar a viabilidade, a documentação e a iteração. Assim, é possível usá-los como referência e aprimorá-los ao longo do desenvolvimento.
Limite o acesso externo
Ao criar um recurso do Google Cloud que usa uma rede VPC, você escolhe uma rede e uma sub-rede onde o recurso reside. O recurso recebe um endereço IP interno de um dos intervalos de IP associados à sub-rede. Os recursos em uma rede VPC podem se comunicar por meio de endereços IP internos se as regras de firewall permitirem.
Limite o acesso à Internet apenas aos recursos que necessitam dela. Recursos com apenas um endereço IP interno privado ainda podem acessar muitos serviços e APIs do Google usando o Private Service Connect ou Private Google Access. O acesso permite que os recursos interajam com os principais serviços do Google e do Google Cloud enquanto permanecem isolados da Internet pública.
Além disso, use políticas organizacionais para restringir ainda mais quais recursos têm permissão para usar endereços IP externos.
Para permitir que as VMs acessem a Internet, use o proxy da Web seguro se o tráfego puder ser baixado por HTTP(S) e você quiser implementar controles de identidade. Caso contrário, use o Cloud NAT.
Definir perímetros de serviço para dados confidenciais
Para cargas de trabalho que envolvem dados confidenciais, use o VPC Service Controls para configurar os perímetros de serviço em torno dos recursos da VPC e dos serviços gerenciados pelo Google e para controlar a movimentação de dados no limite do perímetro. Com o VPC Service Controls, é possível agrupar projetos e sua rede local em um único perímetro que impede o acesso a dados por meio de serviços gerenciados pelo Google. Os perímetros de serviço não podem conter projetos de diferentes organizações. No entanto, é possível usar pontes para que projetos e serviços em diferentes perímetros de serviço se comuniquem.
Gerenciar o tráfego com regras de firewall Google Cloud quando possível
Google Cloud A VPC inclui um firewall com estado que é escalonável horizontalmente e aplicado a cada VM de maneira distribuída. Consulte a visão geral do Cloud NGFW para mais detalhes.
O Google Cloud Marketplace apresenta um grande ecossistema de soluções de terceiros, incluindo VMs que fazem o seguinte: fornecer segurança avançada (como proteção contra vazamento de informações, explorações de aplicativos e escalonamento de privilégios), detectar ameaças conhecidas ou não e aplicar a filtragem de URL. Ter uma única política de implementação de fornecedor nos provedores de serviço de nuvem e em ambientes no local também garante benefícios operacionais.
Normalmente, o tráfego é roteado para essas VMs ao especificar as rotas com prioridades iguais (para distribuir o tráfego usando um hash de cinco tuplas) ou diferentes (para criar um caminho redundante). Isso é mostrado nos vários caminhos para a sub-rede de desenvolvimento no diagrama a seguir.
A maioria das soluções requer várias VMs de interface de rede. Como uma VM não pode ter mais de uma interface por rede VPC, quando você cria uma VM com várias interfaces de rede, cada interface precisa ser anexada a uma rede VPC separada.
A escala também é uma consideração importante ao implantar soluções de terceiros na sua rede VPC pelos seguintes motivos:
- Limites: a maioria das ferramentas baseadas em VMs precisa ser inserida no caminho de dados. Isso requer uma VM de interface de várias redes que conecte várias redes VPC que residam no mesmo projeto. Como as cotas de recursos da VPC são definidas no nível do projeto, as necessidades de recursos agregados em todas as redes VPC podem se tornar limitadas.
- Desempenho: a introdução de um único obstáculo baseado em VM nos atributos de escalonabilidade totalmente horizontal de uma rede VPC vai contra as metodologias de projeto em nuvem. Para atenuar isso, é possível colocar vários dispositivos virtuais de rede (NVAs, na sigla em inglês) em um grupo de instâncias gerenciadas por trás de um balanceador de carga de rede de passagem interno.
Para considerar esses fatores nas arquiteturas com requisitos em grande escala, encaminhe os controles de segurança para os endpoints. Comece aumentando a proteção das VMs e usando regras de firewall do Google Cloud. Essa estratégia também pode envolver a introdução de agentes de inspeção do endpoint baseados em host que não mudam a arquitetura de encaminhamento da sua rede VPC usando várias VMs da interface de rede.
Para ver outro exemplo dessa configuração, consulte o firewall L7 com estado entre a arquitetura de referência de redes VPC.
Usar conjuntos de regras de firewall mais amplos e em menos quantidade quando possível
Somente um determinado número de regras pode ser programado em qualquer VM. No entanto, é possível combinar muitas regras em uma definição de regra complexa. Por exemplo, se todas as VMs na rede VPC precisarem permitir explicitamente 10 portas TCP de entrada, você terá duas opções: escrever 10 regras separadas, cada uma definindo uma única porta, ou definir uma única regra que inclua as 10 portas. A opção mais eficiente é definir uma regra para as 10 portas.
Crie um grupo de regras genéricas que se aplique a toda a rede VPC e use grupos de regras mais específicos para agrupamentos menores de VMs usando destinos. Em outras palavras, comece definindo regras amplas e configure progressivamente as regras mais restritas, conforme necessário:
- Aplique regras de firewall comuns a todas as VMs na rede VPC.
- Aplique regras de firewall que possam ser agrupadas em várias VMs, como um grupo de instâncias de serviço ou uma sub-rede.
- Aplique regras de firewall a VMs individuais, como um gateway NAT ou um Bastion Host.
Isolar as VMs usando contas de serviço quando possível
Muitas organizações têm ambientes que exigem regras específicas para um subconjunto das VMs em uma rede VPC. Há duas abordagens comuns que podem ser seguidas nestes casos: isolamento de sub-rede e filtragem de destino.
Isolamento da sub-rede
Com o isolamento de sub-rede, a sub-rede forma o limite de segurança em que as regras de firewall Google Cloud são aplicadas. Essa abordagem é comum em desenvolvimentos de rede no local e em casos em que os endereços IP e o posicionamento de rede criam parte da identidade da VM.
É possível identificar as VMs em uma sub-rede específica aplicando uma tag, tag de rede ou conta de serviço exclusiva a essas instâncias. Assim, é possível criar regras de firewall que se apliquem somente às VMs em uma sub-rede, ou seja, aquelas com a tag, tag de rede ou conta de serviço associada. Por exemplo, para criar uma regra de firewall que permita toda a comunicação entre VMs na mesma sub-rede, use a configuração de regra a seguir na página Regras de firewall:
- Destinos: tags de destino especificadas
- Tags de destino: subnet-1
- Filtro de origem: sub-redes
- Sub-redes: selecione a sub-rede pelo nome (exemplo: subnet-1).
Filtragem de destino
Com a filtragem de destino, todas as VMs ficam localizadas na mesma sub-rede ou fazem parte de um conjunto arbitrário de sub-redes. Nessa abordagem, a assinatura da sub-rede não é considerada parte da identidade da instância nas regras de firewall. Na verdade, é possível usar tags, tags de rede ou contas de serviço para restringir o acesso entre as VMs na mesma sub-rede. Cada grupo de VMs que usa regras de firewall iguais tem a mesma tag de rede aplicada.
Para ilustrar essa abordagem, pense em um aplicativo de três camadas: Web, app e banco de dados. Nele, todas as instâncias são implantadas na mesma sub-rede. A camada da Web se comunica com usuários finais e com a camada do app, que, por sua vez, se comunica com a camada do banco de dados. No entanto, nenhuma outra comunicação entre camadas é permitida. As instâncias que executam a camada da Web têm uma tag de rede web, as instâncias que executam a camada de aplicativo têm uma tag de rede de app, e as instâncias que executam a camada de banco de dados têm uma tag de rede de db.
Essa abordagem é adotada nestas regras de firewall:
| Regra 1: permitir usuários finais → camada da Web | Destinos: tags de destino especificadas Tags de destino: Web Filtro de origem: intervalos de IP Intervalos de IP de origem: 0.0.0.0/0 |
| Regra 2: permitir a camada da Web → camada do aplicativo | Destinos: Tags de destino especificadas Tags de destino: App Filtro de origem: Tags de origem Tags de origem: Web |
| Regra 3: permitir a camada do aplicativo → camada do banco de dados | Destinos: Tags de destino especificadas Tags de destino: dB Filtro de origem Tags de origem Tags de origem: app |
No entanto, mesmo que seja possível usar tags de rede para a filtragem de destino dessa maneira, recomendamos que você use tags ou contas de serviço sempre que possível. As tags de destino não são controladas por acesso e podem ser alteradas por alguém com o papel instanceAdmin enquanto as VMs estão em serviço. Já as tags e contas de serviço são controladas por acesso, ou seja, um usuário específico precisa ter uma autorização explícita para usá-las.
Só pode haver uma conta de serviço por instância, mas várias tags são aceitas. Além disso, as contas de serviço atribuídas a uma VM só podem ser alteradas quando ela é interrompida.
Usar a automação para monitorar as políticas de segurança ao utilizar tags
Se você usa tags de rede, lembre-se de que o administrador da instância pode alterá-las. Assim, a política de segurança pode ser burlada. Portanto, se você usa tags de rede em um ambiente de produção, utilize um framework de automação para ajudar a superar a falta de governança do IAM sobre as tags de rede.
Usar ferramentas extras para proteger os aplicativos
Além das regras de firewall, use estas outras ferramentas para proteger os aplicativos:
- Use um Google Cloud balanceador de carga HTTP(S) global para oferecer suporte a alta disponibilidade e normalização de protocolo.
- Integre o Google Cloud Armor ao balanceador de carga HTTP(S) para fornecer proteção contra DDoS e a capacidade de bloquear ou permitir endereços IP na extremidade da rede.
- Controle o acesso a apps usando o Identity-Aware Proxy (IAP) para verificar a identidade do usuário e o contexto da solicitação e, com isso, determinar se um usuário precisa receber acesso.
- Forneça uma única interface para insights de segurança, detecção de anomalias e detecção de vulnerabilidades com a Security Command Center.
Serviços de rede: NAT e DNS
Use endereços IP externo fixos com o Cloud NAT.
Reutilize endereços IP em várias VPCs com o Cloud NAT.
Use zonas de DNS particular para resolução de nomes.
Usar endereços IP externos fixos com o Cloud NAT
Se você precisar de endereços IP externos fixos de um intervalo de VMs, use o Cloud NAT. Por exemplo, no caso de um terceiro permitir solicitações de endereços IP externos específicos. Com o Cloud NAT, você tem um pequeno número de endereços IP NAT para cada região usada nas comunicações de saída.
O Cloud NAT também permite que as instâncias de VM se comuniquem pela Internet sem ter os próprios endereços IP externo regras de firewall Google Cloud são com estado. Ou seja, se uma conexão for permitida entre uma origem e uma meta, ou uma meta e um destino, todo o tráfego posterior em qualquer direção será permitido, desde que a conexão esteja ativa. Em outras palavras, as regras de firewall possibilitam a comunicação bidirecional uma vez que a sessão é estabelecida.
Reutilizar endereços IP em várias VPCs com o Cloud NAT
Os endereços IP podem ser reutilizados em várias VPCs quando o Cloud NAT para o Network Connectivity Center está ativado. O Cloud NAT entre VPCs está disponível quando as VPCs são conectadas usando spokes de VPC do Network Connectivity Center. Se os endereços IP da VPC se sobrepuserem a intervalos em redes externas, ative o NAT híbrido. Somente as conexões iniciadas de cargas de trabalho em Google Cloud para redes externas são traduzidas.
Usar zonas DNS particulares na resolução de nomes
Use zonas particulares no Cloud DNS para permitir que seus serviços sejam resolvidos com DNS na rede VPC usando endereços IP internos sem expor esse mapeamento ao lado externo.
Use o DNS split horizon para mapear serviços para diferentes endereços IP de dentro da rede VPC e de fora. Por exemplo, é possível ter um serviço exposto por meio de balanceamento de carga de rede da Internet pública, mas ter balanceamento de carga interno fornecendo o mesmo serviço usando o mesmo nome DNS dentro da rede VPC.
Acesso à API em serviços gerenciados do Google
use o gateway de Internet padrão sempre que possível.
Adicionar rotas explícitas para APIs do Google se você precisar modificar a rota padrão.
Implantar instâncias que usam APIs do Google na mesma sub-rede.
Usar o gateway padrão da Internet sempre que possível
O acesso dos recursos dentro da rede VPC às APIs do Google segue o próximo gateway padrão do gateway de Internet. Mesmo com o nome do gateway do próximo salto, o caminho do tráfego das instâncias para as APIs do Google permanece na rede do Google.
Por padrão, somente as instâncias de VM com um endereço IP externo podem se comunicar com os serviços e as APIs do Google. Se você precisar de acesso a partir de instâncias sem um endereço IP externo, configure endpoints do Private Service Connect ou use o recurso Acesso privado do Google para cada sub-rede. Isso não diminui as comunicações nas APIs do Google.
O Google Kubernetes Engine (GKE) ativa automaticamente o Acesso privado do Google nas sub-redes em que os nós são implantados. Todos os nós nessas sub-redes sem um endereço IP externo podem acessar os serviços gerenciados do Google.
Adicionar rotas explícitas para APIs do Google se você precisar modificar a rota padrão
Se você precisar modificar a rota padrão, adicione rotas explícitas para os intervalos de IP de destino da API do Google.
Nos ambientes em que a rota padrão (0.0.0.0/0) não usa o próximo salto de gateway de Internet padrão, configure rotas explícitas para os intervalos de endereços IP de destino usados pelas APIs do Google. Defina a próxima etapa das rotas explícitas para o gateway de Internet padrão. Um exemplo desse cenário é quando você precisa inspecionar todo o tráfego por meio de um dispositivo no local.
Implante instâncias que usam APIs do Google na mesma sub-rede
Implante instâncias que exigem acesso aos serviços e APIs do Google na mesma sub-rede e ative o Acesso privado do Google naquelas que não tiverem endereços IP externos. Como alternativa, configure endpoints do Private Service Connect.
Se você estiver acessando as APIs do Google do seu ambiente local usando o Acesso privado do Google, use Como configurar o Acesso privado do Google para hosts locais para acessar alguns serviços do Google em intervalos de endereços IP privados. Verifique quais serviços são compatíveis antes de ativar esse recurso, porque o acesso a outras APIs do Google por meio dos endereços IP fornecidos por esse serviço não estará disponível. A ativação desse recurso pode exigir outras configurações do DNS, como a definição das visualizações.
Se você estiver acessando as APIs do Google do seu ambiente local usando endpoints do Private Service Connect, consulte Como acessar o endpoint de hosts locais para mais detalhes.
Geração de registros, monitoramento e visibilidade
ajuste a geração de registros para casos de uso específicos e públicos-alvo pretendidos.
Aumentar o intervalo de agregação de registros para redes VPC com conexões longas.
Usar a amostragem dos registros de fluxo de VPC para reduzir o volume.
Remover metadados extras quando precisar apenas de dados de porta e IP. Use o Network Intelligence Center para receber insights sobre suas redes
Ajustar a geração de registros para casos de uso específicos e públicos-alvo
Use o VPC Flow Logs no monitoramento de rede, perícia, análise de segurança em tempo real e otimização de despesas. É possível ativar ou desativar os registros de fluxo de VPC no nível da sub-rede. Se os registros de fluxo de VPC estiverem ativados para uma sub-rede, ela coletará dados de todas as instâncias de VM nessa sub-rede.
Esses registros gravam uma amostra de fluxos de rede enviados e recebidos pelas instâncias de VM. Com seus casos de uso de registro, é possível determinar quais sub-redes exigem a geração de registros e por quanto tempo.
Os registros de fluxo são agregados por conexão das VMs do Compute Engine em intervalos de cinco segundos e exportados em tempo real. É possível visualizar os registros de fluxo no Cloud Logging e exportá-los para qualquer destino compatível com a exportação do Cloud Logging.
Na página de ingestão de registros no Logging, você rastreia o volume dos registros no projeto. Além disso, é possível desativar todas as ingestões ou excluir as entradas de registro que não forem mais relevantes. Assim, você diminui as cobranças pelos registros na cota mensal.
Os registros são uma parte essencial do sucesso operacional e da segurança. No entanto, eles são úteis somente quando você os revisa e age de acordo com isso. Ajuste os registros para o público-alvo, o que ajuda a garantir o sucesso operacional e de segurança das suas redes VPC.
Para detalhes, consulte Como usar os registros de fluxo de VPC.
Aumentar o intervalo de agregação de registros para redes VPC com conexões longas
Para redes VPC com conexões de longa duração, defina o intervalo de agregação de registros para 15 minutos para reduzir significativamente o número de registros gerados e permitir uma análise mais rápida e simples.
O monitoramento da rede é um exemplo de fluxo de trabalho em que o aumento no intervalo de agregação de registros é adequado. Ele inclui as tarefas a seguir:
- realizar o diagnóstico de rede;
- filtrar os registros de fluxo por VM e por aplicativo para entender as alterações no tráfego;
- analisar o crescimento do tráfego para prever a capacidade.
Usar a amostragem do registro de fluxo de VPC para reduzir o volume
Use a amostragem do VPC Flow Logs para reduzir o volume de registros de fluxo e conferir amostras de nível inferior e visualizações agregadas.
Entender o uso da rede e otimizar as despesas do tráfego são exemplos de fluxo de trabalho em que utilizar a amostragem para reduzir o volume é adequado. Esse fluxo de trabalho inclui as tarefas a seguir:
- prever o tráfego entre regiões e zonas;
- Prever o tráfego em países específicos na Internet
- Identificar os principais talkers
Remover metadados extras quando precisar apenas de dados de porta e IP
Nos casos de uso de segurança em que você só tem interesse em endereços IP e portas, remova os metadados extras para reduzir o volume de dados consumidos no Cloud Logging.
A perícia de rede é um exemplo de fluxo de trabalho em que a remoção de metadados é adequada. Esse fluxo de trabalho inclui as tarefas a seguir:
- determinar quais IPs conversaram com quem e quando isso aconteceu;
- Identificar endereços IP comprometidos, encontrados ao analisar os fluxos de rede
Use o Network Intelligence Center para receber insights sobre suas redes
O Network Intelligence Center oferece um único console para gerenciar Google Cloud visibilidade, monitoramento e solução de problemas da rede. As seções a seguir fornecem detalhes sobre os componentes do Network Intelligence Center.
Topologia de rede
Use a Topologia de rede para visualizar sua topologia de rede.
Testes de conectividade
Use os testes de conectividade para diagnosticar problemas de conectividade com suas redes VPC.
Painel de desempenho
Use o Painel de desempenho para verificar o desempenho da rede física subjacente às redes virtuais da VPC.
Firewall Insights
Use o Firewall Insights para entender melhor suas regras de firewall e como elas interagem.
Network Analyzer
Use o Network Analyzer para monitorar as configurações de rede VPC e detectar configurações incorretas e abaixo do ideal.
Flow Analyzer
Use o Analisador de fluxo para entender melhor os fluxos de tráfego da VPC.
Arquiteturas de referência
Nesta seção, são destacadas arquiteturas que ilustram algumas das melhores práticas deste documento.
Projeto único, rede VPC única
Nesta referência inicial, são incluídos todos os componentes necessários para implantar arquiteturas altamente disponíveis em várias regiões, com isolamento no nível de sub-rede e um SLA de 99,99% que se conecta aos data centers no local.
Um projeto de host, vários projetos de serviço e uma VPC compartilhada
Com base na arquitetura de referência inicial, os administradores podem usar vários projetos de serviço e os de host da VPC compartilhada para delegar responsabilidades administrativas aos responsáveis pelo projeto de serviço. Por exemplo, a criação e o gerenciamento de instâncias. Além disso, é possível manter o controle centralizado dos recursos da rede, como sub-redes, rotas e firewalls.
Vários projetos de host, vários projetos de serviço e várias VPCs compartilhadas
No diagrama a seguir, você vê uma arquitetura de isolamento da VPC. Ela é baseada no nosso design de alta disponibilidade e separa a produção de outros projetos. Há muitos motivos para considerar o isolamento da VPC, incluindo requisitos de auditoria (como PCI), especificações de cota entre ambientes ou apenas outra camada de isolamento lógico. Você só precisa de duas interconexões (para redundância) por local, mas pode adicionar vários anexos de interconexão a várias redes ou regiões VPC.
Usar o isolamento também gera a necessidade de replicação, conforme você decide onde colocar os serviços principais como proxies, autenticação e serviços de diretório. Usar uma rede VPC de serviços compartilhados pode ajudar a evitar essa replicação e permitir que você compartilhe esses serviços com outras redes VPC pelo Network Connectivity Center, centralizando a administração e a implantação.
Firewall L7 com estado entre redes VPC
Essa arquitetura tem várias redes VPC em ponte por um dispositivo de firewall de última geração (NGFW, na sigla em inglês) L7, que funciona como uma ponte multi-NIC entre redes VPC.
Uma rede VPC externa e não confiável é introduzida para encerrar interconexões híbridas e conexões baseadas na Internet que terminam no trecho externo do L7 NGFW para inspeção. Há muitas variações nesse projeto, mas o princípio fundamental é filtrar o tráfego por meio do firewall antes que ele chegue às redes VPC confiáveis.
Esse projeto exige que cada rede VPC resida no projeto em que você insere o NGFW baseado em VM. Como as cotas são aplicadas no nível do projeto, considere o agregado de todos os recursos da VPC.
Várias redes VPC interconectadas com o Network Connectivity Center
Essa arquitetura tem várias redes VPC que se conectam usando o Network Connectivity Center. Uma rede VPC de trânsito é introduzida para encerrar interconexões híbridas e compartilhar a conectividade híbrida em todas as outras VPCs, o que evita a necessidade de criar anexos de VLAN para cada rede VPC. Essa abordagem consolida a conectividade externa e as considerações de roteamento associadas. Da mesma forma, uma ou mais redes VPC de serviços compartilhados podem ser introduzidas para hospedar serviços comuns, como proxies, autenticação e serviços de diretório. Há muitas variações nesse projeto, mas o princípio fundamental é processar os diferentes serviços e tipos de conexão como spokes de um hub do Network Connectivity Center que fornece conectividade de qualquer tipo entre eles. Essa arquitetura de referência é descrita em detalhes em Conectividade entre VPCs do Cross-Cloud Network usando o Network Connectivity Center.
A seguir
- Rede entre nuvens para aplicativos distribuídos
- Práticas recomendadas e informações detalhadas sobre a VPC (vídeo em inglês do Cloud NEXT '18)
- Topologias de rede híbrida e de várias nuvens
- Escolha uma hierarquia de recursos para sua Google Cloud zona de destino
- Práticas recomendadas para a seleção da região do Compute Engine
- Google Cloud para profissionais de data centers: rede
- Documentação da VPC
- Visão geral da rede do GKE
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.