Professional Cloud Network Engineer

Evaluate VPC Spoke Architectures and Dynamic Route Exchange

Differentiating Between Spoke Types in Network Connectivity Center

A Network Connectivity Center (NCC) hub-and-spoke architecture provides centralized management for connecting Google Cloud Virtual Private Cloud (VPC) networks and external on-premises networks. Spokes are categorized by the specific type of backing resource they attach to an NCC hub:

• VPC spokes use a VPC network as their backing resource to export local subnet routes to the hub and import routes from other spokes.
• Hybrid spokes use external connectivity resources such as Router Appliance virtual machines (VMs), High Availability VPN (HA VPN) tunnels, or Cloud Interconnect VLAN attachments to exchange dynamic routes.
• Producer VPC spokes link to a consumer VPC network that is peered via VPC Network Peering to a producer VPC network, allowing workloads across the entire hub to access producer-hosted managed services.

VPC spokes allow granular subnet filtering for IPv4 and IPv6 address ranges, while hybrid spokes exchange dynamic routes using Border Gateway Protocol (BGP) sessions.

Managing Spoke Topologies and Route Tables

Route exchange across an NCC hub relies on centralized route tables organized into either mesh or star network topologies. In a default mesh topology, all spokes reside in a single spoke group and share a single global route table, establishing complete connectivity across every spoke. In a star topology, spokes are organized into center and edge groups to enforce traffic boundaries: spokes in the center group export routes to both center and edge route tables, while spokes in the edge group export routes only to the center route table. This configuration allows edge spokes to communicate with center spokes while preventing edge-to-edge communication. When a project creates a spoke proposal, hub administrators can accept or reject it manually, or configure auto-accept for specific project IDs to approve proposals immediately.

Transitive Routing for Hybrid and Multicloud Interconnectivity

Transitive routing in NCC allows connected spokes to communicate through the central hub without requiring direct peerings or full-mesh tunnels between every network. VPC spokes export their local subnet routes to the hub control plane, which then distributes those routes across other VPC spokes and hybrid spokes. Hybrid spokes advertise dynamic on-premises routes into the hub via Cloud Router BGP sessions, making external sites reachable to all VPC spokes. Simultaneously, Cloud Routers on hybrid spokes use BGP custom route advertisements to advertise imported hub subnet routes back to on-premises routers. This bidirectional propagation establishes an end-to-end data path connecting on-premises facilities, multicloud environments, and multiple VPC networks through the hub.

Implement Hybrid Spokes for Site-to-Site and Site-to-Cloud Connectivity

Hybrid Spoke Resource Attachments

A hybrid spoke connects a VPC network to on-premises facilities or external cloud environments using Cloud Interconnect VLAN attachments, HA VPN tunnels, or Router Appliance VMs. A single hybrid spoke can reference multiple resources of the same type, but all associated resources must reside within the same VPC network. Cloud Interconnect VLAN attachments provide high-speed dedicated or partner physical connections managed by Cloud Router. HA VPN tunnels establish encrypted internet protocol security (IPsec) connections to remote gateways. Router Appliance VMs run third-party network software, such as firewalls or custom routing engines, on Compute Engine instances to exchange dynamic routing data directly with Cloud Router.

Border Gateway Protocol and Autonomous System Number Requirements

Hybrid spokes manage dynamic routing exchanges with non-Google peering routers through BGP sessions managed by Cloud Router. All non-Google routers linked to a single hybrid spoke must use the identical Autonomous System Number (ASN) when advertising network prefixes to Cloud Router. If two routers within the same spoke advertise the same prefix using different ASNs, only one router's ASN and path are re-advertised across the hub. Distinct hybrid spokes must use different ASNs from one another to prevent routing conflicts. Furthermore, hybrid spoke BGP sessions do not support BGP communities, and individual BGP sessions cannot be shared across different network connectivity product types.

Site-to-Site Data Transfer over Google Backbone

Site-to-site data transfer is an NCC feature that routes IPv4 traffic between multiple external networks across the Google Cloud global network backbone. When site-to-site data transfer is enabled on hybrid spokes attached to the same hub, dynamic routes learned from one location—such as an HA VPN tunnel or Cloud Interconnect attachment—are re-advertised to all other data-transfer-enabled hybrid spokes. For example, remote data centers located in New York, Sydney, and Tokyo can achieve full mesh communication through Google Cloud without traversing the public internet. This feature requires that all participating hybrid spokes reference connectivity resources in a single VPC network within supported Google Cloud regions.

Site-to-Cloud Connectivity Topologies

Site-to-cloud topologies enable external corporate offices and third-party clouds to access workloads hosted in Google Cloud VPC networks. When integrating Router Appliance VMs, the instance sits in the VPC network and exchanges routes with Cloud Router using an internal RFC 1918 IPv4 address on its primary interface. VPC spokes can leverage hybrid spokes residing in separate VPC networks to establish centralized egress and ingress paths to on-premises environments. When deploying HA VPN over Cloud Interconnect, two separate Cloud Routers are required: a dedicated Cloud Router for the Cloud Interconnect attachment that restricts traffic to encrypted packets, and a second Cloud Router dedicated to managing the HA VPN tunnels.

Hybrid Spoke IP Addressing and Routing Metrics

Hybrid spokes operate exclusively on IPv4 traffic across all site-to-cloud, site-to-site, and Router Appliance deployments. Routes installed into the VPC network or hub by hybrid spokes are classified as dynamic routes. When Cloud Router operates in regional dynamic routing mode, it advertises only the subnets located in the same Google Cloud region as the hybrid spoke. When global dynamic routing mode is enabled, Cloud Router advertises all VPC subnets across all regions, applying a metric penalty to routes learned outside the local region to preserve optimal, symmetric traffic flow.

Architect Producer Spokes for Managed Service and Multi-Tenant Workloads

Producer VPC Spoke Architecture and Dependencies

A producer VPC spoke enables services hosted in a third-party or managed service producer VPC network to be reached by all spokes connected to an NCC hub. The architecture depends on a consumer VPC network that connects to the producer VPC network via VPC Network Peering and attaches to the NCC hub as a standard VPC spoke. A strict order of operations requires the hub administrator to accept the underlying consumer VPC spoke before accepting the proposed producer VPC spoke. In star topologies, the producer VPC spoke must be assigned to the exact same spoke group—either center or edge—as its paired consumer VPC spoke to maintain consistent route domains.

[ Producer VPC ] <--(VPC Peering)--> [ Consumer VPC (VPC Spoke) ] <--(NCC Hub)--> [ Workload Spokes ]
                                                 |
                                     [ Producer VPC Spoke ]

Route Advertisement Boundaries and Export Range Filtering

Export range filters govern route propagation between producer networks and the NCC hub to prevent route leaks and resolve overlapping IP addresses. A VPC spoke advertises all private IPv4 subnet routes to the hub by default, but administrators can override this behavior using specific filtering criteria:

• Include IPv4 export ranges: Restricts route advertisements to an explicit list of private IPv4 subnets, excluding all unlisted ranges.
• Exclude IPv4 export ranges: Blocks designated IPv4 subnets from advertising to the hub while exporting all remaining subnets.
• Include IPv6 export ranges: Configures the spoke to export all internal and external IPv6 subnet routes to the hub.

Whenever subnets are created, updated, or removed in the underlying VPC network, Google Cloud automatically synchronizes the local VPC route table and the hub route table in real time.

Spoke Lifecycle States and Administrative Approvals

Spoke proposals follow a managed lifecycle to give hub administrators administrative control over network attachments. When a project administrator proposes a new spoke or submits configuration updates, the spoke enters an Inactive state marked as PENDING_REVIEW or UPDATE_PENDING_REVIEW. The hub administrator must review the configuration and explicitly accept it to move the spoke to the Active state, or reject it to place it in an Inactive, rejected state. Administrators can bypass manual review workflows by configuring an auto-accept list of trusted project IDs on a spoke group, which automatically transitions matching spoke proposals to the Active state upon submission.

Multi-Tenant Isolation and Integration Choices

Enterprises select between producer VPC spokes, Private Service Connect (PSC), and transit appliance architectures based on required security controls and routing depth:

• Producer VPC spokes with NCC: Choose this pattern to provide broad, multi-spoke IP routing to a peered managed service network without configuring discrete gateways for each workload VPC.
• Private Service Connect endpoints: Choose this pattern to expose services through explicit internal IP addresses, avoiding subnet route distribution and eliminating IP address overlap entirely.
• Transit VPC with appliances: Choose this pattern when organizational policy mandates inline Layer 7 deep packet inspection using Network Virtual Appliances (NVAs) positioned behind an internal passthrough Network Load Balancer.

Network security boundaries within the hub are enforced using Cloud Next Generation Firewall (Cloud NGFW) policies and hierarchical firewall rules to isolate multi-tenant workloads while allowing authorized traffic to reach shared producer endpoints.

Key Facts

• Network Connectivity Center (NCC) supports three primary spoke types: VPC spokes for subnet route exchange, hybrid spokes for external BGP dynamic routing, and producer VPC spokes for extending peered managed service networks across a hub.
• Hybrid spokes support only IPv4 traffic, and all external BGP peers linked to a single hybrid spoke must use the same Autonomous System Number (ASN).
• A hub administrator must approve the consumer VPC spoke before accepting a dependent producer VPC spoke.
• Site-to-site data transfer enables external networks to route traffic across the Google Cloud backbone by linking hybrid spokes within the same VPC network.
• Spoke export filters allow administrators to specify include or exclude ranges for IPv4 subnets, preventing accidental route leaks and IP address overlap.

Frequently Asked Questions

What is the difference between a VPC spoke and a producer VPC spoke?

A VPC spoke attaches a standard VPC network directly to an NCC hub to exchange local subnet routes. A producer VPC spoke attaches to a consumer VPC network that is peered with a producer VPC network, allowing workloads across the entire hub to access the producer's services without requiring direct VPC peering connections to every workload network.

When should an organization choose Private Service Connect instead of a producer VPC spoke?

Choose Private Service Connect when a managed service needs to be published through an explicit internal IP address endpoint rather than exposing entire subnet routes. This approach bypasses VPC peering limits and prevents IP address overlap across multi-tenant environments.

What are the BGP ASN requirements when configuring hybrid spokes?

All non-Google BGP routers connected to a single hybrid spoke must use the same ASN when advertising prefixes to Cloud Router. Additionally, different hybrid spokes attached to the hub must use distinct ASNs from one another.