Network Connectivity Center (NCC) is a Google Cloud service for building centralized network topologies like hub-and-spoke (star) and mesh. An NCC hub acts as a central transit gateway, and spokes (like VPC networks or hybrid connections) attach to it. This structure simplifies managing connectivity and route propagation across complex, multi-cloud deployments by providing a single control point.
When you create an NCC hub in a project, it becomes a central point for managing routing information between attached spokes. The hub itself does not forward user data packets. Instead, it manages the exchange of routing information, enabling spokes to communicate directly with each other. This model is ideal for creating a transit VPC, where the hub facilitates connectivity between many spoke VPCs and on-premises networks without requiring direct connections between every pair.
A VPC spoke is a VPC network attached to an NCC hub. Upon attachment, the hub automatically learns the subnet routes from that VPC. The hub can then propagate these routes to other attached spokes based on your policies. This dynamic propagation allows a spoke VPC to reach the IP ranges of other spokes without needing manual peering. You can use export filters on the hub to control exactly which routes from a spoke are advertised, enabling traffic isolation and segmentation within the overall topology.
VPC Network Peering creates a direct connection between two VPCs, but it does not support transitive routing—a VPC peered with two others cannot act as a transit path between them. NCC hubs explicitly enable this transitive routing between VPC spokes. NCC also scales better for large deployments, supporting up to 250 active VPC spokes per hub and avoiding the per-VPC instance limits of peering groups. A trade-off is that NCC offers limited options for inserting Network Virtual Appliances (NVAs) for traffic inspection, and inter-VPC transit traffic incurs standard data transfer costs.
NCC hubs can integrate hybrid connections like Cloud VPN tunnels and Cloud Interconnect attachments as spokes. This allows on-premises networks to reach all VPC spokes connected to the same hub. Routes learned from on-premises networks via BGP can be propagated by the hub to VPC spokes, and vice-versa. You can also attach third-party Router Appliances (NVAs) as spokes. This enables advanced routing, filtering, or security inspection for traffic flowing between other spokes through the hub's routing framework.
NCC supports a hub-administrator to spoke-administrator workflow, which is valuable for cross-organizational connectivity. A central network team can own the hub and grant permissions for other teams or external organizations to attach their networks as spokes. This decentralizes the management of individual spokes while maintaining central oversight over the transit routing policy. Spoke attachments can be created, updated, or deleted independently, and the hub's routing table updates dynamically as spokes change.
Private Service Connect (PSC) enables private, granular connectivity between a service consumer and a service producer without exposing traffic to the public internet. PSC creates a private IP address endpoint inside a consumer's VPC that maps directly to a specific service, keeping all traffic within Google's private network for predictable performance and enhanced security.
A PSC implementation involves three primary components. The service producer owns the service being offered, such as Apigee or a custom application. The service consumer is the VPC network or project that wants to access the service. The service attachment is the producer's defined attachment point that consumer VPCs use to connect. Consumers connect using either a service endpoint (a private IP in their VPC) or a PSC backend (which uses a network endpoint group with a load balancer for features like logging and Cloud Armor).
When publishing a service using PSC, the producer creates a service attachment that defines how consumers can connect. For managed services like Apigee, this attachment is created automatically. Consumers then create PSC endpoints or backends that reference this service attachment's URI. The producer controls access via a consumerAcceptList; only projects on this list can create PSC connections, providing a security boundary.
PSC provides strong isolation benefits compared to VPC Network Peering. Unlike peering, which creates a broad network-level connection and exchanges all subnet routes, PSC connects at the service level. This avoids IP address overlap issues that occur when trying to peer networks with overlapping RFC 1918 address ranges. Traffic remains within Google's network, and you can create firewall rules that allow egress traffic exclusively to the PSC endpoint IP, denying all other egress for enhanced security.
Producer network administrators can secure PSC interfaces by controlling ingress traffic from consumer networks. Using iptables on the PSC interface's VM, you can block consumer-initiated ingress while allowing egress and reply traffic from the producer network. This ensures consumer workloads cannot initiate traffic to VMs in the producer network. To prevent users from creating PSC interfaces, administrators can use IAM to create custom roles that omit the specific compute.instances.pscInterfaceCreate permission.
Choose PSC when you need to avoid IP address conflicts, require granular security controls at the service level, or want to reduce administrative overhead. VPC Network Peering is appropriate when you need to insert network virtual appliances (NVAs) or when your application does not support PSC. Peering connections are bidirectional by default, while PSC connections are unidirectional (inbound-only) unless additional configuration is applied. For multi-VPC scenarios, NCC can propagate PSC endpoint reachability across VPC spokes, enabling transitive connectivity while maintaining PSC's isolation benefits.
Virtual Private Cloud (VPC) Network Peering establishes direct internal IP connectivity between two VPC networks across projects and organizations. This peering operates without routing traffic over the public internet. Routing becomes bi-directional once each side configures a symmetrical peering resource. A strict requirement is that subnet IP address ranges between peered VPCs must not overlap.
VPC Network Peering allows workloads in separate VPCs to communicate using private IPv4 and IPv6 addresses. Establishing a connection requires an administrator with appropriate permissions (like the Compute Network Admin role) in each project. The peering remains inactive until both networks define a configuration pointing to the opposite network's project ID and name. Google Cloud strictly forbids peering between VPCs that have overlapping subnet CIDR prefixes. Once both configurations exist and ranges do not conflict, the state transitions to ACTIVE.
Route exchange controls determine which routes propagate across a VPC Network Peering boundary. By default, only private IPv4 subnet routes (RFC 1918) are exchanged. To propagate dynamic and static custom routes, the source VPC must enable the --export-custom-routes flag, and the destination must enable --import-custom-routes. Exchanging subnet routes that use privately used public IPv4 addresses requires matching --export-subnet-routes-with-public-ip and --import-subnet-routes-with-public-ip settings. For dual-stack networks, both IPv4 and IPv6 routes can be exchanged by setting the stack type to IPV4_IPV6 on both sides.
Connection update modes control whether configuration changes require mutual approval. In the default INDEPENDENT mode, an administrator can update flags or delete the local configuration without peer confirmation, immediately dropping the remote connection into an INACTIVE state. In CONSENSUS mode, updating route parameters or requesting deletion requires explicit acknowledgment from the peer administrator. During this process, the initiating network shows an update status of PENDING_PEER_ACKNOWLEDGMENT while the peer shows PENDING_LOCAL_ACKNOWLEDGMENT. Once confirmed, the status transitions to IN_SYNC, and deletions similarly require mutual agreement.
The main difference is that NCC hubs enable transitive routing, meaning a VPC spoke attached to a hub can route traffic to other spokes through the hub. VPC Network Peering is non-transitive; a VPC peered with two others cannot act as a transit path between them.
Use PSC when you need to avoid IP address conflicts between networks, require granular security controls at the service level, or want to reduce administrative overhead. Use VPC Network Peering when you need to insert network virtual appliances (NVAs) for inspection or when your application does not support PSC.
By default, VPC Network Peering only exchanges private IPv4 subnet routes (RFC 1918 addresses). To exchange custom routes (dynamic or static), both the exporting VPC must enable --export-custom-routes and the importing VPC must enable --import-custom-routes.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts