VPC spokes overview

This page provides an overview of Virtual Private Cloud (VPC) spokes support in Network Connectivity Center (NCC).

VPC spokes

Network Connectivity Center provides inter-VPC network connectivity at scale with the support for VPC spokes. VPC spokes reduce the operational complexity of managing the individual pair-wise VPC Network Peering connections through the use of VPC spokes and a centralized connectivity management model. VPC spokes can export and import all subnet routes from other spoke VPCs on a Network Connectivity Center hub. This ensures full connectivity between all workloads that reside in all these VPC networks. Inter-VPC network traffic stays within the Google Cloud network and does not travel through the internet, which helps to ensure privacy and security.

VPC spokes can be in the same project and organization or in a different project and organization from the NCC hub. A VPC spoke can be connected to one hub at a time.

For information about how to create a VPC spoke, see Create a VPC spoke.

Considerations for dynamic route exchange with VPC spokes

  • Routing VPC networks that are also VPC spokes: NCC supports two or more routing VPC networks on the same hub only if all of the routing VPC networks aren't also VPC spokes. If an NCC hub has a single routing VPC network, that routing VPC network can optionally also be a VPC spoke:

    • If you need to make propagated Private Service Connect connections available to on-premises networks through the hub's hybrid spokes, the hub's single routing VPC network must also be connected as a VPC spoke.

    • If you don't need to make propagated Private Service Connect connections available to on-premises networks through the hub's hybrid spokes, we recommend not configuring a routing VPC network as a VPC spoke so that the hub can support two or more routing VPC networks.

Comparison to VPC Network Peering

VPC spokes support medium to large enterprise requirements by:

  • Allowing you to control which IPv4 and IPv6 subnet routes are exported to the hub
  • Importing IPv4 and IPv6 subnet routes from the hub
  • Importing IPv4 and IPv6 (Preview) dynamic routes that hybrid spokes have exported to the hub
  • Allowing you to configure static routes with next hop internal passthrough Network Load Balancers in other VPC spokes

The following rules apply to a VPC spoke network that's connected to another VPC network using VPC Network Peering except for producer VPC spokes :

  • The other VPC network can't be connected to the NCC hub as a VPC spoke.
  • The VPC spoke network cannot export the peering subnet routes, that it imported from the other network, to the hub.
Feature VPC Network Peering VPC spokes
Number of VPC networks

Peerings per VPC network quota

Active VPC spokes per hub quota

Number of subnet ranges (subnet routes)

Subnet ranges per peering group quota

Subnet routes per route table quota

Number of dynamic routes

Dynamic routes per region per peering group quota

Unique dynamic route prefixes per hub route table per region quota

Number of static routes

Static routes per peering group quota

Static route exchange isn't supported, but you can Configure static routes with next hop internal passthrough Network Load Balancers in a different VPC spoke.

Export filters

Specific filters aren't supported; see Route exchange options in the VPC Network Peering documentation.

Supports both include export ranges and exclude export ranges. For more information, see Export filters and Export filter rules for VPC spokes.

Inter-VPC NAT

Private Service Connect endpoint propagation

Producer VPC spoke connectivity in other VPC networks

IP addressing

Internal IPv4 addresses, including private IPv4 addresses and privately used public IPv4 addresses. See Valid IPv4 ranges.

Internal and external IPv6 addresses.

Internal IPv4 addresses, including private IPv4 addresses and privately used public IPv4 addresses. See Valid IPv4 ranges.

Internal and external IPv6 addresses.
IP address families Supported configurations:
  • Exchange only IPv4 subnet ranges
  • Exchange both IPv4 and IPv6 subnet ranges
 Supported configurations:
  • Exchange only IPv4 subnet ranges
  • Exchange both IPv4 and IPv6 subnet ranges
  • Exchange only IPv6 subnet ranges
Performance and throughput (when compared to other VPC connectivity mechanisms)

Lowest latency, highest throughput (VM-VM equivalent).

