Hub-and-spoke network architecture

This document presents two architectural options for setting up a hub-and-spoke network topology in Google Cloud. One option uses the network peering capability of Virtual Private Cloud (VPC), and the other uses Cloud VPN.


What is a hub-and-spoke network, and when is it useful? As an enterprise architect or a network administrator, when you design the Google Cloud topology for a large enterprise, you might need to plan for network-level isolation of resources used by different business units, workloads, or environments. Such isolation enables granular control over network traffic for each group of resources. It could also help you meet legal and regulatory data-separation requirements.

You can achieve network-level isolation of resources in Google Cloud by deploying the resources in separate VPC networks. To enable the resources in these VPC networks to use shared services (such as firewalls or configuration metadata), and for centralized access to the cloud from your on-premises network, you can connect each VPC network to a central hub VPC network. The following diagram shows an example of the resulting hub-and-spoke network, sometimes called a star topology.

Hub-and-spoke network schema.

In this example, separate spoke VPC networks are used for the workloads of individual business units within a large enterprise. Each spoke VPC network is connected to a central hub VPC network that contains shared services and can serve as the sole entry point to the cloud from the enterprise's on-premises network.

Architecture using VPC Network Peering

The following diagram shows a hub-and-spoke network using VPC Network Peering, which enables secure communication between resources in separate VPC networks over Google's internal network using private IP addresses, without the inter-VPC network traffic traversing the public internet.

Hub-and-spoke architecture using VPC Network Peering
  • In this architecture, the resources that need network-level isolation use separate spoke VPC networks. For example, the architecture shows a Compute Engine VM in the spoke-1 VPC network. The spoke-2 VPC network has a Compute Engine VM and a Google Kubernetes Engine (GKE) cluster.

  • Each spoke VPC network in this architecture has a peering relationship with a central hub VPC network.

  • Each spoke VPC network has a Cloud NAT gateway for outbound communication with the internet.

  • The peering connections between the spoke VPC networks and the hub VPC network don't allow transitive traffic; that is, inter-spoke communication through the hub is not possible. Resources such as GKE private nodes and Cloud SQL instances that have private IP addresses require a proxy for access from outside their VPC network.

    To work around the non-transitivity constraint of VPC Network Peering, the architecture shows the option of using Cloud VPN. In this example, a VPN tunnel between the spoke-2 VPC network and the hub VPC network enables connectivity from the spoke-2 VPC network to the other spokes. If you need connectivity between only a few specific spokes, you can peer those VPC network pairs directly.

Architecture using Cloud VPN

The scalability of a hub-and-spoke topology that uses VPC Network Peering is subject to VPC Network Peering limits. And as noted earlier, VPC Network Peering connections don't allow transitive traffic beyond the two VPC networks that are in a peering relationship. The following diagram shows an alternative hub-and-spoke network architecture that uses Cloud VPN to overcome the limitations of VPC Network Peering.

Hub-and-spoke architecture using Cloud VPN
  • In this architecture, too, the resources that need network-level isolation use separate spoke VPC networks.
  • An IPSec VPN tunnel connects each spoke VPC network to a hub VPC network.
  • Each spoke VPC network has a Cloud NAT gateway for outbound communication with the public internet.

When choosing between the two architectures discussed so far, consider the relative merits of VPC Network Peering and Cloud VPN:

  • VPC Network Peering has the non-transitivity constraint, but it supports the full bandwidth defined by the machine type of the VMs and other factors that determine network bandwidth.
  • Cloud VPN allows transitive routing, but the total bandwidth (ingress plus egress) of each VPN tunnel is limited to 3 Gbps.

Design alternatives

Consider the following architectural alternatives for interconnecting resources that are deployed in separate VPC networks in Google Cloud:

Inter-spoke connectivity using a gateway in the hub VPC network
To enable inter-spoke communication, you can deploy a network virtual appliance (NVA) or a next-generation firewall (NGFW) on the hub VPC network, to serve as a gateway for spoke-to-spoke traffic. See Centralized network appliances on Google Cloud.
VPC Network Peering without a hub
If you don't need centralized control over on-premises connectivity or sharing services across VPC networks, then a hub VPC network isn't necessary. You can set up peering for the VPC network pairs that require connectivity, and manage the interconnections individually. Do consider the limits on the number of peering relationships per VPC network.
Multiple Shared VPC networks

Create a Shared VPC network for each group of resources that you want to isolate at the network level. For example, to separate the resources used for production and development environments, create a Shared VPC network for production and another Shared VPC network for development. Then, peer the two VPC networks to enable inter-VPC network communication. Resources in individual projects for each application or department can use services from the appropriate Shared VPC network.

For connectivity between the VPC networks and your on-premises network, you can use either separate VPN tunnels for each VPC network, or separate VLAN attachments on the same Dedicated Interconnect connection.

What's next