Connecting Cloud Networks with Network Connectivity Center — What I Actually Learned

Before this lab, I thought of Google Cloud networking as a collection of isolated pieces — VPCs that don't talk unless you explicitly peer them, on-prem offices connecting through Cloud VPN, workload networks living separately. Network Connectivity Center changed how I think about all of it.

Instead of stitching point-to-point connections manually, NCC gives you a single hub that all your networks plug into as spokes — and they can all communicate through it.

💡 This post is written as a learning reflection — what I understood, what surprised me, and what I'd do differently. It's not a step-by-step lab guide.

What is Network Connectivity Center?

NCC is Google Cloud's managed hub-and-spoke network. You create one central hub, attach any number of spokes — each representing a network — and spokes can talk to each other through the hub automatically.

Think of it like a baby monitor system. Without NCC, every parent in the house would need their own dedicated monitor pointed at every single room — that's VPC peering, and it gets messy fast. With NCC, there's one central monitor station in the living room. Every room connects to it, and anyone watching the station can see everything.

The architecture this lab covers:

On-Prem Office 1  ──┐
                    ├── VPN spokes ──► NCC Hub ◄── VPC spokes ──┬── Workload VPC 1
On-Prem Office 2  ──┘                                           └── Workload VPC 2

Three things that genuinely impressed me:

• One hub handles both cloud-to-cloud and on-prem-to-cloud connectivity

• Add a new spoke → it instantly gets connectivity to all existing spokes

• Google manages the routing plane — no BGP sessions, no routing protocols to configure yourself

The two spoke types — and why they behave differently

This is where most people (including me) get tripped up. There are two completely different spoke types with different scopes, flags, and mechanics.

VPN spokes — for on-prem offices

Used when your on-prem offices connect via existing Cloud VPN tunnels. These are regional resources.

gcloud network-connectivity spokes linked-vpn-tunnels create SPOKE_NAME \
  --hub=HUB_NAME \
  --vpn-tunnels=TUNNEL_0,TUNNEL_1 \
  --region=REGION \
  --site-to-site-data-transfer \
  --project=PROJECT_ID

Key things I learned the hard way:

• Use --region, not --global

• Always attach tunnels from the routing VPC side — the ones named routing-to-onprem-*, not the on-prem side tunnels. Using the wrong tunnels creates a spoke that shows ACTIVE but routing silently fails

• --site-to-site-data-transfer is required to enable traffic between spokes

VPC spokes — for cloud VPCs

Used when connecting Google Cloud VPC networks directly. These are global resources.

gcloud network-connectivity spokes linked-vpc-network create SPOKE_NAME \
  --hub=HUB_NAME \
  --vpc-network=VPC_NAME \
  --global \
  --project=PROJECT_ID

Key things I learned:

• Use --global, not --region — VPC networks are global resources in GCP

• The command subgroup is linked-vpc-network, not linked-vpn-tunnels — easy to mix up when you're moving fast

• Tasks 1 and 2 share the same hub; Task 3 uses a separate hub

Quick comparison

Hybrid connectivity — where NCC gets really powerful

The most impressive part of the lab was connecting an on-prem office directly to a cloud workload VPC — no direct tunnel between them, all traffic routing through NCC.

On-Prem Office 1
      │
      │  VPN tunnels (routing-vpc side)
      ▼
 NCC Hybrid Hub  ◄──────────  Workload VPC 1 (VPC spoke)

When the ping from the on-prem VM finally reached the workload VM — that was the most satisfying moment of this lab. Two separate worlds, one in the data center and one in the cloud, communicating through a managed hub with no direct connection between them.

This is the pattern that enterprises actually use in production when migrating to Google Cloud incrementally.

Things I wish I knew before starting

Always inventory your environment first. Before creating anything, run these three commands to understand what's pre-provisioned:

# List all VPCs
gcloud compute networks list --project=$DEVSHELL_PROJECT_ID

# List all VPN tunnels (critical for VPN spokes)
gcloud compute vpn-tunnels list --project=$DEVSHELL_PROJECT_ID

# List all VMs and their internal IPs
gcloud compute instances list --project=$DEVSHELL_PROJECT_ID

Knowing the exact internal IPs before you start saves enormous time when verifying connectivity later.

Running gcloud compute networks list to inventory all pre-provisioned VPCs before starting

All gcloud commands run from Cloud Shell — never from inside a VM SSH session. This sounds obvious but when you're deep in an SSH session trying to debug connectivity, it's easy to forget. Exit the VM first, run the gcloud command, then SSH back in to test.

ACTIVE status ≠ working connectivity. A spoke can show ACTIVE while routing is broken if you attached the wrong tunnels or used wrong flags. Always verify with an actual ping:

# 1. Check spoke status
gcloud network-connectivity spokes list --hub=HUB_NAME --project=$DEVSHELL_PROJECT_ID

# 2. SSH from Cloud Shell (not from another VM)
gcloud compute ssh VM_NAME --zone=ZONE --project=$DEVSHELL_PROJECT_ID

# 3. Ping inside the SSH session
ping -c 4 DESTINATION_INTERNAL_IP

The NCC Console dashboard is your friend. Go to Network Connectivity Center in the console → click into a hub → you can see all spokes, their types, status, and regions at a glance. Much faster than running CLI list commands repeatedly.

Network Connectivity Center

All VPN tunnels pre-provisioned and showing ✅ Established — BGP sessions confirmed before attaching any NCC spokes

Three Cloud Routers pre-provisioned — one per VPC, each with BGP sessions already established

The 3 things that genuinely surprised me

1. NCC is simpler to operate than I expected — the complexity is in understanding the model, not configuring it. The actual commands are short. The mental model — hub, spokes, spoke types, regional vs global — takes longer to internalise. Invest time in the theory first and the lab moves quickly.

2. The routing VPC is the invisible glue in VPN spoke architecture. There's a routing VPC sitting between the NCC hub and the on-prem offices that you don't create — it's pre-provisioned. Understanding its role (it terminates the VPN tunnels, and the NCC spokes attach to those tunnels) is essential for troubleshooting. Without knowing it exists, the tunnel naming convention makes no sense.

3. This lab is a realistic enterprise architecture — not a toy example. Two on-prem offices, two cloud workload VPCs, hybrid connectivity between them — this is exactly the network a real company would build when migrating to Google Cloud incrementally. Completing it gave me genuine confidence in how production hybrid networks actually work.

Why NCC matters for the PCNE exam

If you're studying for the Professional Cloud Network Engineer certification, NCC is worth understanding deeply — not just for the exam, but because it fundamentally changes how you'd architect multi-site connectivity on Google Cloud.

The key exam concepts from this lab:

• Hub-and-spoke architecture and when to use NCC vs VPC peering

• Spoke types and their different scoping (regional VPN vs global VPC)

• Hybrid connectivity patterns (on-prem to cloud through NCC)

• The role of routing VPCs in VPN spoke architecture

Written as part of my GCP certification study series. Lab: Connecting Cloud Networks with NCC: Challenge Lab