Lowest latency, highest throughput (VM-VM equivalent).

VPC spokes in different projects

VPC spokes can be in either the NCC hub project or a different project. When a VPC spoke and an NCC hub are in different projects, the projects can be in either the same organization or different organizations.

  • A hub administrator creates and manages the NCC hub and accepts VPC spoke proposals.
  • A spoke administrator creates a proposal for a VPC network in a to join the hub as a VPC spoke.

For more information about hub administrators and spoke administrators, see:

When a spoke administrator creates a VPC spoke in the same project as the hub, NCC adds the VPC spoke immediately.

When a spoke administrator creates a VPC spoke in a project different from the NCC hub project, NCC creates a spoke proposal which a hub administrator must approve before the VPC spoke becomes active. For more information, see:

Spoke interaction with VPC Service Controls

NCC supports VPC Service Controls for cross project and organization spokes. For a spoke in a different project from the hub, when a new VPC Service Controls perimeter is added, you can't add new spokes that violate the perimeter. However, existing spokes that you added before adding the VPC Service Controls perimeter continue to function.

VPC connectivity with export filters

NCC lets you limit how other spokes can connect to a VPC spoke by using spoke filters. For detailed information about spoke filters, see Spoke filters overview. VPC spokes only support export filters.

Preset topologies

NCC lets you specify the connectivity configuration across all VPC spokes. You can choose one of the following two preset topologies:

For detailed information about connectivity topologies, see Preset connectivity topologies.

For detailed information about how to configure the mesh or star topology for your VPC spokes, see Configure a hub.

Limitations

This section describes the limitations of VPC spokes in general and when they are attached to a hub in a different project. These limitations also apply to producer VPC spokes.

Limitations of VPC spokes

  • You can't use VPC Network Peering between two VPC spokes that are also connected using an NCC hub. However, consider the following:
    • A producer VPC spoke requires a peering connection to a VPC spoke on the same hub. Connectivity through NCC isn't established between the producer VPC spoke and its peered VPC spoke.
    • You can have a NCC-connected VPC spoke that is peered through VPC Network Peering with a separate VPC that isn't a part of NCC.
    • You can use VPC Network Peering between two VPC spokes in the edge spoke group of a hub configured to use the star topology. This is because NCC doesn't connect spokes in the edge group to each other.
  • Static routes exchange across VPC spokes isn't supported.
  • IPv6-based internal passthrough Network Load Balancers aren't reachable among VPC spokes.
  • Auto mode VPC networks aren't supported as VPC spokes. You can switch from auto mode to a custom VPC network that lets you manually define subnet prefixes for each region in your VPC network. After the network is updated, you can't undo this action.

Cool-down period after deleting a VPC spoke

For a new spoke for the same VPC network attached to a different hub, you must wait for the cool-down period of at least 10 minutes. If the adequate cool-down period isn't allowed, the new configuration might not take effect. This cool-down period isn't needed if the VPC network is added as a spoke to the same hub.

Quotas and limits

When using dynamic route exchange, carefully monitor your usage of the number of dynamic routes per hub. This quota counts usage by destination (prefix) only, without regard to the priority or next hop of a dynamic route. When the usage of this quota exceeds its limit, NCC drops routes by destination. If a destination is dropped, then all dynamic routes with that destination—regardless of priority or next hop—are no longer sent to the hub.

For detailed quota information, see Quotas and limits.

Billing

The following sections outline details of billing for spoke hours and outbound traffic.

Spoke hours

Spoke hours are charged to the project where the spoke resource lives and follows the standard spoke hours pricing. Spoke hours are only charged when the spoke is in the ACTIVE state.

Outbound traffic

Outbound traffic is charged to the project of the spoke resource from which traffic originates. Pricing is the same regardless of whether traffic crosses project boundaries.

Service level agreement

For information about the NCC service level agreement, see Network Connectivity Center Service Level Agreement (SLA).

Pricing

For information about pricing, see NCC pricing.

What's next