Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Last reviewed 2024-07-29 UTC
Neste documento, apresentamos duas opções de arquitetura para configurar uma topologia de rede "hub and spoke"
no Google Cloud. Uma opção usa o recurso de peering de
rede da nuvem privada virtual (VPC) e a outra usa o Cloud VPN.
As empresas podem separar cargas de trabalho em redes VPC individuais
para fins de faturamento, isolamento de ambientes e outras considerações.
No entanto, elas também precisam compartilhar recursos específicos entre essas
redes, como um serviço compartilhado ou uma conexão com o local. Nesses
casos, pode ser útil colocar o recurso compartilhado em uma rede do tipo hub e
anexar as outras redes VPC como spokes. O diagrama a seguir
mostra um exemplo da rede hub-and-spoke resultante, chamada frequentemente de
topologia star.
Neste exemplo, as redes VPC spoke separadas são usadas para as
cargas de trabalho de unidades de negócios individuais dentro de uma grande empresa. Cada rede
VPC spoke está conectada a uma rede VPC do tipo hub central
que contém serviços compartilhados e pode atuar como o único ponto de entrada para
a nuvem por meio da rede local da empresa.
Arquitetura usando peering de rede VPC
O diagrama a seguir mostra uma rede hub-and-spoke usando o
peering de rede VPC.
O peering de rede VPC permite a comunicação por endereços IP internos
entre recursos em redes VPC separadas. O tráfego permanece
na rede interna do Google e não passa pela Internet pública.
Nesta arquitetura, os recursos que precisam do isolamento no nível da rede
usam redes VPC spoke separadas. Por exemplo, a
arquitetura mostra uma VM do Compute Engine na rede
VPC spoke-1. A rede VPC spoke-2 tem uma VM do Compute Engine
e um cluster do Google Kubernetes Engine (GKE).
Cada rede VPC spoke nessa arquitetura tem uma relação de peering
com uma rede VPC hub central.
O peering de rede VPC não restringe a largura de banda da VM. Cada VM pode enviar
tráfego com a
largura de banda total
associada a ela.
Cada rede VPC spoke tem um gateway NAT do Cloud para
comunicação de saída com a Internet.
O peering de rede VPC não fornece avisos de rota transitiva.
A menos que um mecanismo adicional seja usado, a VM na rede spoke-1 não pode enviar
o tráfego para a VM na rede spoke-2. Para contornar essa restrição
não transitiva, a arquitetura mostra a opção de usar o Cloud VPN para
encaminhar rotas entre as redes. Neste exemplo,
os túneis VPN entre a rede VPC spoke-2 e a rede VPC do tipo hub
permitem a acessibilidade à rede VPC spoke-2
por meio de outros spokes. Se você precisar de conectividade
entre apenas alguns spokes específicos, será possível fazer o peering desses pares de rede
VPC diretamente.
Arquitetura usando o Cloud VPN
A escalonabilidade de uma topologia hub-and-spoke que usa peering de rede VPC está
sujeita a limites do peering de redes VPC. E, como observado anteriormente, as conexões de peering de rede VPC não
permitem tráfego transitivo além das duas redes VPC que estão em uma
relação de peering. No diagrama a seguir, mostramos uma arquitetura de rede hub-and-spoke
alternativa que usa o Cloud VPN para superar as
limitações do peering de rede VPC.
Os recursos que precisam de isolamento em
nível de rede usam redes VPC spoke separadas.
Os túneis VPN IPSec conectam cada rede VPC spoke a uma rede VPC
do tipo hub.
Há uma zona particular de DNS na rede hub, uma zona de peering de DNS e uma zona
particular em cada rede spoke.
Ao escolher entre as duas arquiteturas discutidas até agora, considere os
méritos relativos do peering de rede VPC e do Cloud VPN:
O peering de redes VPC tem a restrição não transitiva, mas é compatível
com a largura de banda total definida pelo tipo de máquina das VMs e outros fatores
que determinam a largura de banda da rede. No entanto, é possível adicionar o roteamento transitivo
adicionando túneis VPN.
O Cloud VPN permite o roteamento transitivo, mas a largura de banda total (entrada e
saída) é limitada às larguras de banda dos túneis.
Alternativas de design
Considere as seguintes alternativas arquiteturais para recursos de interconexão
que são implantadas em redes VPC separadas no Google Cloud:
Conectividade entre spoke usando um gateway na rede VPC hub
Para ativar a comunicação entre spoke, implante um dispositivo virtual de rede (NVA)
ou um firewall de última geração (NGFW) na rede VPC hub
para servir como um gateway para tráfego de spoke-to-spoke.
Peering de rede VPC sem um hub
Se você não precisa de controle centralizado sobre a conectividade local nem para o compartilhamento
de serviços entre redes VPC, uma rede
VPC hub não é necessária. É possível configurar o peering para os pares de rede VPC
que exigem conectividade e gerenciar as interconexões
individualmente. Considere os limites
no número de relacionamentos de peering por rede VPC.
Várias redes VPC compartilhadas
Crie uma rede VPC compartilhada para cada grupo de recursos que você quer
isolar no nível da rede. Por exemplo, para separar os recursos usados nos
ambientes de produção e desenvolvimento, crie uma rede VPC compartilhada
para produção e outra rede VPC compartilhada para desenvolvimento. Em seguida,
faça o peering das duas redes VPC para ativar a comunicação entre redes
VPC. Os recursos em projetos individuais para cada aplicativo ou
departamento podem usar serviços da rede VPC compartilhada apropriada.
Para conectividade entre as redes VPC e sua rede local,
é possível usar túneis VPN separados para cada rede VPC
ou anexos da VLAN separados na mesma
conexão da Interconexão dedicada.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-07-29 UTC."],[[["\u003cp\u003eThis document outlines two main architectural approaches for creating a hub-and-spoke network topology in Google Cloud: one using VPC Network Peering and the other utilizing Cloud VPN.\u003c/p\u003e\n"],["\u003cp\u003eHub-and-spoke topologies are useful for enterprises that need to share resources across multiple VPC networks while maintaining workload isolation, often with a centralized hub network for shared services and on-premises connectivity.\u003c/p\u003e\n"],["\u003cp\u003eVPC Network Peering enables communication between VPC networks using internal IP addresses, maintaining traffic within Google's network and providing full bandwidth, but it has a non-transitive routing limitation unless VPN tunnels are added.\u003c/p\u003e\n"],["\u003cp\u003eCloud VPN offers transitive routing between spoke networks, overcoming the limitations of VPC Network Peering, but its total bandwidth is constrained by the capacity of the VPN tunnels.\u003c/p\u003e\n"],["\u003cp\u003eAlternatives to hub-and-spoke network include using a gateway in the hub VPC network for inter-spoke connectivity, direct VPC network peering for simple use cases, or multiple Shared VPC networks for isolating groups of resources.\u003c/p\u003e\n"]]],[],null,["# Hub-and-spoke network architecture\n\n\u003cbr /\u003e\n\nThis document presents three architectural options for setting up a\nhub-and-spoke network topology in Google Cloud. The first option uses\nNetwork Connectivity Center, the second uses VPC Network Peering, and the third uses\nCloud VPN.\n\nAn enterprise can separate workloads into individual VPC networks for the purposes\nof billing, environment isolation, and other considerations. However, the\nenterprise might also need to share specific resources across these networks,\nsuch as a shared service or a connection to on-premises. In such cases, it can\nbe useful to place the shared resource in a hub network (referred\nto as the *routing* network in the rest of this document) and to attach the other VPC networks as spoke\nnetworks (referred to as *workload* networks in the rest of this document). The following diagram\nshows a hub-and-spoke network with two workload VPCs, though more workload VPCs\ncan be added.\n\nIn this example, separate workload VPC networks are used for the workloads of\nindividual business units within a large enterprise. Each workload VPC network is\nconnected to a central routing VPC network that contains shared services and can\nserve as the sole entry point to the cloud from the enterprise's on-premises\nnetwork.\n\nSummary of options\n------------------\n\nWhen you choose one of the architectures discussed in this document, consider the\nrelative merits of Network Connectivity Center, VPC Network Peering, and\nCloud VPN:\n\n- Network Connectivity Center provides full bandwidth between workload VPCs and provides transitivity between workload VPCs.\n- VPC Network Peering provides full bandwidth between workload VPCs and the routing VPC. It does not provide transitivity among workload VPCs. VPC Network Peering supports routing to NVAs in other VPCs.\n- Cloud VPN allows transitive routing, but the total bandwidth (ingress plus egress) between networks is limited to the bandwidths of the tunnels. Additional tunnels can be added to increase bandwidth.\n\nArchitecture using Network Connectivity Center\n----------------------------------------------\n\nThe following diagram shows a hub-and-spoke network that uses\n[Network Connectivity Center](/network-connectivity/docs/network-connectivity-center/concepts/overview).\n\nNetwork Connectivity Center has a hub resource that provides control plane management,\nbut it's not a hub network for the data plane.\n\n- Network Connectivity Center can connect the networks together by using a star (hub-and-spoke) or mesh topology. Using a star topology prevents inter-VPC-spoke (workload VPC) communication while the mesh topology does not.\n- The routing (hub) VPC network has a connection to on-premises using Cloud VPN or Cloud Interconnect connections.\n- Dynamic routes can be propagated across VPC networks.\n- Private Service Connect routes are transitive between workload VPCs.\n- Private services access routes are transitive between workload VPCs through the use of [producer spokes](/network-connectivity/docs/network-connectivity-center/concepts/producer-vpc-spokes-overview) for [many Google-provided services](/network-connectivity/docs/network-connectivity-center/concepts/producer-vpc-spokes-supported-services). For services where routes are not transitive, a workaround is to connect the consumer VPC network to the routing VPC network by using Cloud VPN instead of Network Connectivity Center.\n- All of the VMs in the peered networks can communicate at the [full bandwidth](/compute/docs/network-bandwidth) of the VMs.\n- Each workload VPC and the routing VPC network has a Cloud NAT gateway for outbound communication with the internet.\n- DNS peering and forwarding is set up so that workloads in workload VPCs can be reached from on-premises.\n\nArchitecture using VPC Network Peering\n--------------------------------------\n\nThe following diagram shows a hub-and-spoke network that uses\n[VPC Network Peering](/vpc/docs/vpc-peering).\nVPC Network Peering enables communication using internal IP addresses\nbetween resources in separate VPC networks. Traffic stays on Google's internal\nnetwork and does not traverse the public internet.\n\n- Each workload (spoke) VPC network in this architecture has a peering relationship with a central routing (hub) VPC network.\n- The routing VPC network has a connection to on-premises using Cloud VPN or Cloud Interconnect connections.\n- All of the VMs in the peered networks can communicate at the [full bandwidth](/compute/docs/network-bandwidth) of the VMs.\n- VPC Network Peering connections are not transitive. In this architecture, the on-premises and workload VPC networks can exchange traffic with the routing network, but not with each other. To provide shared services, either put them in the routing network or connect them to the routing network by using Cloud VPN.\n- Each workload VPC and the routing VPC network has a Cloud NAT gateway for outbound communication with the internet.\n- DNS peering and forwarding is set up so that workloads in workloads VPCs can be reached from on-premises.\n\nArchitecture using Cloud VPN\n----------------------------\n\nThe scalability of a hub-and-spoke topology that uses VPC Network Peering\nis subject to\n[VPC Network Peering limits](/vpc/docs/quota#vpc-peering).\nAnd as noted earlier, VPC Network Peering connections don't allow transitive\ntraffic beyond the two VPC networks that are in a peering relationship. The\nfollowing diagram shows an alternative hub-and-spoke network architecture that\nuses\n[Cloud VPN](/network-connectivity/docs/vpn/concepts/overview)\nto overcome the limitations of VPC Network Peering.\n\n- IPsec VPN tunnels connect each workload (spoke) VPC network to a routing (hub) VPC network.\n- A DNS private zone in the routing network and a DNS peering zone and private zone exist in each workload network.\n- Connections are transitive. The on-premises and spoke VPC networks can reach each other through the routing network, though this can be restricted.\n- Bandwidth between networks is limited by the total [bandwidths of the tunnels](/network-connectivity/docs/vpn/concepts/overview#network-bandwidth).\n- Each workload (spoke) VPC and the routing VPC network has a Cloud NAT gateway for outbound communication with the internet.\n- VPC Network Peering does not provide for transitive route announcements.\n- DNS peering and forwarding is set up so that workloads in workload VPCs can be reached from on-premises.\n\nDesign alternatives\n-------------------\n\nConsider the following architectural alternatives for interconnecting resources\nthat are deployed in separate VPC networks in Google Cloud:\n\n**Inter-spoke connectivity using a gateway in the routing VPC network**\n\nTo enable inter-spoke communication, you can deploy a network virtual appliance\n(NVA) or a next-generation firewall (NGFW) on the routing VPC network, to serve as a\ngateway for spoke-to-spoke traffic.\n\n**Multiple Shared VPC networks**\n\nCreate a Shared VPC network for each group of resources that you want to\nisolate at the network level. For example, to separate the resources used for\nproduction and development environments, create a Shared VPC network for\nproduction and another Shared VPC network for development. Then, peer\nthe two VPC networks to enable inter-VPC network communication. Resources in\nindividual projects for each application or department can use services from the\nappropriate Shared VPC network.\n\nFor connectivity between the VPC networks and your on-premises network, you can\nuse either separate VPN tunnels for each VPC network, or separate VLAN\nattachments on the same Dedicated Interconnect connection.\n\nWhat's next\n-----------\n\n- Deploy a hub-and-spoke network [terraform](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/tree/master/fast/stages/2-networking-a-simple).\n- Learn about connecting your hub-and-spoke topology to on-premises and other clouds in the [Cross-Cloud Network design guide](/architecture/ccn-distributed-apps-design).\n- Learn about more design options for [connecting multiple VPC networks](/architecture/best-practices-vpc-design#connecting_multiple_networks).\n- Learn about the [best practices](/architecture/framework) for building a secure and resilient cloud topology that's optimized for cost and performance."]]