VPC spokes overview

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

VPC spokes

Network Connectivity Center provides inter-VPC network connectivity at scale with the support for VPC spokes. VPC network spokes reduce the operational complexity of managing the individual pair-wise peering connections used in VPC network peering by enabling the use of a simpler centralized connectivity management model. VPC spokes export and import all IPv4 subnet routes from other spoke VPCs. This ensures full IPv4 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 Network Connectivity Center hub.

VPC spokes can be connected to one hub at a time.

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

Comparison to VPC Network Peering

VPC spokes are designed to support medium to large enterprise workload requirements for routed connectivity among IPv4 subnet ranges located in many distinct VPC networks.

A VPC network can be both a Network Connectivity Center VPC spoke and be connected to other VPC networks by using VPC Network Peering. However, subnet routes that the spoke VPC network imports by using VPC Network Peering are not shared with other VPC spokes that are connected to the Network Connectivity Center hub. Consequently, managed services that are powered by Private services access are not transitively reachable by using other VPC spokes of a Network Connectivity Center hub.

Feature VPC Network Peering VPC spokes
VPC networks

Up to 25 (requires lowering other VPC quotas)

Up to 250 active VPC spokes per hub

VM instances

Instances per peering group

Network Connectivity Center supports up to the maximum per VPC network (no separate peering groups quotas needed).

Subnet ranges (subnet routes)

Subnetwork ranges per peering group

Subnetwork routes per route table

Static and dynamic routes

Static routes per peering group

Dynamic routes per region per peering group

Static and dynamic route exchange is not supported.

Export filters

Specific filters are not supported; see Route exchange options in the VPC Network Peering documentation.

Up to 16 CIDR ranges supported per VPC spoke.

IP addressing

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

Private IPv4 internal addresses only, excluding privately used public IPv4 addresses. See Valid IPv4 ranges.

IP address families

IPv4 and IPv6/IPv4 dual stack addresses

IPv4 addresses only

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 a different project from a hub

By using Network Connectivity Center, you can attach VPC networks, represented as spokes, to a single hub in a different project, including a project in a different organization. This lets you connect your VPC networks across multiple projects and organizations together at scale.

You can be one of the following types of users:

  • A hub administrator who owns a hub in one project
  • A VPC network spoke administrator or network administrator who wants to add their VPC network in a different project as a spoke to the hub

The hub administrator controls who can create a VPC spoke in a different project associated with their hub by using Identity and Access Management (IAM) permissions. The VPC network spoke administrator creates a spoke in a different project from the hub. These spokes are inactive upon creation. The hub administrator must review them, and can either accept or reject the spoke. If the hub administrator accepts the spoke, it becomes active.

Network Connectivity Center always automatically accepts spokes created in the same project as the hub.

For detailed information about how to manage hubs that have VPC spokes in a different project than the hub, see Hub administration overview. For detailed information for spoke administrators, see Spoke administration overview.

VPC connectivity with export filters

Network Connectivity Center lets you limit the connectivity of all spoke VPC networks to only a subset of subnetworks in the spoke VPC. You can keep an IP address range from being advertised by using the exclude-export-ranges flag in Google Cloud CLI or the excludeExportRanges field in the API. Any subnetworks that match the specified range are excluded from being exported to the hub. This filtering is useful when you have subnets that need to be private within the VPC network, or might overlap with other subnets in the hub route table.

Limitations

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

Limitations of VPC spokes

  • Network Connectivity Center hubs don't support VPC spokes with VPN, Cloud Interconnect, and Router appliance spokes on the same hub.
  • VPC networks can connect with each other in an exclusive manner through either the Network Connectivity Center hub or through VPC Network Peering. You cannot use VPC Network Peering between two VPC spokes that are connected to the same Network Connectivity Center hub. However, you can have a Network Connectivity Center-connected VPC spoke that is peered through VPC Network Peering with a separate VPC that is not a part of Network Connectivity Center.
  • VPCs connected together by using Network Connectivity Center and VPC-peered VPCs in any combination are not transitive.
  • IPv4 static and dynamic routes exchange across VPC spokes are not supported.
  • Routes pointing to internal passthrough Network Load Balancer virtual IP addresses in other VPC spokes are not supported.
  • Overlapping subnets must be masked by export filters.
  • At the most, 16 exclude export range filters can be specified per spoke.
  • Update of export range filters after VPC spoke creation is not supported.
  • For a spoke in a different project from the hub, when a new VPC Service Controls perimeter is added, you cannot add new spokes that violate the perimeter, but existing spokes continue to function.

Cool-down period requirements after deleting a VPC spoke

This section lists the required cool-down period between deleting a VPC spoke and creating a new spoke for the same VPC. If the adequate cool-down period is not allowed, the new configuration might not take effect.

  • After you delete a spoke, you must wait for a cool-down period of at least 10 minutes before creating a new spoke for the same VPC network attached to the same hub.
  • 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 24 hours.
  • It is possible that the spoke creation for the same VPC network might not have its filters applied properly. The workaround is to delete the spoke, wait for a longer period of time, and then recreate the spoke.

Quotas and limits

The following quotas and limits apply:

  • Number of VPC spokes per project: (suggested) 1,000
  • Number of active VPC spokes per hub: 250
  • Total number of VPC spokes per hub: 1,000
  • Number of subnet routes per route table: 1,000
  • Number of export filters per VPC spoke: 16

Billing

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 Network Connectivity Center service level agreement, see Network Connectivity Center Service Level Agreement (SLA).

Pricing

For information about pricing, see Network Connectivity Center pricing.

What's next