Este guia apresenta práticas recomendadas e arquiteturas empresariais típicas para a conceção da nuvem virtual privada (VPC) com o Google Cloud. Este guia destina-se a arquitetos de rede na nuvem e arquitetos de sistemas que já estão familiarizados com os conceitos de rede. Google Cloud
Princípios gerais e primeiros passos
Identifique os responsáveis pela tomada de decisões, os prazos e o trabalho prévio.
Planeie antecipadamente o design da rede VPC.
Simplifique.
Use convenções de nomenclatura claras.
Identifique os decisores, os prazos e o trabalho prévio
Como primeiro passo no design da rede VPC, identifique os responsáveis pela tomada de decisões, os prazos e o trabalho prévio necessário para garantir que pode satisfazer os requisitos das partes interessadas.
Os intervenientes podem incluir proprietários de aplicações, arquitetos de segurança, arquitetos de soluções e gestores de operações. As partes interessadas podem mudar, dependendo se está a planear a sua rede VPC para um projeto, uma linha de negócio ou toda a organização.
Parte do trabalho prévio consiste em familiarizar a equipa com os conceitos e a terminologia relacionados com o design da rede VPC. Os documentos úteis incluem o seguinte:
- Documentação do Resource Manager
- Documentação do Identity and Access Management (IAM)
- Documentação da nuvem privada virtual
Planeie antecipadamente o design da rede VPC
Inicie o design da rede VPC na fase inicial do design da configuração organizacional no Google Cloud. Pode ser prejudicial para a sua organização se, mais tarde, precisar de alterar aspetos fundamentais, como a forma como a sua rede está segmentada ou onde as suas cargas de trabalho estão localizadas.
As diferentes configurações da rede VPC podem ter implicações significativas para o encaminhamento, a escala e a segurança. Um planeamento cuidadoso e uma compreensão aprofundada das suas considerações específicas ajudam a criar uma base arquitetónica sólida para cargas de trabalho incrementais.
Simplifique
Manter o design da topologia da rede VPC simples é a melhor forma de garantir uma arquitetura gerível, fiável e bem compreendida.
Use convenções de nomenclatura claras
Torne as suas convenções de nomenclatura simples, intuitivas e consistentes. Isto garante que os administradores e os utilizadores finais compreendem a finalidade de cada recurso, onde está localizado e como se diferencia de outros recursos.
As abreviaturas de palavras longas geralmente aceites ajudam a manter a brevidade. A utilização de terminologia familiar sempre que possível ajuda na legibilidade.
Considere os componentes ilustrados no exemplo seguinte ao estabelecer as suas convenções de nomenclatura:
- Nome da empresa: Acme Company:
acmeco - Unidade empresarial: recursos humanos:
hr - Código da aplicação: 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,stageeprod
Neste exemplo, o ambiente de desenvolvimento do sistema de remuneração do departamento de recursos humanos chama-se acmeco-hr-comp-eu-we1-dev.
Para outros recursos de rede comuns, considere padrões como estes:
Rede da 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
nota: se uma sub-rede contiver recursos apenas numa zona, pode usar "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-ruleIP route
sintaxe:{priority}-{VPC-label}-{tag}-{next hop}
exemplo:1000-acmeco-hr-dev-vpc-1-int-gw
Moradas e sub-redes
Use sub-redes no modo personalizado nas suas redes VPC empresariais.
Agrupe as aplicações em menos sub-redes com intervalos de endereços maiores.
Use redes VPC no modo personalizado
Embora as redes no modo automático possam ser úteis para a exploração inicial, as redes VPC no modo personalizado são mais adequadas para a maioria dos ambientes de produção.
Recomendamos que as empresas usem redes VPC no modo personalizado desde o início pelos seguintes motivos:
- As redes VPC no modo personalizado integram-se melhor nos esquemas de gestão de endereços IP existentes. Uma vez que todas as redes do modo automático usam o mesmo conjunto de intervalos de IP internos, os intervalos de IP do modo automático podem sobrepor-se quando estão ligados às suas redes empresariais no local.
- Não é possível ligar duas redes VPC de modo automático através da interligação de redes VPC porque as respetivas sub-redes usam intervalos de IP primários idênticos.
- Todas as sub-redes do modo automático têm o mesmo nome que a rede. Pode escolher nomes descritivos únicos para as sub-redes do modo personalizado, o que torna as suas redes VPC mais compreensíveis e fáceis de manter.
- Quando é introduzida uma nova Google Cloud região, as redes VPC no modo automático recebem automaticamente uma nova sub-rede nessa região. As redes VPC no modo personalizado só recebem novas sub-redes se as especificar. Isto pode ser importante por motivos de soberania e gestão de endereços IP.
Se não tiver recursos, pode eliminar a defaultrede. Não pode eliminar uma rede VPC até remover todos os recursos, incluindo instâncias de máquinas virtuais (VMs), que dependam da mesma.
Para mais detalhes sobre as diferenças entre as redes VPC no modo automático e no modo personalizado, consulte a vista geral da rede VPC.
Agrupar aplicações em menos sub-redes com intervalos de endereços maiores
Convencionalmente, algumas redes empresariais estão separadas em muitos intervalos de endereços pequenos por vários motivos. Por exemplo, isto pode ter sido feito para identificar ou isolar uma aplicação, ou manter um pequeno domínio de transmissão.
No entanto, recomendamos que agrupe as aplicações do mesmo tipo em menos sub-redes, mas mais fáceis de gerir, com intervalos de endereços maiores nas regiões onde quer operar.
Ao contrário de outros ambientes de rede nos quais é usada uma máscara de sub-rede, o Google Cloud usa uma abordagem de rede definida por software (SDN) para fornecer uma malha completa de acessibilidade entre todas as VMs na rede VPC global.Google Cloud O número de sub-redes não afeta o comportamento de encaminhamento.
Pode usar contas de serviço ou etiquetas de rede para aplicar políticas de encaminhamento específicas ou regras de firewall. A identidade em Google Cloud não se baseia apenas no endereço IP da sub-rede.
Algumas funcionalidades da VPC, incluindo o Cloud NAT, acesso privado à Google, registos de fluxo de VPC> e intervalos de IPs de alias, são configuradas por sub-rede. Se precisar de um controlo mais detalhado destas funcionalidades, use sub-redes adicionais.
Rede da VPC única e VPC partilhada
Comece com uma única rede VPC para recursos que tenham requisitos comuns.
Use a VPC partilhada para a administração de vários grupos de trabalho.
Conceda a função de utilizador da rede ao nível da sub-rede.
Use um único projeto anfitrião se os recursos precisarem de várias interfaces de rede.
Use vários projetos anfitriões se os requisitos de recursos excederem a quota de um único projeto.
Use vários projetos anfitriões se precisar de políticas de administração separadas para cada VPC.
Comece com uma única rede VPC para recursos que tenham requisitos comuns
Em muitos exemplos de utilização simples, uma rede VPC única oferece as funcionalidades de que precisa, ao mesmo tempo que é mais fácil de criar, manter e compreender do que as alternativas mais complexas. Ao agrupar recursos com requisitos e caraterísticas comuns numa única rede VPC, começa a estabelecer o limite da rede VPC como o perímetro para potenciais problemas.
Para ver um exemplo desta configuração, consulte a arquitetura de referência de projeto único e rede VPC única.
Os fatores que podem levar à criação de redes VPC adicionais incluem a escala, a segurança da rede, as considerações financeiras, os requisitos operacionais e a gestão de identidade e acesso (IAM).
Use uma VPC partilhada para a administração de vários grupos de trabalho
Para organizações com várias equipas, a VPC partilhada oferece uma ferramenta eficaz para simplificar a arquitetura de uma rede VPC única em vários grupos de trabalho. A abordagem mais simples é implementar um único projeto anfitrião de VPC partilhada com uma única rede VPC partilhada e, em seguida, anexar projetos de serviço da equipa à rede do projeto anfitrião.
Nesta configuração, a política de rede e o controlo de todos os recursos de rede são centralizados e mais fáceis de gerir. Os departamentos do projeto de serviço podem configurar e gerir recursos que não sejam de rede, o que permite uma separação clara das responsabilidades para diferentes equipas na organização.
Os recursos nesses projetos podem comunicar entre si de forma mais segura e eficiente nos limites do projeto através de endereços IP internos. Pode gerir recursos de rede partilhados, como sub-redes, rotas e firewalls, a partir de um projeto anfitrião central, para poder aplicar políticas de rede consistentes nos projetos.
Para ver um exemplo desta configuração, consulte a arquitetura de referência Projeto anfitrião único, vários projetos de serviço, VPC partilhada única.
Conceda a função de utilizador da rede ao nível da sub-rede
O administrador da VPC partilhada centralizada pode conceder aos membros a função de utilizador da rede (networkUser) ao nível da sub-rede, para uma autorização detalhada do projeto de serviço, ou para todas as sub-redes ao nível do projeto anfitrião.
Seguindo o princípio do menor privilégio, recomendamos que conceda a função de utilizador de rede ao nível da sub-rede ao utilizador, à conta de serviço ou ao grupo associado.
Uma vez que as sub-redes são regionais, este controlo detalhado permite-lhe especificar as regiões que cada projeto de serviço pode usar para implementar recursos.
Com as arquiteturas de VPC partilhada, também tem a flexibilidade de implementar vários projetos anfitriões de VPC partilhada na sua organização. Cada projeto anfitrião da VPC partilhada pode, em seguida, acomodar uma ou várias redes da VPC partilhada. Nesta configuração, diferentes ambientes podem aplicar diferentes preocupações com as políticas.
Para mais informações, consulte o artigo Funções de IAM para redes.
Use um único projeto anfitrião se os recursos precisarem de várias interfaces de rede
Se tiver um projeto de serviço que precise de implementar recursos em várias redes VPC isoladas, por exemplo, instâncias de VM com várias interfaces de rede, o projeto anfitrião tem de conter todas as redes VPC que fornecem os serviços. Isto deve-se ao facto de um projeto de serviço poder ser anexado apenas a um projeto anfitrião.
Use vários projetos anfitriões se os requisitos de recursos excederem a quota de um único projeto
Nos casos em que os requisitos de recursos agregados de todas as redes VPC não podem ser cumpridos dentro da quota de um projeto, use uma arquitetura com vários projetos anfitriões com uma única rede VPC partilhada por projeto anfitrião, em vez de um único projeto anfitrião com várias redes VPC partilhadas. É importante avaliar os requisitos de escala, porque a utilização de um único projeto anfitrião requer várias redes VPC no projeto anfitrião, e as quotas são aplicadas ao nível do projeto.
Para ver um exemplo desta configuração, consulte o artigo Vários projetos anfitriões, vários projetos de serviço e várias arquiteturas de referência de VPC partilhada.
Use vários projetos anfitriões se precisar de políticas de administração separadas para cada rede VPC
Uma vez que cada projeto tem a sua própria quota, use um projeto anfitrião da VPC partilhada separado para cada rede VPC de modo a dimensionar os recursos agregados. Isto permite que cada rede de VPC tenha autorizações do IAM separadas para a gestão de rede e segurança, uma vez que as autorizações do IAM também são implementadas ao nível do projeto. Por exemplo, se implementar duas redes VPC (rede VPC A e rede VPC B) no mesmo projeto anfitrião, a função de
administrador de rede
(networkAdmin)
aplica-se a ambas as redes VPC.
Decidir se deve criar várias redes VPC
Crie uma única rede VPC por projeto para mapear as quotas da rede VPC para projetos.
Crie uma rede VPC para cada equipa autónoma, com serviços partilhados numa rede VPC comum.
Crie redes VPC em projetos diferentes para controlos IAM independentes.
Isolar dados confidenciais na sua própria rede VPC.
Crie uma única rede VPC por projeto para mapear as quotas de recursos da VPC para projetos
As quotas são restrições aplicadas ao nível do projeto ou da rede. Todos os recursos têm uma quota predefinida inicial destinada a proteger contra a utilização inesperada de recursos. No entanto, muitos fatores podem levar a que queira mais quota. Para a maioria dos recursos, pode pedir quota adicional.
Recomendamos que crie uma única rede VPC por projeto se esperar crescer além das quotas de recursos VPC predefinidas. Isto facilita o mapeamento dos aumentos de quota ao nível do projeto para cada rede VPC, em vez de para uma combinação de redes VPC no mesmo projeto.
Os limites são concebidos para proteger os recursos do sistema de forma agregada. Geralmente, não é fácil aumentar os limites, embora Google Cloud as equipas de apoio técnico e vendas possam trabalhar consigo para aumentar alguns limites.
Consulte as quotas e os limites de recursos da VPC para ver os valores atuais.
O apoio técnico da Google pode aumentar alguns limites de escalabilidade, mas pode haver alturas em que tem de criar várias redes VPC para cumprir os seus requisitos de escalabilidade. Se a sua rede da VPC tiver um requisito de escalabilidade para além dos limites, discuta o seu caso com as equipas de vendas e apoio técnico acerca da melhor abordagem para os seus requisitos.Google Cloud
Crie uma rede VPC para cada equipa autónoma, com serviços partilhados numa rede VPC comum
Algumas implementações empresariais de grande escala envolvem equipas autónomas que requerem controlo total sobre as respetivas redes VPC. Pode cumprir este requisito criando uma rede VPC para cada unidade empresarial, com serviços partilhados numa rede VPC comum (por exemplo, ferramentas de análise, pipeline de CI/CD e máquinas de compilação, serviços de DNS/diretório).
Crie redes VPC em projetos diferentes para controlos de IAM independentes
Uma rede VPC é um recurso ao nível do projeto com controlos de gestão de identidade e de acesso (IAM) detalhados ao nível do projeto, incluindo as seguintes funções:
networkAdminsecurityAdminnetworkUsernetworkViewer
Por predefinição, os controlos da IAM são implementados ao nível do projeto e cada função da IAM aplica-se a todas as redes VPC no projeto.
Se precisar de controlos de IAM independentes por rede VPC, crie as redes VPC em projetos diferentes.
Se precisar de funções IAM com âmbito para recursos específicos do Compute Engine, como instâncias de VMs, discos e imagens, use as políticas IAM para recursos do Compute Engine.
Isole dados confidenciais na sua própria rede VPC
Para as empresas que lidam com iniciativas de conformidade, dados confidenciais ou dados altamente regulamentados que estão sujeitos a normas de conformidade, como a HIPAA ou a PCI-DSS, faz frequentemente sentido adotar medidas de segurança adicionais. Um método que pode melhorar a segurança e facilitar a comprovação da conformidade é isolar cada um destes ambientes na sua própria rede VPC.
Ligar várias redes VPC
Escolha o método de ligação à VPC que satisfaça as suas necessidades de custo, desempenho e segurança.
Use raios da VPC do Centro de conetividade de rede.
Use o peering de rede VPC se precisar de inserir NVAs ou se a sua aplicação não suportar o Private Service Connect.
Use o encaminhamento externo se não precisar de comunicação de endereços IP privados.
Use o Cloud VPN para ligar redes VPC que alojam pontos de acesso a serviços que não são transitivamente acessíveis através do Network Connectivity Center.
Use dispositivos virtuais com várias NICs para controlar o tráfego entre redes VPC através de um dispositivo na nuvem.
Escolha o método de ligação à VPC que satisfaz as suas necessidades de custo, desempenho e segurança
O passo seguinte depois de decidir implementar várias redes VPC é ligar essas redes VPC. As redes VPC são espaços de inquilinos isolados na SDN Andromeda da Google, mas existem várias formas de ativar a comunicação entre elas. As secções seguintes fornecem práticas recomendadas para escolher um método de ligação à VPC.
As vantagens e as desvantagens de cada uma são resumidas na tabela seguinte, e as secções subsequentes fornecem práticas recomendadas para escolher um método de ligação de VPC.
| Vantagens | Desvantagens | |
|---|---|---|
| Hubs da VPC do Network Connectivity Center |
|
|
| Intercâmbio da rede da VPC |
|
|
| Encaminhamento externo (IP público ou gateway de NAT) |
|
|
| Cloud VPN |
|
|
| Várias interfaces de rede (Multi-NIC) |
|
|
Use raios da VPC do Network Connectivity Center
Recomendamos que use raios VPC do Network Connectivity Center quando precisar de ligar redes VPC. Os raios da VPC do Network Connectivity Center permitem a reutilização de endereços em várias VPCs no mesmo projeto e organização ou num projeto e organização diferentes.
Os raios da VPC do Centro de conetividade de rede são o método preferencial para ligar redes de VPC pelos seguintes motivos:
- O plano de dados é distribuído, pelo que não existe nenhum gargalo de gateway. O tráfego desloca-se pelas redes VPC como se as VMs estivessem na mesma rede VPC.
- Conetividade entre redes em diferentes organizações. As redes incluem VPCs, bem como redes externas.
- Até 250 redes de VPC por hub.
- Acessibilidade transitiva entre VPCs de pontos de acesso ao serviço.
- NAT da nuvem entre VPCs integrado para permitir a reutilização de endereços IP em várias VPCs.
- Regras de acessibilidade à rede definidas através de topologias predefinidas e filtros de prefixos.
Use o peering de rede VPC se precisar de inserir NVAs ou se a sua aplicação não suportar o Private Service Connect
Recomendamos que use o peering de redes VPC se precisar de inserir dispositivos virtuais de rede (NVAs), como VMs de firewall. Pode ter de inserir NVAs para tráfego que atravessa várias redes VPC ou para conectividade privada a serviços que não são publicados através do Private Service Connect.
Quando usa o peering de redes VPC, certifique-se de que os totais dos recursos necessários para todos os pares ligados diretamente não excedem os limites nas instâncias de VMs, no número de ligações de peering e nas regras de encaminhamento interno.
O intercâmbio das redes da VPC permite que duas redes da VPC se liguem internamente entre si através da SDN da Google, quer pertençam ou não ao mesmo projeto ou à mesma organização. O intercâmbio da rede da VPC une o plano de controlo e a propagação de fluxo entre cada par, permitindo as mesmas características de encaminhamento como se todas as VMs estivessem na mesma rede da VPC. Quando as redes VPC estão interligadas, todas as sub-redes, os intervalos de IP de alias e as regras de encaminhamento interno são acessíveis, e cada rede VPC mantém a sua própria firewall distribuída. O intercâmbio das redes da VPC não é transitivo.
Use o encaminhamento externo se não precisar de comunicação de endereços IP privados
Se não precisar de comunicação de endereços IP privados, pode usar o encaminhamento externo com endereços IP externos ou um gateway NAT.
Quando uma rede VPC é implementada, é fornecido um encaminhamento para o gateway da Internet predefinido da Google com uma prioridade de 1000. Se este caminho existir e for atribuído um endereço IP externo a uma VM, as VMs podem enviar tráfego de saída (egress) através do gateway de Internet da Google. Também pode implementar serviços atrás de uma das muitas ofertas de balanceamento de carga públicas da Google, o que permite que os serviços sejam alcançados externamente.
As VMs com endereços externos comunicam entre si de forma privada através da infraestrutura da Google, independentemente da região e dos níveis de serviço de rede. Use regras de firewall para controlar o tráfego externo de entrada (ingress) para as suas VMs. Google Cloud
O encaminhamento externo é uma boa opção para fins de escalabilidade, mas é importante compreender como o encaminhamento público afeta os custos. Para ver detalhes, consulte a documentação de preços da rede.
Use o Cloud VPN para ligar redes VPC que alojam pontos de acesso a serviços que não são transitivamente acessíveis através do Centro de conectividade de rede
A VPN de alta disponibilidade oferece um serviço gerido para ligar redes da VPC através da criação de túneis IPsec entre conjuntos de pontos finais. Se configurar os Cloud Routers com o modo de anúncio personalizado, pode ativar o encaminhamento transitivo nas redes VPC e nas topologias de hub e raio, conforme descrito mais adiante neste documento. Com o Network Connectivity Center, pode usar túneis de VPN de alta disponibilidade como uma rede de trânsito entre redes no local, conforme explicado na documentação do Cloud VPN.
A VPN na nuvem não suporta MTU grande. Para obter detalhes, consulte as considerações sobre a MTU.
Use dispositivos virtuais para controlar o tráfego entre redes VPC através de um dispositivo na nuvem
As VMs com várias interfaces de rede são comuns para redes VPC que requerem segurança ou serviços adicionais entre elas, porque as VMs com várias interfaces de rede permitem que as instâncias de VM estabeleçam uma ponte de comunicação entre redes VPC.
Uma VM só pode ter uma interface para cada rede VPC à qual se liga. Para implementar uma VM em várias redes VPC, tem de ter a autorização do IAM adequada para cada rede VPC à qual a VM se liga.
Tenha em atenção as seguintes caraterísticas quando implementar uma VM com várias NICs:
- Uma VM com vários NICs pode ter um máximo de 8 interfaces.
- Os intervalos de IP de sub-rede das interfaces não se podem sobrepor.
Conetividade do serviço
O Private Service Connect permite que os consumidores acedam aos serviços de forma privada a partir da respetiva rede VPC sem necessidade de um modelo de implementação orientado para a rede. Da mesma forma, permite que os produtores alojem estes serviços nas suas próprias redes VPC separadas e podem oferecer uma ligação privada aos seus consumidores na mesma organização ou em várias organizações. O Private Service Connect permite a conetividade a serviços geridos originais e de terceiros, o que elimina a necessidade de atribuição de sub-redes para acesso a serviços privados e interligação de redes VPC.
O Private Service Connect oferece um modelo de segurança centrado no serviço com as seguintes vantagens:
- Sem dependências partilhadas
- Autorização explícita
- Desempenho à velocidade da linha
O Private Service Connect está disponível em diferentes tipos que oferecem diferentes capacidades e modos de comunicação:
- Pontos finais do Private Service Connect: os pontos finais são implementados através de 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 implementados através de grupos de pontos finais da rede (NEGs) que permitem aos consumidores direcionar o tráfego para o respetivo balanceador de carga antes de o tráfego chegar a um serviço do Private Service Connect. Se os back-ends forem implementados com um balanceador de carga HTTPS, podem suportar certificados.
- Interfaces do Private Service Connect: as interfaces permitem que o consumidor e o produtor originem tráfego, o que permite a comunicação bidirecional. As interfaces podem ser usadas na mesma rede VPC que os pontos finais e os back-ends.
Uma alternativa ao Private Service Connect é o acesso a serviços privados, que permite aos consumidores ligar os serviços do produtor através do VPC Network Peering. Quando usa o acesso privado aos serviços, recomendamos que considere a atribuição de IP para cada serviço produtor, a sobreposição de IP e a quota partilhada.
Design híbrido: ligar um ambiente nas instalações
Use o encaminhamento dinâmico sempre que possível.
Use uma rede VPC de conetividade para dimensionar uma arquitetura de hub e raios com várias redes VPC.
Depois de identificar a necessidade de conetividade híbrida e escolher uma solução que cumpra os seus requisitos de largura de banda, desempenho e segurança, considere como integrá-la no design da sua VPC.
A utilização da VPC partilhada elimina a necessidade de cada projeto replicar a mesma solução. Por exemplo, quando integra uma solução do Cloud Interconnect numa VPC partilhada, todas as VMs, independentemente da região ou do projeto de serviço, podem aceder à ligação do Cloud Interconnect.
Use o planeamento de trajeto dinâmico quando possível
O encaminhamento dinâmico está disponível em todas as soluções híbridas, incluindo HA VPN, VPN clássica, Dedicated Interconnect e Partner Interconnect. O encaminhamento dinâmico usa o Cloud Router da Google como um orador do Border Gateway Protocol (BGP) para fornecer um encaminhamento dinâmico do BGP externo (eBGP).
O Cloud Router não está no plano de dados; apenas cria rotas na SDN.
O encaminhamento dinâmico não usa etiquetas e o Cloud Router nunca volta a anunciar prefixos aprendidos.
Pode ativar qualquer um dos dois modos do Cloud Router, regional ou global, em cada rede VPC. Se escolher o encaminhamento regional, o Cloud Router anuncia apenas sub-redes que residam na região onde o Cloud Router está implementado. Por outro lado, o encaminhamento global anuncia todas as sub-redes da rede VPC especificada, independentemente da região, mas penaliza as rotas anunciadas e aprendidas fora da região. Isto mantém a simetria na região, preferindo sempre uma interconexão local, e é calculado adicionando uma métrica de penalização (MED) igual a 200 + TTL em milissegundos entre regiões.
Encaminhamento estático
O encaminhamento estático só está disponível na VPN clássica. O encaminhamento estático oferece a capacidade de definir uma rota de próximo salto que aponta para um túnel de Cloud VPN.
Por predefinição, uma rota estática aplica-se a todas as VMs na rede, independentemente da região. A rotagem estática também permite que os administradores de rede definam seletivamente a que VMs a rota se aplica através de etiquetas de instâncias, que podem ser especificadas quando cria uma rota.
Os trajetos estáticos aplicam-se globalmente na rede VPC, com a mesma prioridade de trajeto que os outros. Por conseguinte, se tiver vários túneis em várias regiões para o mesmo prefixo com a mesma prioridade, uma VM usa o ECMP baseado em hash de 5 tuplos em todos os túneis. Para otimizar esta configuração, pode criar uma rota preferencial na região fazendo referência às etiquetas de instâncias de cada região e criando rotas preferenciais em conformidade.
Se não quiser que o tráfego de saída (egresso) passe pelo gateway de Internet predefinido da Google, pode definir uma rota estática predefinida preferencial para enviar todo o tráfego de volta no local através de um túnel.
Use uma rede VPC de conetividade para dimensionar uma arquitetura de hub e raios com várias redes VPC
Se precisar de dimensionar uma arquitetura de hub e raios com várias redes VPC, configure a conetividade híbrida centralizada numa ou mais redes VPC dedicadas, em seguida, adicione as ligações híbridas e todos os raios da VPC a um hub do Network Connectivity Center. Tem de ativar a troca de rotas com raios da VPC. Esta configuração permite que as rotas estáticas ou as rotas aprendidas dinamicamente sejam exportadas para os spokes da VPC, de modo a fornecer uma configuração centralizada e escalabilidade ao design da sua rede da VPC.
O diagrama seguinte ilustra uma arquitetura de conetividade híbrida centralizada com o Network Connectivity Center:
Em alternativa, pode usar o intercâmbio das redes da VPC e rotas anunciadas personalizadas para fornecer acesso a ligações híbridas partilhadas, se não exceder os limites de recursos e precisar de usar NVAs.
O diagrama seguinte ilustra a conetividade híbrida centralizada com rotas personalizadas de intercâmbio de redes VPC:
Este design centralizado contrasta com a implementação de conetividade híbrida convencional, que usa túneis de VPN ou anexos de VLAN em cada rede VPC individual.
Segurança de redes
Identifique objetivos de segurança claros.
Limite o acesso externo.
Defina perímetros de serviço para dados confidenciais.
Faça a gestão do tráfego com Google Cloud regras de firewall sempre que possível.
Use menos conjuntos de regras de firewall mais amplos quando possível.
Isole as VMs através de contas de serviço, quando possível.
Use a automatização para monitorizar as políticas de segurança quando usar etiquetas.
Use ferramentas adicionais para ajudar a proteger as suas apps.
Google Cloud oferece funcionalidades de segurança robustas na respetiva infraestrutura e serviços, desde a segurança física dos centros de dados e hardware de segurança personalizado a equipas dedicadas de investigadores. No entanto, a proteção dos seus Google Cloud recursos é uma responsabilidade partilhada. Tem de tomar medidas adequadas para ajudar a garantir que as suas apps e dados estão protegidos.
Identifique objetivos de segurança claros
Antes de avaliar os controlos de segurança nativos da nuvem ou compatíveis com a nuvem, comece com um conjunto de objetivos de segurança claros que todas as partes interessadas concordam como parte fundamental do produto. Estes objetivos devem enfatizar a realização, a documentação e a iteração, para que possam ser referenciados e melhorados ao longo do desenvolvimento.
Limite o acesso externo
Quando cria um Google Cloud recurso que usa uma rede de VPC, escolhe uma rede e uma sub-rede onde o recurso reside. O recurso é atribuído a um endereço IP interno de um dos intervalos de IP associados à sub-rede. Os recursos numa rede VPC podem comunicar entre si através de endereços IP internos se as regras de firewall o permitirem.
Limite o acesso à Internet apenas aos recursos que precisam dele. Os recursos com apenas um endereço IP interno privado continuam a poder aceder a muitas APIs e serviços Google através do Private Service Connect ou do Private Google Access. O acesso privado permite que os recursos interajam com os principais serviços e produtos Google enquanto permanecem isolados da Internet pública. Google Cloud
Além disso, use políticas organizacionais para restringir ainda mais os recursos que podem usar endereços IP externos.
Para permitir que as VMs acedam à Internet, use o proxy Web seguro se o tráfego puder ser transferido através de HTTP(S) e quiser implementar controlos de identidade. Caso contrário, use o Cloud NAT.
Defina perímetros de serviço para dados confidenciais
Para cargas de trabalho que envolvam dados sensíveis, use os VPC Service Controls para configurar perímetros de serviço em torno dos seus recursos de VPC e serviços geridos pela Google, e controlar a movimentação de dados no limite do perímetro. Com os VPC Service Controls, pode agrupar projetos e a sua rede no local num único perímetro que impede o acesso aos dados através de serviços geridos pela Google. Os perímetros de serviço não podem conter projetos de diferentes organizações, mas pode usar pontes de perímetro para permitir que projetos e serviços em diferentes perímetros de serviço comuniquem.
Faça a gestão do tráfego com Google Cloud regras de firewall sempre que possível
Google Cloud A VPC inclui uma firewall com estado que é escalável horizontalmente e aplicada a cada VM de forma distribuída. Consulte a vista geral da NGFW na nuvem para ver detalhes.
O Google Cloud Marketplace apresenta um grande ecossistema de soluções de terceiros, incluindo VMs que fazem o seguinte: oferecem segurança avançada, como proteção contra fugas de informações, explorações de aplicações e escalada de privilégios; detetam ameaças conhecidas e desconhecidas; e aplicam filtragem de URLs. Também existem vantagens operacionais em ter um único fornecedor a implementar políticas em fornecedores de serviços na nuvem e ambientes nas instalações.
Normalmente, o tráfego é encaminhado para estas VMs especificando rotas, quer com a mesma prioridade (para distribuir o tráfego através de um hash de 5 tuplos) ou com prioridades diferentes (para criar um caminho redundante), conforme mostrado nos vários caminhos para a sub-rede de desenvolvimento no diagrama seguinte.
A maioria das soluções requer várias VMs de interface de rede. Uma vez que uma VM não pode ter mais do que uma interface por rede VPC, quando cria uma VM com várias interfaces de rede, cada interface tem de ser anexada a uma rede VPC separada.
A escala também é uma consideração importante quando implementa soluções de terceiros na sua rede de VPC pelos seguintes motivos:
- Limites: a maioria dos dispositivos baseados em VMs tem de ser inserida no caminho de dados. Isto requer uma VM com várias interfaces de rede que faça a ponte entre várias redes VPC que residam no mesmo projeto. Uma vez que as quotas de recursos da VPC são definidas ao nível do projeto, os recursos agregados necessários em todas as redes VPC podem tornar-se limitativos.
- Desempenho: a introdução de um ponto de estrangulamento baseado numa única VM nos atributos de escalabilidade totalmente horizontal de uma rede VPC vai contra as metodologias de design da nuvem. Para mitigar esta situação, pode colocar vários dispositivos virtuais de rede (NVAs) num grupo de instâncias gerido atrás de um balanceador de carga de rede de encaminhamento interno.
Para ter em conta estes fatores em arquiteturas de requisitos de grande escala, envie controlos de segurança para os seus pontos finais. Comece por proteger as suas VMs e usar Google Cloud regras de firewall. Esta estratégia também pode envolver a introdução de agentes de inspeção de pontos finais baseados no anfitrião que não alteram a arquitetura de encaminhamento da sua rede VPC através de várias VMs de interface de rede.
Para ver um exemplo adicional desta configuração, consulte a arquitetura de referência de firewall L7 com estado entre redes da VPC.
Use menos conjuntos de regras de firewall mais amplos quando possível
Só é possível programar um determinado número de regras em qualquer VM. No entanto, pode combinar muitas regras numa definição de regra complexa. Por exemplo, se todas as VMs na rede VPC precisarem de permitir explicitamente 10 portas TCP de entrada, tem duas opções: escrever 10 regras separadas, cada uma a definir uma única porta, ou definir uma única regra que inclua todas as 10 portas. Definir uma única regra que inclua todas as 10 portas é a opção mais eficiente.
Crie um conjunto de regras genérico que se aplique a toda a rede VPC e, em seguida, use conjuntos de regras mais específicos para agrupamentos mais pequenos de VMs através de alvos. Por outras palavras, comece por definir regras gerais e, progressivamente, defina regras mais específicas conforme necessário:
- Aplicar regras de firewall comuns a todas as VMs na rede VPC.
- Aplicar regras de firewall que podem ser agrupadas em várias VMs, como um grupo de instâncias de serviço ou uma sub-rede.
- Aplicar regras de firewall a VMs individuais, como um gateway NAT ou um anfitrião bastion.
Isole as VMs através de contas de serviço, quando possível
Muitas organizações têm ambientes que requerem regras específicas para um subconjunto das VMs numa rede VPC. Existem duas abordagens comuns que pode adotar nestes casos: isolamento de sub-redes e filtragem de alvos.
Isolamento de sub-rede
Com o isolamento de sub-rede, a sub-rede forma o limite de segurança no qual as regras de firewall são aplicadas. Google Cloud Esta abordagem é comum em construções de rede no local e em casos em que os endereços IP e o posicionamento na rede fazem parte da identidade da VM.
Pode identificar as VMs numa sub-rede específica aplicando uma etiqueta, uma etiqueta de rede ou uma conta de serviço únicas a essas instâncias. Isto permite-lhe criar regras de firewall que se aplicam apenas às VMs numa sub-rede, ou seja, às VMs com a etiqueta, a etiqueta de rede ou a 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, pode usar a seguinte configuração de regra na página Regras de firewall:
- Objetivos: etiquetas de destino especificadas
- Etiquetas de destino: subnet-1
- Filtro de origem: sub-redes
- Sub-redes: selecione a sub-rede por nome (exemplo: subnet-1).
Filtragem de destinos
Com a filtragem de destinos, todas as VMs residem na mesma sub-rede ou fazem parte de um conjunto arbitrário de sub-redes. Com esta abordagem, a associação à sub-rede não é considerada parte da identidade da instância para regras de firewall. Em alternativa, pode usar etiquetas, etiquetas de rede ou contas de serviço para restringir o acesso entre VMs na mesma sub-rede. Cada grupo de VMs que usa as mesmas regras de firewall tem a mesma etiqueta de rede aplicada.
Para ilustrar isto, considere uma aplicação de três camadas (Web, app, base de dados) para a qual todas as instâncias são implementadas na mesma sub-rede. A camada Web pode comunicar com os utilizadores finais e a camada de apps, e a camada de apps pode comunicar com a camada de base de dados, mas não é permitida nenhuma outra comunicação entre camadas. As instâncias que executam a camada Web têm uma etiqueta de rede de web, as instâncias que executam a camada de app têm uma etiqueta de rede de app e as instâncias que executam a camada de base de dados têm uma etiqueta de rede de db.
As seguintes regras de firewall implementam esta abordagem:
| Regra 1: permitir utilizadores finais → camada Web | Alvos: etiquetas de destino especificadas Etiquetas de destino: web Filtro de origem: intervalos de IP Intervalos de IP de origem: 0.0.0.0/0 |
| Regra 2: permitir camada Web → camada de app | Segmentações: etiquetas de segmentação especificadas Etiquetas de segmentação: app Filtro de origem: etiquetas de origem Etiquetas de origem: web |
| Regra 3: permitir camada de app → camada de base de dados | Alvos: etiquetas de destino especificadas Etiquetas de destino: db Filtro de origem: etiquetas de origem Etiquetas de origem: app |
No entanto, apesar de ser possível usar etiquetas de rede para a filtragem de alvos desta forma, recomendamos que use etiquetas ou contas de serviço sempre que possível. As etiquetas de destino não têm controlo de acesso e podem ser alteradas por alguém com a função instanceAdmin enquanto as VMs estão em serviço. As etiquetas e as contas de serviço têm controlo de acesso, o que significa que um utilizador específico tem de ser explicitamente autorizado a usar uma conta de serviço.
Só pode haver uma conta de serviço por instância, enquanto pode haver várias etiquetas. Além disso, as contas de serviço atribuídas a uma VM só podem ser alteradas quando
a VM está parada.
Use a automatização para monitorizar as políticas de segurança quando usar etiquetas
Se usar etiquetas de rede, lembre-se de que um administrador da instância pode alterar essas etiquetas. Isto pode contornar a política de segurança. Por isso, se usar etiquetas da rede num ambiente de produção, use uma framework de automatização para ajudar a superar a falta de gestão de IAM nas etiquetas da rede.
Use ferramentas adicionais para ajudar a proteger as suas apps
Além das regras de firewall, use estas ferramentas adicionais para ajudar a proteger as suas apps:
- Use um Google Cloud balanceador de carga HTTP(S) global para suportar a elevada disponibilidade e a normalização de protocolos.
- Integre o Google Cloud Armor com o balanceador de carga de HTTP(S) para oferecer proteção contra DDoS e a capacidade de bloquear ou permitir endereços IP no limite da rede.
- Controle o acesso às apps através do IAP (IAP) para validar a identidade do utilizador e o contexto do pedido para determinar se deve ser concedido acesso a um utilizador.
- Ofereça uma única interface para estatísticas de segurança, deteção de anomalias e deteção de vulnerabilidades com o Security Command Center.
Serviços de rede: NAT e DNS
Use endereços IP externos fixos com o Cloud NAT.
Reutilize endereços IP em várias VPCs com o Cloud NAT.
Use zonas DNS privadas para a resolução de nomes.
Use endereços IP externos fixos com o Cloud NAT
Se precisar de endereços IP externos fixos de um intervalo de VMs, use o Cloud NAT. Um exemplo do motivo pelo qual pode precisar de endereços IP externos fixos é o caso em que um terceiro permite pedidos de endereços IP externos específicos. A utilização do Cloud NAT permite-lhe ter um pequeno número de endereços IP NAT para cada região que são usados para comunicações de saída.
O Cloud NAT também permite que as suas instâncias de VM comuniquem através da Internet sem terem os seus próprios endereços IP externos.As regras de firewall são com estado. Google Cloud Isto significa que, se for permitida uma ligação entre uma origem e um destino ou um destino e um destino, todo o tráfego subsequente em qualquer direção é permitido, desde que a ligação esteja ativa. Por outras palavras, as regras de firewall permitem a comunicação bidirecional após o estabelecimento de uma sessão.
Reutilize 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 estão ligadas através de raios 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. Apenas as ligações iniciadas a partir de cargas de trabalho em Google Cloud em direção a redes externas são traduzidas.
Use zonas DNS privadas para a resolução de nomes
Use zonas privadas no Cloud DNS para permitir que os seus serviços sejam resolvidos com DNS na sua rede VPC através dos respetivos endereços IP internos sem expor este mapeamento ao exterior.
Use o DNS de horizonte dividido para mapear serviços para diferentes endereços IP a partir da rede VPC do que a partir do exterior. Por exemplo, pode ter um serviço exposto através do balanceamento de carga de rede a partir da Internet pública, mas ter o balanceamento de carga interno a fornecer o mesmo serviço com o mesmo nome DNS a partir da rede VPC.
Acesso à API para serviços geridos pela Google
Use o gateway da Internet predefinido sempre que possível.
Adicione rotas explícitas para as APIs Google se precisar de modificar a rota predefinida.
Implemente instâncias que usam APIs Google na mesma sub-rede.
Use o gateway da Internet predefinido sempre que possível
O acesso de recursos na rede VPC às APIs Google segue o próximo salto do gateway de Internet predefinido. Apesar do nome do gateway de salto seguinte, o caminho do tráfego das instâncias para as APIs Google permanece na rede da Google.
Por predefinição, apenas as instâncias de VM com um endereço IP externo podem comunicar com as APIs e os serviços Google. Se precisar de acesso a partir de instâncias sem um endereço IP externo, configure pontos finais do Private Service Connect ou use a funcionalidade de acesso privado à Google para cada sub-rede. Isto não abranda as comunicações para as APIs Google.
O Google Kubernetes Engine (GKE) ativa automaticamente o acesso privado à Google em sub-redes onde os nós estão implementados. Todos os nós nestas sub-redes sem um endereço IP externo podem aceder aos serviços geridos pela Google.
Adicione rotas explícitas para as APIs Google se precisar de modificar a rota predefinida
Se precisar de modificar a rota predefinida, adicione rotas explícitas para os intervalos de IP de destino da Google API.
Em ambientes onde a rota predefinida (0.0.0.0/0) não usa o próximo salto do gateway de Internet predefinido, configure rotas explícitas para os intervalos de endereços IP de destino usados pelas APIs Google. Defina o próximo salto das rotas explícitas para o gateway de Internet predefinido. Um exemplo de tal cenário é quando precisa de inspecionar todo o tráfego através de um dispositivo no local.
Implemente instâncias que usam APIs Google na mesma sub-rede
Implemente instâncias que requerem acesso a APIs e serviços Google na mesma sub-rede e ative o acesso privado à Google para instâncias sem endereços IP externos. Em alternativa, configure pontos finais do Private Service Connect.
Se estiver a aceder às APIs Google a partir do seu ambiente no local através do acesso privado à Google, use o acesso privado à Google para configurar anfitriões no local para aceder a alguns serviços Google através de intervalos de endereços IP privados. Verifique que serviços são suportados antes de ativar esta funcionalidade, porque o acesso a outras APIs Google através dos endereços IP fornecidos por este serviço vai ficar inacessível. A ativação desta funcionalidade pode exigir uma configuração de DNS adicional, como a configuração de visualizações de DNS.
Se estiver a aceder às APIs Google a partir do seu ambiente no local através de pontos finais do Private Service Connect, consulte o artigo Aceda ao ponto final a partir de anfitriões no local para ver detalhes.
Registo, monitorização e visibilidade
Personalize o registo para exemplos de utilização específicos e públicos-alvo pretendidos.
Aumente o intervalo de agregação de registos para redes da VPC com ligações longas.
Use a amostragem de registos de fluxo de VPC para reduzir o volume.
Remova metadados adicionais quando apenas precisar de dados de IP e de porta. Use o Network Intelligence Center para aceder a estatísticas sobre as suas redes
Personalize o registo para casos de utilização específicos e públicos-alvo pretendidos
Use os registos de fluxo de VPC para monitorização de rede, análise forense, análise de segurança em tempo real e otimização de despesas. Pode ativar ou desativar os registos de fluxo de VPC ao nível da sub-rede. Se os registos de fluxo de VPC estiverem ativados para uma sub-rede, recolhem dados de todas as instâncias de VM nessa sub-rede.
Estes registos registam uma amostra dos fluxos de rede que as instâncias de VM enviam e recebem. Os seus exemplos de utilização de registos ajudam a determinar que sub-redes decide que precisam de registos e durante quanto tempo.
Os registos de fluxo são agregados por ligação em intervalos de 5 segundos a partir das VMs do Compute Engine e, em seguida, exportados em tempo real. Pode ver os registos de fluxo no Cloud Logging e exportá-los para qualquer destino suportado pela exportação do Cloud Logging.
A página de carregamento de registos no Logging monitoriza o volume de registos no seu projeto e permite-lhe desativar todo o carregamento de registos ou excluir (rejeitar) entradas de registos nas quais não tem interesse, para que possa minimizar os encargos com registos que excedam a sua atribuição mensal.
Os registos são uma parte fundamental do sucesso operacional e de segurança, mas não são úteis a menos que os reveja e tome medidas. Personalizar os registos para o público-alvo pretendido, o que ajuda a garantir o sucesso operacional e de segurança das suas redes VPC.
Para ver detalhes, consulte o artigo Usar registos de fluxo de VPC.
Aumente o intervalo de agregação de registos para redes da VPC com ligações longas
Para redes VPC com ligações maioritariamente de longa duração, defina o intervalo de agregação de registos como 15 minutos para reduzir significativamente o número de registos gerados e permitir uma análise mais rápida e simples.
Um exemplo de fluxo de trabalho para o qual o aumento do intervalo de agregação de registos é adequado é a monitorização da rede, que envolve as seguintes tarefas:
- A realizar o diagnóstico de rede
- Filtrar os registos de fluxo por VMs e por aplicações para compreender as alterações de tráfego
- Analisar o crescimento do tráfego para prever a capacidade
Use a amostragem de registos de fluxo de VPC para reduzir o volume
Use a amostragem de registos de fluxo de VPC para reduzir o volume de registos de fluxo de VPC, mas ainda poder ver amostras de baixo nível e vistas agregadas.
Um exemplo de fluxo de trabalho para o qual a utilização da amostragem para reduzir o volume é adequada é compreender a utilização da rede e otimizar as despesas com o tráfego de rede. Este fluxo de trabalho envolve as seguintes tarefas:
- Estimativa do tráfego entre regiões e zonas
- Estimativa do tráfego para países específicos na Internet
- Identificar os principais oradores
Remova metadados adicionais quando só precisar de dados de IP e porta
Nos exemplos de utilização de segurança em que só tem interesse nos endereços IP e nas portas, remova os metadados adicionais para reduzir o volume de dados consumidos no Cloud Logging.
Um exemplo de fluxo de trabalho para o qual a remoção de metadados é adequada é a análise forense de rede, que envolve as seguintes tarefas:
- Determinar que IPs comunicaram com quem e quando
- Identificar endereços IP comprometidos, encontrados através da análise dos fluxos de rede
Use o Network Intelligence Center para aceder a estatísticas sobre as suas redes
O Network Intelligence Center oferece uma única consola para gerir a visibilidade, a monitorização e a resolução de problemas da rede. Google Cloud As secções seguintes fornecem detalhes sobre os componentes do Network Intelligence Center.
Network Topology
Use a topologia de rede para visualizar a topologia da sua rede.
Connectivity Tests
Use os testes de conetividade para ajudar a diagnosticar problemas de conetividade com as suas redes VPC.
Performance Dashboard
Use o Painel de controlo de desempenho para verificar o desempenho da rede física subjacente às suas redes virtuais da VPC.
Firewall Insights
Use as Estatísticas de firewall para compreender as suas regras de firewall e como interagem.
Analisador de rede
Use o analisador de rede para monitorizar as configurações da sua rede VPC e detetar configurações incorretas e configurações abaixo do ideal.
Analisador de fluxo
Use o analisador de fluxo para compreender melhor os fluxos de tráfego da VPC.
Arquiteturas de referência
Esta secção realça algumas arquiteturas que ilustram algumas das práticas recomendadas neste documento.
Projeto único, rede VPC única
Esta arquitetura de referência inicial inclui todos os componentes necessários para implementar arquiteturas de elevada disponibilidade em várias regiões, com isolamento ao nível da sub-rede e um SLA de 99,99% que se liga aos seus centros de dados no local.
Um projeto anfitrião, vários projetos de serviço e uma VPC partilhada
Com base na arquitetura de referência inicial, os projetos anfitriões da VPC partilhada e os vários projetos de serviço permitem que os administradores deleguem responsabilidades administrativas, como a criação e a gestão de instâncias, nos administradores de projetos de serviço, ao mesmo tempo que mantêm o controlo centralizado sobre os recursos de rede, como sub-redes, rotas e firewalls.
Vários projetos anfitriões, vários projetos de serviço e várias VPCs partilhadas
O diagrama seguinte ilustra uma arquitetura para isolamento de VPC, que se baseia no nosso design de alta disponibilidade, ao mesmo tempo que separa a produção de outros projetos. Existem muitos motivos para considerar o isolamento da VPC, incluindo requisitos de auditoria (como a PCI), considerações de quotas entre ambientes ou apenas outra camada de isolamento lógico. Só precisa de duas interligações (para redundância) por localização, mas pode adicionar várias associações de interligação a várias redes VPC ou regiões a partir destas.
A utilização do isolamento também pode introduzir a necessidade de replicação, à medida que decide onde colocar os serviços principais, como proxies, autenticação e serviços de diretório. A utilização de uma rede VPC de serviços partilhados pode ajudar a evitar esta replicação e permitir-lhe partilhar estes serviços com outras redes VPC através do Network Connectivity Center, ao mesmo tempo que centraliza a administração e a implementação.
Firewall L7 com estado entre redes VPC
Esta arquitetura tem várias redes VPC que são interligadas por um dispositivo de firewall de nova geração (NGFW) de nível 7, que funciona como uma ponte com vários NICs entre redes VPC.
É introduzida uma rede VPC externa não fidedigna para terminar as interligações híbridas e as ligações baseadas na Internet que terminam no segmento externo da NGFW de camada 7 para inspeção. Existem muitas variações deste design, mas o princípio fundamental é filtrar o tráfego através da firewall antes de o tráfego chegar às redes VPC fidedignas.
Este design requer que cada rede VPC resida no projeto onde insere a NGFW baseada em VMs. Uma vez que as quotas são aplicadas ao nível do projeto, tem de ter em conta o agregado de todos os recursos da VPC.
Várias redes VPC interligadas com o Centro de conetividade de rede
Esta arquitetura tem várias redes VPC que se ligam entre si através do Network Connectivity Center. É introduzida uma rede VPC de trânsito para terminar as interligações híbridas e partilhar a conetividade híbrida em todas as outras VPCs, o que evita a necessidade de criar anexos de VLAN para cada rede VPC. Esta abordagem consolida a conetividade externa e as respetivas considerações de encaminhamento associadas. Da mesma forma, podem ser introduzidas uma ou mais redes VPC de serviços partilhados para alojar serviços comuns, como proxies, autenticação e serviços de diretório. Existem muitas variações deste design, mas o princípio fundamental é processar os diferentes serviços e tipos de ligação como raios de um hub do Network Connectivity Center que fornece conetividade de qualquer para qualquer entre estes. Esta arquitetura de referência é descrita detalhadamente no artigo Conetividade entre VPCs da rede entre nuvens através do Network Connectivity Center.
O que se segue?
- Rede entre nuvens para aplicações distribuídas
- Análise detalhada e práticas recomendadas da VPC (vídeo do Cloud NEXT'18)
- Topologias de rede híbridas e de várias nuvens
- Decida uma hierarquia de recursos para a sua Google Cloud zona de destino
- Práticas recomendadas para a seleção da região do Compute Engine
- Google Cloud para profissionais de centros de dados: redes
- Documentação da VPC
- Vista geral da rede do GKE
- Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.