Understanding Hub-Spoke Topology in GCP

techhadoop GCP

Here’s a clear, enterprise-grade explanation of Hub-Spoke topology in GCP, mapped to how you’d actually design it in production (very similar to Azure Landing Zones, but with GCP-native constructs).

Hub-Spoke Topology in Google Cloud Platform

Concept (Simple View)

Image
Image

Hub = centralized services (security, connectivity, control)
Spokes = application workloads (isolated environments)

Core Components (GCP Mapping)

1. Hub VPC (Transit / Shared Services)

What lives in the Hub:

  • Firewall / inspection (NGFW, IDS/IPS)
  • Cloud NAT (outbound internet)
  • VPN / Interconnect (on-prem connectivity)
  • DNS (Cloud DNS private zones)
  • Logging / monitoring agents
  • Security tooling (SIEM, proxies)

2. Spoke VPCs (Workloads)

Each spoke is:

  • App-specific (e.g., prod, dev, data)
  • Isolated network boundary
  • No direct internet exposure (recommended)

Examples:

  • spoke-prod-app
  • spoke-dev-app
  • spoke-data-platform

3. Connectivity Layer

Option A: VPC Peering
  • Simple
  • No transitive routing
Option B: Google Cloud VPC Network Peering
  • Used for direct hub ↔ spoke
Option C (Recommended): Google Cloud Network Connectivity Center
  • Enables true hub-spoke with transitive routing
  • Central control of connectivity

4. Shared VPC (IMPORTANT)

The most “GCP-native” hub-spoke model

Use:

  • Host Project → owns VPC (hub)
  • Service Projects → attach (spokes)
Host Project (Hub VPC)
   ├── Subnet: shared-services
   ├── Subnet: security
   ├── Subnet: transit
Service Project A (Spoke)
   ├── Uses subnet from Host VPC
Service Project B (Spoke)
   ├── Uses subnet from Host VPC

Security Design (This is what interviewers want)

1. Centralized Egress Control

All outbound traffic:
Spokes → Hub → Internet (via NAT / firewall)

Why:

  • Prevent data exfiltration
  • Apply inspection

2. Zero Trust Networking

  • No direct spoke-to-spoke communication (default deny)
  • Use:
    • Firewall rules
    • Identity-aware proxy (IAP)

3. Private Services Access

  • Private Google Access
  • Private Service Connect (for APIs)

4. DNS Centralization

Use:

  • Cloud DNS private zones
  • Forwarding rules for hybrid (on-prem)

5. Logging & Monitoring

  • VPC Flow Logs
  • Firewall logs
  • Centralized in hub project

Reference Architecture (Production)

Typical Enterprise Layout

                On-Prem
                   │
        ┌──────────┴──────────┐
        │   VPN / Interconnect│
        └──────────┬──────────┘
                   │
             ┌─────▼─────┐
             │   HUB VPC │
             │───────────│
             │ Firewall  │
             │ NAT       │
             │ DNS       │
             │ Logging   │
             └─────┬─────┘
        ┌──────────┼──────────┐
        │          │          │
   ┌────▼───┐ ┌────▼───┐ ┌────▼───┐
   │Spoke A │ │Spoke B │ │Spoke C │
   │(Prod)  │ │(Dev)   │ │(Data)  │
   └────────┘ └────────┘ └────────┘

Common Mistakes (Real-World)

1. Using only VPC Peering

  • No transitive routing → breaks hub model

2. Allowing direct internet from spokes

  • Bypasses security inspection

3. No centralized DNS

  • Causes hybrid resolution failures

4. Flat network (no segmentation)

  • High blast radius

5. Overusing firewall allow rules

  • Leads to implicit trust

Advanced Enhancements

1. Service Perimeter (Data Protection)

Use:

  • VPC Service Controls

Prevent:

  • Data exfiltration to external networks

2. Identity-Based Access

  • IAM Conditions
  • IAP for internal apps

3. Multi-Region Hub-Spoke

  • Hub per region OR global hub with NCC

4. Secure GKE Integration

  • Private GKE clusters in spokes
  • Control plane restricted
  • Egress via hub

Interview Answer (2-Minute Version)

“
In GCP, a hub-spoke topology uses a centralized hub VPC for shared services like firewall, NAT, DNS, and hybrid connectivity, while application workloads run in isolated spoke VPCs or service projects.

The most GCP-native implementation is Shared VPC, where a host project owns the network and service projects act as spokes.

For enterprise scale, I use Network Connectivity Center instead of basic VPC peering to enable transitive routing.

From a security perspective, I enforce centralized egress through the hub, implement zero-trust segmentation between spokes, use private clusters for GKE, centralize DNS, and enable logging and monitoring in the hub.

This pattern reduces blast radius, improves governance, and aligns with landing zone architecture.
”

Leave a Reply