Also read,  A Shared VPC versus HUB VPC in GCP

and IAM and VPC Service Controls - a 2 minute security solution on GCP

Hub-and-Spoke on GCP: A Reusable Design with Shared VPCs for Each Environment

A reusable hub-and-spoke architecture on Google Cloud combines a central connectivity VPC with separate Shared VPC networks for production and nonproduction.

The hub provides connectivity to on-premises infrastructure and selected shared services. Each environment manages its workloads through its own Shared VPC host project and associated service projects.

This approach separates two responsibilities:

• The hub centralizes connectivity.
• Each environment’s Shared VPC centralizes networking for its application projects.

What Belongs in the Hub?

The hub is a custom-mode VPC in a dedicated networking project. It connects to each environment’s VPC through VPC Network Peering.

Typical hub responsibilities include:

• Hybrid connectivity: Cloud Interconnect or HA VPN connections to on-premises infrastructure.
• Routing: Cloud Router and the route configuration needed to reach on-premises networks.
• Shared network services: DNS forwarding and other services intentionally shared across environments.
• Connectivity administration: Central ownership of hybrid connections and hub-to-spoke peering.

The hub should expose only the services required by connected environments. Avoid unnecessary public IP addresses and restrict traffic through explicit firewall policies.

However, a hub does not become an internet gateway simply because spokes are peered with it. Centralized internet egress requires a separately designed forwarding and inspection path. Peering does not exchange routes whose next hop is the default internet gateway.

What Belongs in Each Spoke?

Each spoke represents an environment, such as production, staging, or development.

For this design, each environment has:

• A dedicated Shared VPC host project.
• A custom-mode VPC with deliberately allocated subnet ranges.
• Application service projects attached to that host project.
• Firewall controls that restrict communication between workload tiers.

For example:

Environment	Shared VPC host project	Attached service projects
Production	prj-prod-network-host	Production application, data, and platform projects
Nonproduction	prj-nonprod-network-host	Development, testing, and staging projects

Shared VPC is not a separate network type. It allows resources in service projects to use subnets from a VPC owned by a host project. The service projects retain ownership of their application resources.

Custom-mode networks are a better fit for this reusable design than default or auto-mode networks because they support deliberate IP planning. Allocate nonoverlapping address ranges for the hub, spokes, and on-premises networks before configuring connectivity.

How Do the Hub and Spokes Communicate?

Each spoke establishes a separate peering relationship with the hub. Peering provides private connectivity between the connected networks.

An important characteristic is that VPC Network Peering is non-transitive.

If production and nonproduction are both peered with the hub, those peering relationships do not automatically create a path between production and nonproduction. Any additional connectivity must be designed explicitly.

This is useful for environment separation, but it is only one part of the security model. Firewall policies and carefully scoped IAM permissions remain essential.

Within each spoke, define the permitted application flows. For example:

Source	Destination	Intended access
Web tier	Application tier	Required application ports
Application tier	Database tier	Required database ports
Administration systems	Workload instances	Approved management access
Other workloads	Database tier	Denied unless explicitly authorized

Peering exchanges routes, not firewall rules. Each connected VPC must enforce its own traffic controls.

How Does a Spoke Reach On-Premises Systems?

The hub’s hybrid connection can provide on-premises connectivity for the spokes, provided routing is configured in both directions.

For a design using HA VPN or Cloud Interconnect with Cloud Router:

1. Learn on-premises prefixes in the hub.
   Cloud Router receives these routes through BGP.
2. Export the required custom routes from the hub.
   Configure the hub’s peering relationship to export custom routes.
3. Import those routes into each spoke.
   Configure the corresponding spoke peering relationship to import custom routes.
4. Advertise the spoke subnet ranges to on-premises routers.
   Configure Cloud Router custom advertisements so on-premises systems have a return path.
5. Permit the required traffic.
   Validate firewall rules, on-premises controls, and routing scope.

Exchanging routes with the spokes is not enough by itself: on-premises routers also need routes back to the spoke subnets.

What Should the Folder Structure Look Like?

Folders should reflect the organization’s administrative and policy boundaries. For this architecture, separating shared networking, production, and nonproduction provides a practical starting point.

Folder	Example projects	Purpose
Shared Infrastructure	prj-network-hub	Hybrid connectivity and shared network services
Production	prj-prod-network-host, production service projects	Production networking and workloads
Nonproduction	prj-nonprod-network-host, development and test service projects	Nonproduction networking and workloads

Departmental folders can sit beneath the environment folders where needed.

The folder hierarchy does not create network isolation by itself. Its purpose is to make IAM inheritance, policy application, and administrative ownership align with the intended environment boundaries.

Why Use Separate Shared VPC Host Projects?

A single Shared VPC host project can support multiple service projects, and it can be configured securely. However, service projects using the same VPC are not independent network spokes. They share the host network.

For organizations that require strong production and nonproduction separation, separate host projects make ownership and permission boundaries easier to manage.

A practical access model is to:

• Give the central networking team responsibility for the hub.
• Scope environment networking permissions to the appropriate host project.
• Give application teams access only to the subnets they require.
• Review inherited permissions that could span both environments.

Google Cloud supports granting the Compute Network User role at individual subnet scope rather than across an entire host project.

An accidental Shared VPC Admin grant should not be described as automatically granting access to production workloads. The actual exposure depends on the principal’s complete permissions and the network configuration. The architectural concern is that broad cross-environment authority increases the scope of a misconfiguration.

Use the hub to share connectivity, and use a separate Shared VPC host project for each environment to organize its networking and application projects. This creates a repeatable foundation while keeping environment boundaries explicit.

 

What does the folder structure look like for such a network design?

Folder structures can be driven by organizational departmental hierarchies or by network topology.

In my experience, network design (and environment segregation) are the drivers behind folder  structures.

Summary

The Shared Host VPC is often used as the Hub and Service Projects as Spokes. This isn't ideal - especially if the spokes are ENVIRONMENTS (production and non production). This will couple environments through the hub and an accidental IAM permission on the HUB (Shared VPC Admin) would enable a NON PRODUCTION admin to get to PRODUCTION resources.

A better solution is to use the traditional Hub Spoke design along with Shared Host VPCs for each of the spokes, as described in this post.