Neste guia, apresentamos as práticas recomendadas e as arquiteturas empresariais comuns para o projeto de nuvens privadas virtuais (VPCs) 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 do 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 Cloud Identity and Access Management
- 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/zone-label}
exemplo:acmeco-hr-na-ne1-dev-subnetRegra 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.
Use redes VPC de modo personalizado
Ao iniciar seu primeiro projeto, você começa com a rede padrão, que é uma rede VPC de modo automático chamada default. As redes do modo automático criam automaticamente sub-redes e rotas de sub-redes em que os intervalos de IP principais são /20 CIDRs em cada região do Google Cloud usando um conjunto previsível de intervalos de endereços RFC 1918. A rede default também inclui automaticamente algumas regras de firewall preenchidas previamente.
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 região do Google Cloud é 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.
Diferentemente de outros ambientes de rede em que uma máscara de sub-rede é usada, o Google 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 do IAM 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. De maneira geral, os limites não podem ser gerados facilmente, ainda que as equipes de suporte e vendas do Google Cloud possam 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 do Google 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. Para mais informações sobre como criar uma rede VPC comum para serviços compartilhados, consulte a seção Serviços compartilhados.
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 o peering de rede VPC se você não for exceder os limites de recursos.
Usar o roteamento externo se você não precisa da comunicação de endereço IP particular.
Usar o Cloud VPN para conectar redes VPC que excederiam os limites do grupo de peering agregado.
Usar o Cloud Interconnect para controlar o tráfego entre redes VPC por meio de um dispositivo local.
Usar dispositivos virtuais multi-NIC para controlar o tráfego entre redes VPC por meio de um dispositivo na nuvem.
Criar uma VPC de serviços compartilhados se várias redes VPC precisarem acessar recursos comuns, mas não entre si.
Escolha 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 | |
|---|---|---|
| Peering de rede VPC |
|
|
| Roteamento externo (IP público ou gateway NAT) |
|
|
| Cloud VPN |
|
|
| Cloud Interconnect: dedicada ou por parceiro |
|
|
| Várias interfaces de rede (multi-NIC, na sigla em inglês) |
|
|
Usar o peering de rede VPC se você não for exceder os limites de recursos
Recomendamos que use o Peering de rede VPC quando precisar conectar redes VPC e não puder utilizar uma única VPC compartilhada. Para isso, as quantidades totais dos recursos necessários para todos os pares de conexão direta não podem exceder 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 se tornam acessíveis. Além disso, cada VPC mantém o próprio firewall distribuído. O peering de rede VPC não é transitivo.
O peering de rede VPC é o melhor método para conectar redes VPC pelos seguintes motivos:
- Nenhum gargalo de gateway: o tráfego é encaminhado entre os peerings como se as VMs estivessem na mesma rede VPC.
- Faturamento: não há custos extras. Você receberá cobranças como se as VMs estivessem na mesma rede VPC.
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 as regras de firewall do 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.
Usar o Cloud VPN para conectar redes VPC que excederiam os limites do grupo de peering agregado
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 o Cloud Interconnect para controlar o tráfego entre redes VPC por meio de um dispositivo local
O Cloud Interconnect estende a rede local para a rede do Google por meio de uma conexão altamente disponível e de baixa latência. Para se conectar ao Google, é possível fazer isso diretamente com a Interconexão dedicada ou por meio de um provedor de serviços autorizado com o Partner Interconnect.
A Interconexão dedicada fornece serviço L2 de alta velocidade entre o Google e um provedor de colocalização ou com instalações no local. Isso permite usar equipamentos de roteamento no local para rotear entre redes VPC e usar serviços de inspeção e segurança locais atuais para filtrar todo o tráfego entre redes VPC. Todo o tráfego entre as duas redes VPC tem latência extra devido a uma ida e volta adicional pelo sistema local.
A Interconexão por parceiro fornece recursos semelhantes, bem como a capacidade de fazer o peering diretamente com um provedor no L3 e ter o provedor de rota entre redes VPC. Isso permite o acesso a endereço IP internos na sua rede local e nas redes do Google Cloud VPC sem um dispositivo NAT ou túnel VPN.
Como muitos dispositivos de segurança empresariais podem ser usados no Google Cloud usando VMs com várias interfaces de rede, o uso do Cloud Interconnect para rotear o tráfego entre redes VPC não é necessário, exceto em poucos casos em que todo o tráfego precisa fluir por um dispositivo local devido a políticas corporativas.
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.
Criar uma VPC de serviços compartilhados se várias redes VPC precisarem acessar recursos comuns, e não entre si.
Uma rede VPC fornece uma malha completa de acessibilidade global. Por esse motivo, os serviços compartilhados e os pipelines de integração contínua que residem na mesma rede VPC não precisam de consideração especial quando se trata de conectividade. Eles são intrinsecamente acessíveis. A VPC compartilhada amplia esse conceito, permitindo que serviços compartilhados fiquem em um projeto isolado e forneçam conectividade a outros serviços ou consumidores.
As abordagens dos serviços compartilhados incluem o Private Service Connect, o peering de rede VPC e o Cloud VPN. Use o Private Service Connect, a menos que por algum motivo. É possível usar o peering de rede VPC para se conectar a uma rede VPC de serviços compartilhados se você não for exceder os limites de recursos agregados e não quiser configurar endpoints para cada serviço. Também é possível usar o Cloud VPN para conectar redes VPC de serviço compartilhado que excederiam os limites do grupo de peering agregado.
O Private Service Connect permite que você disponibilize um serviço hospedado em uma rede para VMs em outra rede criando um endpoint especial na rede do consumidor. A configuração do Private Service Connect, em seguida, canaliza o tráfego para esse serviço entre as duas redes.
Os consumidores podem usar os próprios endereços IP internos para acessar serviços sem sair das redes VPC ou usar endereços IP externos. O tráfego permanece inteiramente dentro do Google Cloud. O Private Service Connect fornece acesso orientado ao serviço entre consumidores e produtores com controle granular sobre como os serviços são acessados.
No modelo de peering de rede VPC, cada rede VPC cria uma relação de peering com uma rede VPC de serviços compartilhados comuns para fornecer acessibilidade. Com o peering de rede VPC, você precisa considerar o dimensionamento, porque os limites dele se aplicam ao uso de recursos agregados de todos os pares.
Também é possível usar o peering de rede VPC com o acesso de serviço privado e a API Service Networking. Com essa API, clientes em organizações iguais ou diferentes usam um serviço fornecido por você. No entanto, eles escolhem o intervalo de endereços IP que é conectado por meio do peering de rede VPC.
O Cloud VPN é outra alternativa. Como o Cloud VPN estabelece acessibilidade por meio de túneis IPSec gerenciados, ele não tem os limites agregados do peering de rede VPC. O Cloud VPN usa um gateway VPN para gerar a conectividade e não leva em consideração o uso de recursos agregados do par IPSec. As desvantagens do Cloud VPN são os custos maiores (túneis VPN e saída de tráfego), além da sobrecarga no desempenho do IPSec e no gerenciamento, necessária para manter os túneis.
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.
Roteamento dinâmico
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 uma conectividade híbrida centralizada em uma rede VPC dedicada e faça o peering para outros projetos usando rotas anunciadas personalizadas. Isso permite que rotas aprendidas de maneira estática ou dinâmica sejam exportadas para redes VPC de mesmo nível, para fornecer configuração centralizada e escalonabilidade ao design da rede VPC.
Isso está em contraste com a implantação de conectividade híbrida convencional, que usa anexos de VLAN ou túnel VPN em cada rede VPC individual.
O diagrama a seguir ilustra a conectividade híbrida centralizada com rotas personalizadas de peering de rede VPC:
Segurança de rede
identifique objetivos claros de segurança.
Limitar o acesso externo
Definir perímetros de serviço para dados confidenciais.
Gerenciar o tráfego com regras de firewall nativas do Google Cloud quando possível.
Usar conjuntos de regras de firewall mais amplos e em menos quantidade quando possível.
Isolar as VMs usando contas de serviço quando possível.
Usar a automação para monitorar as políticas de segurança ao utilizar tags.
Usar ferramentas extras para proteger os aplicativos.
O Google 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 do Google 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.
Limitar o acesso externo
Ao criar um recurso do Google Cloud que usa uma rede VPC, você escolhe uma rede e uma sub-rede em que 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.
Antes de bloquear o acesso à Internet, pense no impacto que isso terá nas instâncias da VM. Bloquear o acesso à Internet reduz o risco de exportação de dados, mas também pode bloquear as visitas legítimas, incluindo o tráfego essencial para atualizações de software e serviços ou APIs de terceiros. Sem acesso à Internet, você só conseguirá acessar as instâncias de VM por meio de uma rede no local, conectada pelo Cloud Interconnect, por um túnel do Cloud VPN ou pelo Identity-Aware Proxy. Ao usar o Cloud NAT, as máquinas virtuais podem iniciar conexões de saída com a Internet para receber o tráfego essencial específico, sem expor as conexões públicas de entrada.
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 nativas do Google Cloud quando possível
O Google Cloud VPC inclui um firewall com estado L3/L4 que é escalonável horizontalmente e aplicado a cada VM de maneira distribuída. Esse firewall é configurado usando políticas hierárquicas de firewall, políticas de firewall de rede globais e regionais e regras de firewall da VPC. Consulte a visão geral do Cloud Firewall para 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 alteram a arquitetura de encaminhamento de 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 do 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 balanceador de carga HTTP(S) global do Google Cloud 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 externos fixos com o Cloud NAT.
Use zonas de DNS particular para resolução de nomes.
Use 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 externos. As regras de firewall do Google Cloud funcionam 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.
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.
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 o VPC Flow Logs.
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
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 por meio do peering de rede VPC e, ao mesmo tempo, centralize 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.
A seguir
- 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
- Práticas recomendadas para o design de redes no framework de arquitetura do Google Cloud
- Práticas recomendadas para a seleção da região do Compute Engine
- Google Cloud Platform 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.