Network Connectivity Center, in depth: hubs, spokes, topologies and route control on Google Cloud

The problem NCC solves

Consider five VPC networks and one on-premises data centre. With peering, full connectivity needs ten peerings, and on-premises routes learned in one VPC are not usable from a VPC peered to it in the general case, so each VPC also needs its own hybrid path or an appliance in the middle. Every new VPC adds work, and nobody can see the whole routing picture in one place.

NCC replaces the pairwise graph with a hub and spokes. The hub is a global resource. Each spoke represents a VPC network or a set of hybrid resources. The hub collects routes from its spokes into route tables and installs them in the other spokes according to the topology. The hub is a control-plane construct: it does not sit in the data path, so traffic between VPC spokes flows directly over Google's network rather than through a central appliance. AWS users will recognise the idea from Transit Gateway, although the two differ in detail.

Concepts: hubs, spokes, groups and route tables

• Hub. A global resource. It has a policy mode and a preset topology, chosen at creation. The topology cannot be changed afterwards, so choose deliberately.
• VPC spoke. Attaches a VPC network, which can be in another project. It exports its subnet routes to the hub and imports subnet and dynamic routes from the hub.
• Producer VPC spoke. Makes a service producer network, reached through VPC peering (for example a managed service's network), reachable by the other spokes.
• Hybrid spokes. Attach HA VPN tunnels, Cloud Interconnect VLAN attachments, router appliance VMs (your own virtual routers that speak BGP with Cloud Router), or Partner Cross-Cloud Interconnect for AWS. Routes they install in VPC spokes are treated as dynamic routes.
• NCC Gateway spoke. A newer regional spoke type for steering traffic through third-party Security Service Edge inspection.
• Groups. Spokes belong to groups. A mesh hub has one group, default. A star hub has center and edge.
• Route tables. The hub keeps route tables whose contents follow the topology; inspecting them is the first step in any troubleshooting session.

Mesh or star

Mesh is the default. Every spoke can reach every other spoke, which suits a flat estate where VPCs are split for administrative reasons rather than isolation. Star provides segmentation: spokes in the center group can reach each other and the edge, while edge spokes can reach only the center. That is the shape you want when production and development must both reach shared services and on-premises, but never each other. A third preset, hybrid inspection, which inserts inspection between groups, is in Preview at the time of writing.

One constraint shapes star designs: a hybrid spoke with site-to-site data transfer enabled must be in the center group. In practice the hybrid connectivity and the shared-services VPC go in the center and workload VPCs go on the edge.

Worked example: shared services, prod, dev and on-premises

Requirements: prod and dev VPCs (in their own projects) must reach a shared-services VPC (DNS, CI runners, artifact registry) and the on-premises network over HA VPN. Prod and dev must not reach each other. A legacy range in dev overlaps an on-premises subnet and must never be advertised.

# 1. Hub with a star topology (cannot be changed later)
gcloud network-connectivity hubs create corp-hub \
  --preset-topology=STAR \
  --description="corp hub: center = shared + hybrid, edge = workloads"

gcloud network-connectivity hubs groups list --hub=corp-hub   # expect: center, edge

# 2. Center: shared-services VPC (it also hosts the HA VPN and Cloud Router)
gcloud network-connectivity spokes linked-vpc-network create shared-svc \
  --hub=corp-hub --global --group=center \
  --vpc-network=projects/net-host/global/networks/shared-svc

# 3. Center: hybrid spoke for the HA VPN tunnels to on-premises
gcloud network-connectivity spokes linked-vpn-tunnels create onprem-vpn \
  --hub=corp-hub --region=europe-west1 --group=center \
  --vpn-tunnels=onprem-tun-0,onprem-tun-1 \
  --include-import-ranges=ALL_IPV4_RANGES

# 4. Edge: workload VPCs; hide dev's legacy overlapping range from the hub
gcloud network-connectivity spokes linked-vpc-network create prod \
  --hub=projects/net-host/locations/global/hubs/corp-hub --global --group=edge \
  --vpc-network=projects/prod-net/global/networks/prod

gcloud network-connectivity spokes linked-vpc-network create dev \
  --hub=projects/net-host/locations/global/hubs/corp-hub --global --group=edge \
  --vpc-network=projects/dev-net/global/networks/dev \
  --exclude-export-ranges=10.200.0.0/16

Step 4 runs from the workload projects, so the spokes are proposed to a hub in another project. Unless the hub auto-accepts them, the hub administrator reviews and accepts each one with gcloud network-connectivity hubs accept-spoke. That review is a useful control point: it is where a central network team decides which VPCs join and in which group.

The hybrid spoke's --include-import-ranges=ALL_IPV4_RANGES lets it import the hub's subnet routes so the Cloud Router can advertise them to on-premises over BGP. Confirm the Cloud Router's advertisement settings actually include them, and remember that on-premises routers will see the union of every exported range. The dev exclusion keeps 10.200.0.0/16 out of the hub entirely, so it is never sent to on-premises and never collides there.

How routes are filtered

VPC spokes have export filters. If you specify none, the default is equivalent to ALL_PRIVATE_IPV4_RANGES: every subnet in a private range is exported. --include-export-ranges narrows the set to listed CIDRs and --exclude-export-ranges carves exceptions out of it. Include ranges accept up to 16 unique, non-overlapping CIDRs. Google Cloud will refuse to create a new subnet whose range straddles an include boundary, so design include ranges as clean supernets of your address plan.

Hybrid spokes have import filters instead; VPC spokes do not. The include-import list for a hybrid spoke accepts only ALL_IPV4_RANGES and defaults to empty when site-to-site data transfer is off, which is why the example sets it explicitly.

Overlap is the classic failure. Two spokes exporting the same or overlapping subnet ranges cannot both be reachable unambiguously, so expect spoke creation to fail rather than NCC picking one; read the error, which names the conflicting range. The fix is an address plan with non-overlapping ranges per VPC, and exclude filters for legacy ranges that cannot be renumbered.

Site-to-site transfer and Private Service Connect

Hybrid spokes can also connect sites to each other through Google's backbone, for example two data centres each with an Interconnect, by enabling --site-to-site-data-transfer on the spokes. It is available only in supported locations, the spokes must be in the same VPC network, and in a star hub they must sit in the center group. Check data-transfer pricing before using Google as your WAN.

Separately, a hub created or updated with --export-psc propagates Private Service Connect endpoints, so a published service consumed through PSC in one spoke can be reached from the others without repeating endpoints in every VPC. Disabling it later removes the propagated connections asynchronously, so plan that change like a route withdrawal.

Migrating from a peering mesh

Most teams adopt NCC with peerings already in place, and the migration is a routing change on live traffic. Plan it in the same order every time.

1. Inventory. Export every peering, its exchanged routes and any custom route import or export settings. List which pairs actually carry traffic using VPC Flow Logs, so you know which paths must survive the cutover.
2. Check overlaps first. Peerings tolerate overlaps between VPCs that never peer with each other; a hub sees all of them at once. Compute the union of every subnet range that will be exported and resolve conflicts with exclude filters or renumbering before attaching anything.
3. Test coexistence before the window. Whether two VPCs that are still peered can join the same hub depends on the subnet routes the peering already installs, and attachment may fail on the duplicates. Try it in a staging pair first; if it fails, plan each cutover as delete peering, attach spoke, verify, inside a maintenance window.
4. Cut over pair by pair. Move one peering at a time, verify with Connectivity Tests and application health checks, then move to the next. Keep the peering definition in code so you can restore it quickly.
5. Clean up. Remove now-unused custom routes and per-VPC VPN tunnels that the shared hybrid spoke replaces, and update runbooks so on-call engineers look at hub route tables first.

Operating NCC

Treat the hub like a router you can inspect. List spokes and their states, read the hub route tables, and compare them with the effective routes in a spoke VPC:

gcloud network-connectivity spokes list --hub=corp-hub
gcloud network-connectivity hubs route-tables list --hub=corp-hub
gcloud network-connectivity hubs route-tables routes list \
  --hub=corp-hub --route_table=-           # "-" lists every route table in the hub
gcloud compute routers get-status onprem-router --region=europe-west1   # BGP-learned routes

Firewall rules are still per VPC: NCC makes routes exist, it does not allow traffic. A new spoke that can route but cannot connect almost always lacks an ingress rule for the other spoke's ranges. Connectivity Tests in Network Intelligence Center simulate a packet path and will tell you whether a route or a firewall rule is the blocker. For the BGP side, the session and route-advertisement mechanics in BGP basics apply unchanged.

Keep the hub and spokes in infrastructure as code. Terraform's Google provider exposes NCC hubs and spokes as resources, which turns spoke proposals into reviewed pull requests instead of console clicks.

Failure modes and trade-offs

NCC versus peering. Peering is free of a central object and fine for two or three VPCs. NCC wins once you need transitivity, shared hybrid connectivity or segmentation, at the cost of a new control plane to understand and some per-spoke and data-processing charges.

NCC versus Shared VPC. Shared VPC puts many projects into one network with one administrator; NCC connects many networks that keep separate administration. Large organisations use both: Shared VPC per environment, NCC between them.

NCC versus a transit VPC of virtual appliances. Appliances give inspection and full routing control but are throughput bottlenecks and HA projects of their own. NCC keeps the data path native; when you need inspection, router appliance spokes, NCC Gateway spokes or the hybrid inspection topology bring it back selectively.

If services only need a few private endpoints rather than whole networks, consider Private Google Access and Private Service Connect before joining networks at all.

What to do next

1. Write down the reachability matrix: which VPCs and sites must reach which. That decides mesh or star, and it cannot be changed later.
2. Produce a non-overlapping address plan and list legacy ranges that need exclude filters.
3. Create the hub and the shared-services and hybrid spokes in the center group; add workload VPCs as proposed spokes and accept them through review.
4. Set include-import-ranges on hybrid spokes and verify on-premises routers learn exactly the intended prefixes.
5. Add firewall policies for hub ranges, then prove each matrix cell with Connectivity Tests.
6. Put hubs and spokes in Terraform and add a check that rejects new subnets overlapping the plan.