Overview
VPC Network Peering allows internal IP address connectivity across two Virtual Private Cloud (VPC) networks. This connection can exist between VPCs in the same project, different projects, or even different organizations. Traffic stays within Google’s private network, ensuring high security and low latency.
The Bridge Analogy
Imagine two separate private islands (VPCs). Usually, to send a package from one to the other, you’d have to use a public ferry (The Internet). VPC Peering is like building a private bridge directly between the two islands. Once the bridge is built, residents can walk across freely without ever touching public waters. However, you cannot use Island B’s bridge to get to Island C (Transitive Peering is not allowed).
Detail Elaboration
VPC Peering is a decentralized approach to networking. Unlike Shared VPC, where a host project controls the network, Peering connects independent networks. Each VPC retains its own firewall rules and administrative control.
- Latency: Peering offers the same latency as if the resources were in the same network.
- Security: Traffic is never exposed to the public internet.
- Billing: Egress traffic over peered networks is generally charged at the same rate as traffic within the same network, though cross-region costs still apply.
Core Concepts & Best Practices
Google Cloud recommends VPC Peering for organizations that need to connect services across different administrative boundaries while maintaining autonomy.
| Feature | VPC Peering | Shared VPC | Cloud VPN |
|---|---|---|---|
| Use Case | Connecting independent networks | Centralized network administration | Connecting to On-Prem/Other Clouds |
| IP Ranges | Must NOT overlap | Centrally managed | Must NOT overlap |
| Transitivity | No (A→B, B→C ≠ A→C) | Yes (all subnets in one VPC) | Yes (via Hub-and-Spoke) |
| Administration | Decentralized | Centralized (Host Project) | Hybrid |
Decision Matrix (If/Then)
- If you need to connect two VPCs with completely different owners… Then use VPC Peering.
- If you need to share a single network’s subnets with multiple projects… Then use Shared VPC.
- If you need VPC A to talk to VPC C through VPC B… Then use a Network Virtual Appliance or Cloud Router (Peering won’t work).
- If you have overlapping IP ranges… Then you cannot use Peering (consider Private Service Connect).
ACE Exam Tips
- Transitive Peering is a Lie: If VPC A peers with B, and B peers with C, A and C cannot communicate. This is a common distractor.
- Firewall Rules: Peering only connects the networks; you still need to configure firewall rules in each VPC to allow specific traffic.
- DNS: By default, peering does not share internal DNS names. You must enable “Export/Import custom routes” and configure DNS peering zones.
- IAM: To configure peering, you need the
compute.networks.addPeeringpermission on both networks.
Architecture Flow: VPC Peering
Key Concepts
Peering is bidirectional. Both sides must create a peering configuration pointing to the other to establish the link.
Common Pitfalls
Trying to peer networks with overlapping CIDR blocks will fail. Always plan your IP space before deployment.
Patterns
Hub-and-Spoke: Use a central VPC for shared services (like logging) and peer multiple “spoke” VPCs to it.