Google Cloud Hybrid Connectivity: Connect Data Centers, Branches, and Cloud Networks (Part 5)

Moving an application to Google Cloud does not mean every dependency moves with it. A cloud application might still need an on-premises database, a branch-office system, or a service in another cloud.

Hybrid connectivity provides the connection between these environments. Four capabilities work at different layers:

Capability	Main responsibility	Practical example
Cloud VPN	Establish encrypted connections between networks	Connect a data center to a VPC
Cloud Interconnect	Provide private connectivity with higher-capacity options	Transfer large volumes between a data center and Google Cloud
Cloud Router	Exchange routes dynamically using BGP	Advertise cloud subnets and learn on-premises routes
Network Connectivity Center	Organize supported connections in a hub-and-spoke model	Manage connectivity across VPCs and enterprise sites

The examples below are illustrative designs.

1. Cloud VPN — Connect private networks through encrypted tunnels

Cloud VPN provides site-to-site IPsec connectivity. It encrypts traffic between a Google Cloud VPN gateway and a compatible peer gateway.

HA VPN uses dynamic routing through BGP and Cloud Router. Its availability commitment depends on the configured topology and redundancy. Cloud VPN is not a remote-access VPN for individual laptops.

Practical example: a cloud application accesses an on-premises API

The diagram shows redundant paths conceptually. Validate the actual gateway, tunnel, and peer-device topology against Google’s supported designs.

Suggested hands-on workflow

1. Plan non-overlapping network ranges.
2. Verify the peer gateway’s IPsec and BGP compatibility.
3. Create an HA VPN gateway and Cloud Router.
4. Configure tunnels and BGP sessions on both sides.
5. Verify advertised and learned routes.
6. Permit the required application traffic.
7. Test connectivity and controlled failover.

Interview question: The tunnel is established, but the application cannot connect. What do you check?

I check BGP status, routes in both directions, overlapping addresses, firewall rules, DNS, the destination port, and whether the application is listening.

Common mistake: Assuming an established tunnel proves application connectivity.

2. Cloud Interconnect — Connect through private network paths

Cloud Interconnect provides connectivity that avoids the public internet.

Common options include:

Option	Connection model
Dedicated Interconnect	Direct connection between your network and Google’s network at a supported location
Partner Interconnect	Connectivity through a supported service provider
Cross-Cloud Interconnect	Dedicated connectivity between Google Cloud and another supported cloud

Private connectivity does not mean traffic is encrypted by default. Evaluate supported encryption options, such as HA VPN over Interconnect, against your requirements.

Practical example: large-scale data synchronization

An enterprise synchronizes substantial data between its data center and Google Cloud.

The dotted connections represent routing control, rather than application traffic.

Implementation considerations

• Required capacity and expected growth.
• Provider or colocation availability.
• Redundant connections and locations.
• VLAN attachments and route advertisements.
• Encryption, monitoring, and failover testing.

Interview question: When would you choose Interconnect over VPN?

I evaluate Interconnect when capacity, private-path requirements, or traffic characteristics justify it. VPN can suit smaller requirements or an appropriately designed backup path.

Common mistake: Purchasing one connection and treating it as a resilient production architecture.

3. Cloud Router — Exchange routes dynamically

Cloud Router is a managed, regional routing-control service. It uses Border Gateway Protocol (BGP) to exchange routes with peer routers for supported connectivity services.

It is not a VM appliance through which application packets pass. Google’s networking infrastructure forwards traffic using the resulting routes.

Practical example: advertise cloud and data-center subnets

Suppose the cloud subnet is 10.20.0.0/24 and the data-center subnet is 172.20.10.0/24

These addresses are examples; plan ranges around your actual environment.

Read-only investigation command

gcloud compute routers get-status ROUTER_NAME \
  --region=REGION \
  --project=PROJECT_ID

Inspect session status and advertised or learned routes.

Interview question: BGP is established, but the expected subnet is missing. Why?

I inspect route advertisements, peer filters, learned-route configuration, and the VPC’s dynamic routing mode. An established BGP session does not guarantee every required prefix is exchanged.

Common mistake: Assuming all learned routes are usable across every region regardless of routing configuration.

4. Network Connectivity Center — Organize connectivity at scale

Network Connectivity Center, or NCC, uses a hub-and-spoke model to manage supported network connections. Depending on the design, spokes can represent VPC networks or supported hybrid resources such as VPN tunnels and VLAN attachments.

NCC does not replace the underlying connections or remove the need for firewall and routing configuration.

Practical example: connect enterprise sites and cloud networks

This is a logical management diagram. Traffic follows supported network paths; it does not traverse a central “hub VM.”

Suggested setup workflow

1. Define which networks must communicate.
2. Select supported spoke types and topology.
3. Create the hub.
4. Attach and approve spokes as required.
5. Configure route propagation or exchange.
6. Apply firewall controls.
7. Verify intended connectivity and isolation.

Interview question: How is NCC different from VPC Peering?

Peering connects pairs of VPC networks and is non-transitive. NCC provides hub-and-spoke connectivity management with supported route-exchange capabilities. I evaluate topology and isolation requirements before choosing.

Common mistake: Assuming every spoke automatically communicates with every other spoke.

How the four capabilities work together

Layer	Capability	What to verify
Connection	VPN or Interconnect	Tunnel or attachment status and capacity
Route exchange	Cloud Router	BGP sessions and prefixes
Topology management	NCC	Spoke configuration and route propagation
Traffic permission	Firewall policies	Required source, destination, protocol, and port
Application access	DNS and application controls	Name resolution, listener, authentication

A practical troubleshooting flow

For intermittent failures, also examine packet loss, MTU, saturation, route changes, and return-path behavior.

A useful interview answer

“I choose VPN or Interconnect based on connectivity, capacity, security, and availability requirements. Cloud Router exchanges routes through BGP, while NCC organizes supported connections at scale. I verify both network directions, firewall permissions, DNS, and application behavior, then test failover rather than assuming redundancy works.”