Network Connectivity Center (NCC) is a Google Cloud service that simplifies network connectivity across multiple VPC networks and on-premises environments using a hub-and-spoke management model. An NCC hub acts as a centralized control plane resource that manages routing policy, while connected networks and hybrid connections attach as spokes. Workload networks attach to the hub as VPC spokes, allowing them to exchange subnet routes with other spokes at line-rate VM performance. Hybrid connectivity resourcesâsuch as Dedicated Interconnect VLAN attachments, Partner Interconnect VLAN attachments, High Availability VPN tunnels, and Router appliance virtual machinesâattach to the hub as hybrid spokes. Shared VPC architectures integrate with NCC by attaching the host project's Shared VPC network directly as a VPC spoke. For dynamic route exchange to operate across regions, all participating VPC networks must have their dynamic routing mode set to global.
NCC supports two primary topology types for interconnecting networks: a mesh topology and a star topology. The choice between these topologies is an irreversible configuration made when creating the NCC hub. In a mesh topology, all connected workload VPC spokes require full, bidirectional communication with one another directly across Google's private network. In a star topology, workload VPC spokes remain isolated from each other while retaining direct access to a central group of central shared services and hybrid spokes. Spoke groups allow administrators to organize spokes within the hub into distinct routing domains to manage route propagation boundaries. In both topologies, data packets flow directly between source and destination workloads over Google's internal backbone without traversing a centralized data-plane appliance.
Hybrid connectivity with NCC uses Cloud Router instances running Border Gateway Protocol (BGP) to dynamically exchange routes between on-premises routers and cloud spokes. Cloud Routers deployed in a dedicated transit VPC establish external BGP sessions and advertise cloud subnet ranges to on-premises routers using custom route advertisements. Cloud Router interfaces use a Multi-Exit Discriminator (MED) metricâsuch as 100 on primary links for Equal-Cost Multi-Path (ECMP) load balancing, and a higher MED like 200 on secondary links for failoverâto steer ingress hybrid traffic. When dynamic route exchange is enabled on the NCC hub, dynamically learned BGP routes from hybrid spokes are automatically exported into the route tables of all attached VPC spokes. Subnet advertisements from cloud spokes back to on-premises environments can be controlled using include-export and exclude-export IP filters configured on the VPC spoke.
NCC significantly reduces operational overhead compared to traditional multi-VPC designs that rely strictly on VPC Network Peering or Cloud VPN tunnels. VPC Network Peering enforces non-transitive routing constraints, requiring dedicated peering connections and custom route propagation between every individual VPC and the hybrid entry point. Cloud VPN mesh topologies allow transitive routing, but data throughput is constrained by per-tunnel bandwidth limits and requires maintaining numerous individual IPsec connections. By deploying NCC, organizations establish a centralized hybrid transit point where routes propagate dynamically to all workload VPC spokes without the operational bottleneck of peering quotas. Traffic moving between cloud spokes or between on-premises sites and cloud workloads achieves full VM network bandwidth. NCC also supports site-to-site data transfer across hybrid spokes, allowing branch offices and data centers to transfer traffic securely across Google's private backbone.
A hub-and-spoke topology using VPC Network Peering connects each workload VPC directly to a central routing VPC. Traffic between these networks flows over Google's internal network, not the public internet, allowing VMs to communicate at their full bandwidth. However, VPC Network Peering is not transitive; this means the on-premises network and individual workload VPCs can only exchange traffic with the routing VPC, not directly with each other. To enable shared services, you must place them in the routing VPC or connect them using Cloud VPN. Each VPC also requires a Cloud NAT gateway for outbound internet access, and you must configure DNS peering and forwarding so on-premises systems can resolve names for workloads in the spoke VPCs.
An alternative hub-and-spoke topology uses Cloud VPN to overcome the limitations of VPC Network Peering. IPsec VPN tunnels connect each workload VPC to the routing VPC. Unlike VPC peering, Cloud VPN connections are transitive, allowing the on-premises network and spoke VPCs to reach each other through the routing hub, though this can be restricted by policy. The trade-off is that bandwidth between networks is limited by the total bandwidth of the VPN tunnels, not the full VM bandwidth. Each VPC still needs a Cloud NAT gateway, and DNS peering must be set up for cross-environment name resolution.
Network Connectivity Center provides a managed control plane for connecting VPCs in either a star (hub-and-spoke) or full mesh topology. Using a star topology prevents direct communication between workload VPCs, while a mesh topology allows it. Network Connectivity Center supports dynamic route propagation and transitive routing for Private Service Connect and many Google-provided services via producer spokes. It provides full bandwidth between VMs in peered networks. The routing VPC connects to on-premises via Cloud VPN or Cloud Interconnect. As with other architectures, each VPC requires Cloud NAT for internet egress and DNS peering for hybrid name resolution.
When choosing an architecture, evaluate the trade-offs between the three core methods. Network Connectivity Center offers full bandwidth and transitivity between workload VPCs. VPC Network Peering provides full bandwidth but no transitivity among spokes; it is required if you need to insert network virtual appliances in the path or if an application doesn't support Private Service Connect. Cloud VPN allows transitive routing but limits total bandwidth to the capacity of the VPN tunnels. A key limitation of VPC Network Peering is that it does not support transitive route announcements, which can be addressed by using Cloud VPN or Network Connectivity Center for certain paths.
For architectures requiring communication between spoke VPCs (inter-spoke connectivity), you can deploy a network virtual appliance or next-generation firewall in the routing VPC to act as a gateway. Alternatively, you can create multiple Shared VPC networksâfor example, separate ones for production and developmentâand then peer them to enable inter-VPC communication. For hybrid connectivity, you can use separate VPN tunnels or VLAN attachments for each VPC network, or use separate attachments on the same Dedicated Interconnect connection. To scale a hub-and-spoke design with many VPCs, you can configure centralized hybrid connectivity in a dedicated VPC and add all VPC spokes to a Network Connectivity Center hub, enabling route exchange.
Shared VPC is a Google Cloud feature that lets an organization connect multiple projects to a common VPC network so that resources in different projects can communicate securely using internal IP addresses. In a Shared VPC setup, one project serves as the host project and contains the VPC network and its subnets, while other projects called service projects attach to the host project and gain access to use those shared subnets for their workloads. The host project contains all the network infrastructure including the VPC network, subnets, routes, and firewall policies that will be available to attached service projects. Service project administrators can create and manage VM instances in the shared subnets, but they cannot modify the network configuration itself. This architecture enables network administrators to maintain centralized control over network resources while allowing application teams to deploy resources in the shared network without managing the network itself.
Shared VPC uses IAM to control who can access the shared network resources. A Shared VPC Admin has the authority to attach service projects to a host project and configure which subnets are available to each service project. The Shared VPC Admin can grant access to all subnets in the host project or restrict access to specific subnets using subnet-level permissions. Network and security administrators maintain control over the shared network through dedicated roles. A Network Admin can manage routes, VPN configurations, and routing settings, while a Security Admin can create and manage firewall rules. Service Project Admins in attached projects can create resources in the shared subnets but cannot modify network infrastructure, implementing the principle of least privilege for network administration.
When configuring Shared VPC, you decide which subnets to share with each service project. You can share all subnets in the host project with a service project, or you can restrict sharing to specific subnets for tighter security control. This flexibility allows organizations to dedicate different subnets to different service projects, or to share the same subnets between multiple service projects depending on the use case. Each subnet in a Shared VPC network is a regional resource with its own IP address range. Subnets must have non-overlapping IP ranges to avoid routing conflicts. When planning your IP address allocation, consider using custom mode VPC networks rather than auto mode networks, because auto mode networks use predetermined IP ranges that can conflict with on-premises networks or other VPC networks that need to communicate with each other.
Shared VPC networks can connect to on-premises data centers using several connectivity options. Cloud VPN provides IPsec VPN tunnels over the public internet for lower-bandwidth needs, while Dedicated Interconnect provides direct physical connections to Google's network at colocation facilities for higher throughput and reliability. Partner Interconnect offers connectivity through service providers when direct physical connection is not feasible. For high availability, organizations typically use HA VPN, which provides two interfaces with multiple tunnel support and can achieve a 99.99% availability SLA. Cloud Router manages dynamic routing between the VPC network and on-premises networks using BGP, automatically exchanging route information and applying learned routes as custom dynamic routes in the VPC network.
VPC Network Peering enables direct communication between separate VPC networks using internal IP addresses, with traffic traveling over Google's internal network rather than the public internet. Unlike Shared VPC, VPC Network Peering does not provide centralized network administrationâall peered networks retain their own IAM policies and administrative controls. The key difference is that VPC Network Peering connections are not transitive. If VPC A is peered with VPC B, and VPC B is peered with VPC C, traffic cannot flow from VPC A to VPC C through VPC B. Shared VPC avoids this limitation because all service projects share the same VPC network. Choose VPC Network Peering when you need to connect isolated VPC networks that must remain under separate administrative control, and choose Shared VPC when you want centralized network management with transitive connectivity.
Network Connectivity Center provides a hub-and-spoke model for managing connectivity among multiple VPC networks and on-premises networks. The hub serves as a central management point, reducing operational complexity by consolidating connectivity management. Spokes can be VPC networks, VLAN attachments for Dedicated Interconnect, VPN connections, or router appliances. Network Connectivity Center supports both full-mesh and star topologies. In a full-mesh configuration, all VPC networks can communicate directly with each other through the hub. In a star topology, spoke networks can communicate with the hub and with each other through the hub, but traffic between spokes must traverse the hub. This decision is made when creating the hub and cannot be changed afterward.
When a Shared VPC network connects to on-premises infrastructure, the routing behavior depends on the dynamic routing mode of the VPC network. With regional routing, routes are advertised only to subnets in the same region as the Cloud Router. With global routing, which is the default for custom mode VPC networks, all subnets in the VPC are advertised to on-premises networks regardless of region, and on-premises routes are distributed to all regions. Cloud Router learns routes from on-premises BGP peers and applies them as custom dynamic routes in the VPC network. These routes are automatically propagated to all subnets in the VPC network when using global dynamic routing mode. This means that resources in any region can reach on-premises networks through the nearest Cloud Router, and traffic is distributed across available connections using equal-cost multi-path routing when multiple paths exist.
A transit VPC serves as a centralized connectivity hub that provides routing between on-premises networks and multiple workload VPC networks. In this architecture, the transit VPC hosts the hybrid connectivity (VPN or Interconnect) and routes traffic between external networks and the spoke VPC networks that contain workloads. This design centralizes the connectivity infrastructure so that each workload VPC does not need its own direct connection to on-premises. Workload VPC networks connect to the transit VPC using VPC Network Peering, HA VPN tunnels, or Network Connectivity Center spokes. Traffic from on-premises to workload resources flows through the transit VPC, which applies routing policies and can optionally pass through network virtual appliances for inspection. This architecture scales well because adding new workload VPCs only requires establishing a connection to the existing transit VPC rather than provisioning new hybrid connectivity for each workload.
NCC mesh topology allows all connected workload VPC spokes to communicate directly with each other across Google's private network. NCC star topology keeps workload VPC spokes isolated from each other while allowing each to access central shared services and hybrid spokes. The topology choice is made when creating the hub and cannot be changed later.
Use Shared VPC when you want centralized network management with transitive connectivity across projects, because all service projects share the same VPC network and can communicate with each other. Use VPC Network Peering when you need to connect isolated VPC networks that must remain under separate administrative control.
Global dynamic routing mode is required for dynamic route exchange to operate across regions in NCC. When enabled, all subnets in participating VPC networks are advertised to other spokes regardless of region, and routes learned from on-premises BGP peers are distributed to all regions.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts