GCP ACE: Every Way to Connect a Network to Google Cloud

Google Cloud gives you four different answers to the same question: “how do I connect this VPC to something else?” The “something else” can be another VPC, another project, or a network outside Google Cloud entirely, and that distinction is what decides which tool you reach for. This post covers all four, maps to the interconnecting-networks section of the ACE exam guide, and ends with the gcloud commands to actually build an HA VPN connection end to end.

The four ways to connect

• VPC Network Peering: connects two separate VPC networks (yours or someone else’s) so resources can talk over Google’s internal network, without encryption and without touching the public internet.
• Shared VPC: not a connection between two networks — a single VPC network shared by multiple projects, so they don’t need peering between them at all.
• Cloud VPN: an encrypted IPsec tunnel over the public internet, connecting your VPC to a network outside Google Cloud (on-premises, another cloud, a remote office).
• Cloud Interconnect: a physical, dedicated connection between your infrastructure and Google’s network, bypassing the public internet entirely.

VPC Network Peering

VPC Network Peering connects two VPC networks so that resources in each can reach each other using internal IP addresses, as if they were on the same network — while remaining two administratively separate networks. Neither side gains access to the other’s project, IAM, or firewall policies; peered networks exchange routes only, based on what each administrator chooses to export and import.

Key behaviors to know cold for the exam:

• Peering is not transitive. If network-a peers with network-b, and network-b peers with network-c, network-a cannot reach network-c. Full-mesh connectivity between more than two networks means a direct peering connection between every pair.
• Subnet IP ranges can’t overlap. Google Cloud checks for overlapping ranges at peering time and the peering fails if any exist. The same check applies later if a new subnet route would create an overlap.
• Firewall rules and routes aren’t shared automatically. You still need firewall rules on both sides allowing the peer’s ranges, and each side controls its own route exchange settings.
• Internal DNS doesn’t resolve by default. A VM’s internal DNS name isn’t resolvable from a peered network unless you set up Cloud DNS peering zones.
• Peering requires consent from both sides. Either network can create, update, or delete the peering connection independently (in the default “Independent” mode).
• Default quota: 25 peering connections per VPC network, adjustable via a quota increase request.

# From network-a, peer with network-b
gcloud compute networks peerings create peer-a-to-b \
  --network=network-a \
  --peer-network=network-b

# From network-b, peer back with network-a (required — peering is two-sided)
gcloud compute networks peerings create peer-b-to-a \
  --network=network-b \
  --peer-network=network-a

Use VPC Peering when two independently managed VPCs (different teams, different projects, sometimes different organizations) need direct, low-latency, no-encryption-needed connectivity and you don’t want to centralize them into one network.

Shared VPC

Shared VPC solves a different problem: instead of connecting two networks, it lets one VPC network live in one project and be used by resources in other projects.

• The project that owns the network is the host project.
• Projects attached to it are service projects.
• Resources created in a service project (VMs, GKE clusters, etc.) can use subnets from the host project’s VPC, getting internal IPs from that same network — no peering connection needed between service projects, because they’re all using the same network.
• A project can be a host project or be attached to a host project, but a service project can only be attached to a single host project at a time.
• IAM is granted separately: an org admin enables Shared VPC on the host project, and a Shared VPC Admin grants specific service projects (or specific subnets within the network) to specific teams, so network administration stays centralized while compute/resource management stays decentralized.

The practical difference from peering: with Shared VPC there’s one network, many projects. With peering there’s many networks, each kept separate, bridged by routes. Shared VPC is the common pattern for a company with centralized network/security teams and several product teams each working in their own project.

Cloud VPN

Cloud VPN connects your VPC to a peer network over an encrypted IPsec tunnel that travels across the public internet. It cannot be used to reach the public internet itself — only for private network-to-network communication (on-premises, another cloud, or another VPC via two Cloud VPN instances).

Classic VPN vs HA VPN

Google recommends HA VPN for all new deployments; Classic VPN is legacy.

The pieces you actually create

1. Cloud Router — a managed service that speaks BGP (Border Gateway Protocol) with the peer side, automatically exchanging which subnets are reachable through which tunnel, instead of you maintaining static routes. Requires an ASN (a private ASN in the 64512–65534 or 4200000000–4294967294 ranges if you don’t bring your own); the ASN applies to every BGP session on that router and can’t be changed later. One Cloud Router can serve multiple tunnels and both gateway interfaces.
2. HA VPN Gateway — your side, created inside a VPC and region. Google automatically assigns two external IP addresses (one per interface) from a pool chosen to support high availability.
3. External VPN Gateway (peer gateway) — the Google Cloud representation of the device on the other end (your on-prem firewall, or another cloud’s gateway). It’s metadata only: you tell Google the peer’s external IP address(es).
4. VPN Tunnel — the actual IPsec connection between one HA VPN Gateway interface and the external VPN gateway, created with a pre-shared key and linked to a Cloud Router.
5. BGP session — configured per tunnel on the Cloud Router: a Cloud Router interface plus a BGP peer entry (peer ASN, and BGP IPs from the 169.254.0.0/16 link-local range if assigned manually).
6. Firewall rules — ingress rules allowing traffic from the ranges learned via BGP. A tunnel reporting “Established” with no traffic flowing is almost always a missing firewall rule.

Bandwidth limit

Each Cloud VPN tunnel (Classic or HA) is capped at 250,000 packets per second for the sum of ingress and egress — roughly 1–3 Gbps depending on average packet size. If you need more throughput, the answer is more tunnels, not a bigger tunnel — distribute traffic across several tunnel pairs, or across several HA VPN gateways if you need distinct IPs per tunnel.

Building it with gcloud

# 1. Cloud Router with a private ASN
gcloud compute routers create router-a \
  --region=europe-west1 \
  --network=network-a \
  --asn=65001

# 2. HA VPN gateway — Google auto-assigns two external IPs
gcloud compute vpn-gateways create ha-vpn-gw-a \
  --network=network-a \
  --region=europe-west1

# 3. External (peer) VPN gateway representing the on-prem device
gcloud compute external-vpn-gateways create peer-gw \
  --interfaces 0=203.0.113.1,1=203.0.113.2

# 4. Two VPN tunnels, one per HA VPN gateway interface
gcloud compute vpn-tunnels create tunnel-if-0 \
  --peer-external-gateway=peer-gw \
  --peer-external-gateway-interface=0 \
  --region=europe-west1 \
  --ike-version=2 \
  --shared-secret=REPLACE_WITH_STRONG_SECRET \
  --router=router-a \
  --vpn-gateway=ha-vpn-gw-a \
  --interface=0

gcloud compute vpn-tunnels create tunnel-if-1 \
  --peer-external-gateway=peer-gw \
  --peer-external-gateway-interface=1 \
  --region=europe-west1 \
  --ike-version=2 \
  --shared-secret=REPLACE_WITH_STRONG_SECRET \
  --router=router-a \
  --vpn-gateway=ha-vpn-gw-a \
  --interface=1

# 5. Router interfaces + BGP peers, one pair per tunnel
gcloud compute routers add-interface router-a \
  --interface-name=if-tunnel-0 \
  --vpn-tunnel=tunnel-if-0 \
  --region=europe-west1

gcloud compute routers add-bgp-peer router-a \
  --peer-name=bgp-peer-0 \
  --peer-asn=65002 \
  --interface=if-tunnel-0 \
  --region=europe-west1

gcloud compute routers add-interface router-a \
  --interface-name=if-tunnel-1 \
  --vpn-tunnel=tunnel-if-1 \
  --region=europe-west1

gcloud compute routers add-bgp-peer router-a \
  --peer-name=bgp-peer-1 \
  --peer-asn=65002 \
  --interface=if-tunnel-1 \
  --region=europe-west1

For the 99.99% SLA, both tunnels must be configured and active — a single-interface HA VPN gateway still works, but drops to no availability SLA.

Cloud Interconnect

Cloud Interconnect replaces the public-internet path of Cloud VPN with a physical connection between your infrastructure and Google’s network. Traffic never touches the public internet, which means lower and more predictable latency and no IPsec encryption overhead (though you can layer HA VPN over an Interconnect connection if you need encryption too).

Dedicated Interconnect vs Partner Interconnect

Both options use VLAN attachments to split a physical circuit into logical connections, each tied to one VPC network and one region. Both rely on a Cloud Router for BGP, exactly like Cloud VPN does.

Choosing a connection

Work through it in this order:

1. Is it two Google Cloud VPCs, or Google Cloud to something external? Two VPCs → Peering (or Shared VPC if you control both and want one network instead of two). External → VPN or Interconnect.
2. Do you need it encrypted, or is it already on a private physical path? VPN encrypts over the public internet. Interconnect doesn’t need to, because it doesn’t use the public internet.
3. How much bandwidth, how consistently? A few Mbps to a few Gbps, intermittent or as a backup → Cloud VPN. Sustained high throughput (tens or hundreds of Gbps) → Dedicated or Partner Interconnect.
4. Do you have colocation access? Yes, and you need maximum control → Dedicated Interconnect. No, or you want a provider to handle the physical layer → Partner Interconnect.
5. Is this a proof of concept, a backup path, or non-critical? Cloud VPN is the fastest and cheapest to stand up, and it’s commonly paired as a backup to an Interconnect connection.

Exam-relevant takeaways

• VPC Peering connects two VPC networks over Google’s internal network, unencrypted, and is not transitive: A-B and B-C peering does not give A reachability to C.
• Peering doesn’t share firewall rules or IAM — each network administers its own; routes are the only thing exchanged, and subnet ranges can’t overlap.
• Default quota is 25 peering connections per VPC network, adjustable.
• Shared VPC is not a connection between networks — it’s one VPC network (owned by a host project) used by multiple service projects, avoiding the need for peering between those projects.
• Classic VPN: 1 interface, 99.9% SLA, static or BGP routing, no IPv6. HA VPN: 2 interfaces, 99.99% SLA (only with tunnels active on both), BGP required, IPv6 supported.
• Cloud VPN tunnel bandwidth is capped at 250,000 pps (~1–3 Gbps); scale by adding tunnels, not by expecting a single tunnel to go faster.
• Cloud Router requires a private ASN and handles BGP automatically — this is what Google pushes you toward instead of static routes.
• Dedicated Interconnect: physical cross-connect, 10 Gbps or 100 Gbps circuits, up to 8 circuits, VLAN attachments from 50 Mbps to 100 Gbps.
• Partner Interconnect: via a service provider, no colocation needed, VLAN attachments from 50 Mbps to 50 Gbps.
• Cloud VPN and Cloud Interconnect can be combined (HA VPN over Cloud Interconnect) when you need both a dedicated physical path and encryption.
• None of these hybrid connectivity options route traffic to the public internet — they’re all for private network-to-network communication.

Source

↗ Google Cloud: VPC Network Peering ↗ Google Cloud: Shared VPC overview ↗ Google Cloud: Cloud VPN overview ↗ Google Cloud: Create an HA VPN gateway to a peer VPN gateway ↗ Google Cloud: HA VPN topologies to increase bandwidth ↗ Google Cloud: Network Connectivity quotas and limits ↗ Google Cloud: Cloud Interconnect terminology ↗ Google Cloud: Choosing a Network Connectivity product

↗ LinkedIn