Professional Cloud Network Engineer
VPC Network Peering establishes private, low-latency connectivity between Virtual Private Cloud (VPC) networks across projects and organizations within Google Cloud. It enables scalable communication without using external IP addresses or traversing the public internet. To design for scalability and hybrid connectivity, you must evaluate peering constraints, manage routing implications, and integrate peering with services like Cloud VPN or Cloud Interconnect to extend these private connections to on-premises or other cloud environments.
A scalable peering architecture organizes multiple VPC networks to manage growth and centralize control. Two primary patterns are the peering mesh and hub-and-spoke topology. In a peering mesh, every VPC network peers directly with every other VPC network, which provides the shortest path for traffic but becomes complex to manage as the number of networks grows. In a hub-and-spoke topology, a central hub VPC network peers with multiple spoke VPC networks, but the spokes do not peer directly with each other; all inter-spoke traffic must route through the hub. This centralizes network management and security policy enforcement but adds an extra hop for traffic between spokes, which can increase latency.
The choice between these topologies involves a tradeoff between complexity and control. A full mesh is simpler for a small number of networks but does not scale well. A hub-and-spoke is more scalable and easier to manage for many projects, as you can apply shared services like firewalls or NAT gateways in the hub VPC. However, it introduces a dependency on the hub VPC for all cross-spoke communication, making the hub a potential single point of failure or performance bottleneck.
VPC Network Peering provides private connectivity within Google Cloud, but hybrid connectivity extends this private network to on-premises data centers or other clouds using Cloud VPN or Cloud Interconnect. In a hub-and-spoke design, the hub VPC typically hosts the hybrid connectivity gateway. The Cloud VPN gateway or Cloud Interconnect attachment resides in the hub VPC, allowing on-premises networks to access all peered spoke VPCs through the hub. This centralizes the hybrid connection point, simplifying management and reducing the number of external connections you must provision and maintain.
Traffic flow in this integrated model follows a defined path. When an on-premises system communicates with a resource in a spoke VPC, the traffic first enters Google Cloud via the Cloud VPN tunnel or Interconnect VLAN attachment in the hub VPC. The hub's routing table then directs the traffic over the appropriate VPC Network Peering connection to the target spoke VPC. The return traffic flows symmetrically back through the same path. This design maintains a clear trust boundary, as the hub VPC acts as a central enforcement point for network and security policies governing all traffic between on-premises and cloud environments.
Shared VPC is a foundational principle for centralizing network management across multiple projects. It allows you to designate a single host project containing the shared VPC network, while service projects use subnets and resources from that shared network. When combined with VPC Network Peering, Shared VPC enables you to build large-scale, multi-project architectures with centralized control. For instance, you can create a hub VPC as a Shared VPC in a host project and peer it with other VPC networks (which may also be Shared VPCs) in other host projects.
This approach centralizes ownership of core networking components like firewall rules, routes, and hybrid gateways in the host project's Shared VPC, which is managed by a central networking team. Service project teams can then deploy their workloads into designated subnets without needing broad network permissions. For hybrid connectivity, the Shared VPC hub project owns the Cloud VPN or Cloud Interconnect resources, ensuring consistent policy application for all traffic entering or leaving the collective environment. The key decision is determining which projects host shared networks and which act as service projects, balancing administrative control with operational autonomy for different teams.
VPC Network Peering is a networking feature that enables private connectivity between two Virtual Private Cloud (VPC) networks in Google Cloud, allowing resources in each network to communicate using internal IP addresses without traversing the public internet. When you create a peering connection, the two VPC networks exchange subnet routes automatically, enabling seamless communication between instances in both networks. This approach is commonly used to connect networks belonging to different projects, different organizations, or different departments within the same organization, providing a secure and cost-effective way to enable inter-network communication.
To establish VPC Network Peering, you must create a peering configuration on both VPC networks involved in the connection, as the connection is only established when both sides have a matching configuration. The process involves creating a peering connection on the consumer network first, then creating a corresponding peering connection on the producer network; only then does the peering state change from INACTIVE to ACTIVE. You can create peering connections using the Google Cloud Console or the gcloud CLI, for example by running gcloud compute networks peerings create peering-cp --network=vpc-consumer --peer-network=vpc-producer --stack-type=IPV4_ONLY. Once the peering becomes ACTIVE, subnet routes and custom routes are exchanged between the networks according to your configuration.
A VPC Network Peering connection progresses through specific lifecycle states that indicate the status of the connection. The peering starts in an INACTIVE state when you create the first side of the peering, because the other VPC network does not yet have a matching configuration; this indicates that your network is not yet connected to the other one. When the other network creates a corresponding peering configuration, the state changes to ACTIVE in both networks, confirming that the connection is established and traffic can flow. Understanding these states is important for troubleshooting connectivity issues, as an INACTIVE peering means the networks cannot communicate despite having a partial configuration.
VPC Network Peering requires that the two VPC networks have non-overlapping CIDR ranges; if the IP address spaces overlap, the peering cannot be established because routing would be ambiguous. Google Cloud enforces this requirement to ensure that traffic can be properly routed between the networks without conflicts. Additionally, VPC Network Peering is non-transitive, meaning that if VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot reach VPC C through VPC B—each pair of networks must have a direct peering connection to communicate. These constraints are fundamental to how VPC Peering works and must be considered when designing your network architecture.
When VPC networks are peered, they always exchange subnet routes, which allows resources in each network to reach any subnet in the peer network. You can optionally configure the peering to import and export custom routes, which include both static routes you define and dynamic routes learned from Cloud Router; however, custom routes are only exchanged when both networks are configured to do so. Exporting custom routes is particularly important when you need to advertise routes to on-premises networks connected via Cloud VPN or Cloud Interconnect, so that the peer network can route traffic to your on-premises environment. The ability to control custom route exchange gives you flexibility in how traffic flows between peered networks and your broader infrastructure.
VPC networks are project-level resources with fine-grained, project-level IAM controls, including roles such as networkAdmin, securityAdmin, networkUser, and networkViewer. By default, IAM controls apply to all VPC networks within a project, meaning that anyone granted networkAdmin in a project can manage all VPC networks in that project. If you require independent IAM controls per VPC network, you should create the VPC networks in different projects, which provides isolation for security-sensitive or compliance-regulated environments. This architectural approach is common in large enterprises where different teams or business units need separate administrative control over their network resources.
When deciding how to connect VPC networks, you should consider VPC Network Peering when you need to insert network virtual appliances (NVAs) or when your application does not support Private Service Connect. VPC Network Peering is easy to configure and provides direct private connectivity between networks, making it suitable for scenarios where you need full control over traffic between VPCs. However, you should consider alternatives like Network Connectivity Center for hub-and-spoke topologies with up to 250 active spokes per hub, or Private Service Connect when you need more granular control over service endpoints. For connecting to Google-managed services like Cloud SQL or Dataproc, private services access (which uses VPC Network Peering under the hood) is often the recommended approach.
VPC Network Peering allows private connectivity across different Virtual Private Cloud (VPC) networks in Google Cloud by exchanging routes directly across the Andromeda software-defined network. While subnet routes are exchanged by default once peering is established, administrators must actively configure custom route import and export settings to control dynamic and static route propagation. Understanding how peering configurations, route policies, and firewall rules interact ensures secure and predictable network behavior between peered environments.
A VPC Network Peering connection requires matching configurations in both participating VPC networks before active communication and route exchange can begin. When an administrator creates a peering connection in a local network, its lifecycle state remains INACTIVE until the administrator of the peer network creates a reciprocal connection pointing back to the local network. Once both sides configure the peering, the lifecycle state transitions to ACTIVE, triggering an automatic exchange of all subnet routes between the two networks. Route propagation takes effect dynamically across the software-defined network, but dynamic route overlaps must be avoided because peering does not prevent route collisions between conflicting ranges.
Custom route import and export settings control whether static and dynamic routes propagate across a VPC Network Peering boundary. Peered VPC networks do not share custom static routes or dynamic routes learned from Cloud Router by default; both networks must explicitly opt in to the exchange. For traffic to flow using custom routes, the source VPC network must enable the Export custom routes flag, and the destination peer VPC network must enable the Import custom routes flag. When custom routes are updated or added in the exporting network, the importing network automatically learns and updates its local routing tables to reflect the changes.
VPC Network Peering is strictly non-transitive, meaning intermediate networks cannot forward traffic between two separate peered VPC networks. If network A peers with network B, and network B peers with network C, workloads in network A cannot reach network C through network B across the peering relationship alone. In architectures where on-premises traffic arrives at a hub VPC network via Cloud VPN or Cloud Interconnect, custom routes must be exported to the peered VPC network to extend private connectivity. If end-to-end routing is not supported transitively across peering hops, organizations must use intermediary services such as reverse proxy Compute Engine instances, Network Connectivity Center, or Private Service Connect (PSC).
Diagnosing peering connectivity failures requires validating route export states, active subnet allocations, and underlying firewall policies. If a private service endpoint or hybrid destination is unreachable, administrators must confirm that the appropriate static or dynamic route appears in the exported and imported routes views in the VPC Network Peering console. Lingering subnet routes can also occur when changing allocated IP address ranges in a private service connection, as old routes persist until all dependent resources are fully deprovisioned. Furthermore, because each peered network manages its own security boundary, administrators must configure ingress firewall rules or network firewall policies to explicitly permit incoming traffic, such as allowing Identity-Aware Proxy (IAP) access from 35.235.240.0/20 or allowing application traffic from the peer subnet ranges.
In a peering mesh, every VPC network peers directly with every other network, providing the shortest path but becoming complex to manage as the number of networks grows. In a hub-and-spoke topology, a central hub VPC peers with multiple spoke VPCs, and all inter-spoke traffic must route through the hub, which centralizes management but adds an extra hop and makes the hub a potential bottleneck.
To extend VPC Network Peering to on-premises networks, place the Cloud VPN gateway or Cloud Interconnect attachment in a hub VPC that peers with spoke VPCs. The hub VPC exports custom routes to the spoke VPCs, allowing on-premises traffic to reach the spokes through the hub. The hub VPC acts as a central enforcement point for hybrid connectivity.
A peering connection remains INACTIVE until the administrator of the peer VPC network creates a reciprocal peering configuration pointing back to your network. Once both sides have matching configurations, the state changes to ACTIVE. Verify that the peer network has created a corresponding peering connection with the correct network name and project details.
First, confirm that the peering state is ACTIVE on both sides. Then verify that the subnet CIDR ranges do not overlap and that custom routes are properly exported and imported if needed. Finally, check that ingress firewall rules or network firewall policies in the destination VPC network explicitly allow traffic from the source peer subnet ranges, and that no lingering old routes remain from previous configurations.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts