India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Google Cloud Networking: Shared VPC, Interconnect & Load Balancing
Google Cloud networking is the set of services that connect, segment and expose workloads: global VPCs with Shared VPC, Cloud Load Balancing, Cloud Interconnect, HA VPN, Cloud NAT, Network Connectivity Center and Private Service Connect. NTSPL designs IP plans, hybrid links from Indian offices, plants and data centres, and private access to managed services so traffic stays predictable, private and auditable.
Google Cloud services in scope
The Problem VPC and Shared VPC and Cloud Load Balancing Solve
Network problems on Google Cloud usually date from week one: a default VPC with auto-mode subnets that overlap the corporate 10.0.0.0/8 plan, a separate VPC per project stitched with peering until the non-transitive limits bite, and branch offices connected by single Classic VPN tunnels that drop every time an ISP flaps. Later, managed services such as Cloud SQL get private IPs from peered ranges nobody documented. Fixing this after 40 projects exist means re-addressing live workloads, so getting the IP plan, Shared VPC boundaries and hybrid topology right first is far cheaper.
NTSPL starts with an IP address management plan covering on-premises ranges, every planned region including asia-south1 and asia-south2, GKE pod and service ranges, and Private Service Connect endpoints. We then design Shared VPC host projects per environment, choose between Dedicated Interconnect, Partner Interconnect and HA VPN per site based on bandwidth and SLA, and use Network Connectivity Center where many sites or SD-WAN appliances must reach each other through Google's backbone.
When to Redesign Your Google Cloud Network Topology (and When a Simpler Setup Is Enough)
Signals that point to networking on Google Cloud
- Projects each have their own VPC and you are already managing more than 10 VPC peerings or have hit peering route limits.
- Branch offices or plants connect through single-tunnel VPNs and you have logged more than three connectivity outages in a quarter.
- Monthly hybrid traffic to or from Google Cloud exceeds roughly 20-30 TB, making Interconnect egress pricing worth modelling.
- Security review found VMs with external IPs or Cloud SQL instances reachable from 0.0.0.0/0 authorised networks.
- You run workloads in another public cloud and cross-cloud latency or egress is affecting data pipelines.
When a different approach is better
- A single small application in one project with no on-premises dependency does not need Shared VPC or Interconnect; one custom-mode VPC with Cloud NAT is enough.
- If the goal is user access to internal web apps rather than site connectivity, Identity-Aware Proxy or Chrome Enterprise Premium can replace VPN for users.
- Content delivery to end users is a Cloud CDN or Media CDN design, not an Interconnect problem.
Google Cloud Networking Building Blocks: Shared VPC, Load Balancing, Interconnect, HA VPN, Cloud NAT, NCC and PSC
| Service | Role in the architecture | Choose it when |
|---|---|---|
| VPC and Shared VPC | Global VPC networks with regional subnets, where a Shared VPC host project owns subnets, routes and firewall policies that service projects consume. | More than a few projects need common connectivity to on-premises and to each other under a central network team. |
| Cloud Load Balancing | Global and regional Application and Network Load Balancers, external and internal, with anycast IPs, managed certificates and Cloud Armor integration. | Services need a single global IP, cross-region failover, or private internal load balancing between tiers. |
| Cloud Interconnect (Dedicated, Partner, Cross-Cloud) | Private, high-throughput links into Google's network: Dedicated Interconnect in 10, 100 or 400 Gbps circuits, Partner Interconnect through a service provider from 50 Mbps upward, and Cross-Cloud Interconnect to other public clouds. | Sustained hybrid traffic exceeds what VPN tunnels handle comfortably or egress volume makes Interconnect pricing cheaper. |
| Cloud VPN (HA VPN) | IPsec tunnels over the internet using two interfaces and BGP via Cloud Router, with a 99.99% SLA when configured with redundant peer tunnels. | Branch sites, smaller offices or a backup path need encrypted connectivity within days, not months. |
| Cloud NAT | Managed, software-defined outbound NAT so VMs and GKE nodes without external IPs can reach the internet, with static or dynamic port allocation. | Workloads need outbound access to patch mirrors, partner APIs or licence servers without public IPs on any VM. |
| Network Connectivity Center | Hub-and-spoke connectivity management that joins VPN, Interconnect, router appliance and VPC spokes, enabling site-to-site and VPC-to-VPC routing through Google's network. | Many sites, SD-WAN appliances or VPCs need any-to-any connectivity without a mesh of individual peerings. |
| Private Service Connect | Private endpoints in your VPC for Google APIs, managed services such as Cloud SQL and AlloyDB, and producer services published by other teams or partners. | Services must be consumed privately across VPCs or organizations without peering or overlapping-IP conflicts. |
Hub-and-spoke Shared VPC with dual-metro hybrid connectivity
Hub-and-spoke Shared VPC with dual-metro hybrid connectivity
Users and partners reach services through a global external Application Load Balancer, while offices and plants connect over Partner or Dedicated Interconnect in Mumbai and Delhi with HA VPN as backup, all terminating on Cloud Routers in a Shared VPC host project. Service projects run workloads on subnets in asia-south1 and asia-south2, reach managed databases and partner services through Private Service Connect, and leave for the internet only through Cloud NAT.
Select any component
Hub-and-spoke Shared VPC with dual-metro hybrid connectivity: click any of its 10 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Network Engineering Decisions: IP Plan, Shared VPC Boundaries, Hybrid Link Selection and Egress Control
IP plan and subnet sizing
We reserve a non-overlapping /16 per region per environment from the corporate plan, carve /20 or /22 primary subnets for VMs, and allocate GKE pod ranges separately because a /14 pod range per cluster is easy to exhaust. Ranges for Private Service Access and PSC endpoints are documented up front. We never use auto-mode VPCs, because their 10.128.0.0/9 subnets collide with many Indian enterprise plans and cannot be shrunk later.
Shared VPC boundaries
One host project per environment, production and non-production, is the default; separating by business unit only makes sense where units have different regulators or network teams. Service projects receive compute.networkUser on specific subnets, not the whole host project. Where a team needs full independence or a partner must connect, we use Private Service Connect between VPCs instead of peering, avoiding transitive-routing surprises and IP overlap.
Interconnect, Partner Interconnect or HA VPN
HA VPN suits sites below roughly 1 Gbps sustained or as a backup path, and can be live in days. Partner Interconnect suits sites needing 200 Mbps to 10 Gbps where a service provider already reaches the premises. Dedicated Interconnect pays off from about 10 Gbps sustained or very high egress, but requires your router in a supported colocation facility. For 99.99% we build four VLAN attachments across two metros, typically Mumbai and Delhi.
Egress control and NAT design
No VM or node gets an external IP; outbound traffic leaves through Cloud NAT with reserved static IPs per region so partners and banks can allowlist exact addresses. We enable dynamic port allocation with a minimum of 64 and a maximum of 4,096 ports per VM, log NAT translation errors, and route Google API traffic through Private Google Access or PSC so it never consumes NAT ports at all.
Load balancer type and network tier
Public HTTP services use the global external Application Load Balancer on the Premium tier for anycast entry and cross-region failover between asia-south1 and asia-south2. Internal tier-to-tier traffic uses the regional internal Application Load Balancer for L7 routing or the internal passthrough Network Load Balancer for TCP and UDP such as SIP or MES protocols. Standard tier is considered only for cost-sensitive, single-region, non-latency-critical egress.
How NTSPL Builds a Shared VPC Landing Zone with Hybrid Connectivity
IP plan and organization guardrails
Agree the address plan with the on-premises network team and apply organization policies that block default networks, external IPs and unapproved regions.
Shared VPC host build
Create host projects per environment with subnets in asia-south1 and asia-south2, hierarchical firewall policies and subnet-level IAM for service projects.
Hybrid link provisioning
Order Partner Interconnect or Dedicated Interconnect circuits in Mumbai and Delhi, bring up HA VPN first as an interim path, then attach VLANs and tune BGP preferences.
Private service access and PSC endpoints
Publish PSC endpoints for Google APIs and managed databases, and migrate any peering-based private service access where overlap is a risk.
NCC hub and SD-WAN integration
Register Interconnect, VPN and router appliance spokes on a Network Connectivity Center hub where sites need any-to-any routing.
Failover and change validation
Pull one Interconnect metro in a maintenance window to prove VPN failover, and add Connectivity Tests to the network Terraform pipeline.
What you receive
Securing Google Cloud Networks: Cloud NGFW, VPC Service Controls and Private-Only Service Access
The network is where Google Cloud lateral movement and data exfiltration either succeed or fail. Typical gaps are permissive 0.0.0.0/0 ingress rules created for debugging, VMs with public IPs, and service accounts that can copy data to buckets in any project. NTSPL enforces hierarchical firewall policies that service projects cannot override, removes external IPs organization-wide, and containers data projects in VPC Service Controls perimeters with access levels for on-premises ranges.
- Hierarchical firewall policies with deny-by-default at the folder level, delegating only allow rules to projects
- Cloud NGFW with FQDN and geolocation objects for egress filtering, plus intrusion prevention where licensed
- VPC Service Controls perimeters so data cannot move to projects outside the organization even with valid credentials
- MACsec on Dedicated Interconnect and IPsec on HA VPN to encrypt hybrid traffic in transit
- VPC Flow Logs and Firewall Rules Logging retained for at least 180 days to meet CERT-In direction requirements
Networking Pricing Levers: Interconnect Attachments, Egress Tiers, NAT and Load Balancer Charges
Google Cloud networking costs are driven by egress rather than ingress: internet egress varies by network tier and destination, inter-region traffic between Mumbai and Delhi is billed per GB, and Interconnect egress is cheaper per GB but adds hourly VLAN attachment and port charges. Cloud NAT bills per gateway-hour and per GB processed, and load balancers bill forwarding rules plus data processed.
- Move high-volume hybrid flows from VPN over the internet to Interconnect, where per-GB egress is lower
- Route Google API traffic through Private Google Access or PSC instead of Cloud NAT to avoid NAT processing charges
- Keep chatty tiers and their databases in the same region and zone set to avoid inter-region charges
- Right-size VLAN attachment capacity to measured P95 throughput rather than ordering maximum capacity
- Use Standard tier only for bulk, latency-tolerant internet egress from a single region
HA VPN vs Partner Interconnect vs Dedicated Interconnect: which hybrid link should we use from India?
Choose on bandwidth, SLA, lead time and location. HA VPN runs over your existing internet links, delivers a 99.99% SLA with redundant tunnels, and can be live in a day; throughput per tunnel is limited, so it suits branches and backup paths. Partner Interconnect uses a service provider's existing connection to Google, starts at 50 Mbps, scales through VLAN attachments, and suits offices or plants that cannot reach a colocation facility; lead time is typically weeks. Dedicated Interconnect requires your router in a Google colocation facility, offers 10, 100 or 400 Gbps circuits, MACsec and the lowest per-GB egress, and suits data centres with sustained multi-gigabit traffic. Most Indian enterprises use Partner Interconnect in Mumbai and Delhi with HA VPN as backup.
Key facts about networking on Google Cloud
Networking on Google Cloud in Practice
3 networking scenarios from BPO / ITES contact centre, Clinical research organization (CRO), Tyre manufacturing: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Contact-centre operator cuts voice jitter by 70% across six city hubs
Clinical research organization connects 48 trial sites to a private EDC platform
Tyre manufacturer links four plants to cloud MES and IIoT analytics at 99.99%
Animation studio bursts to 4,000 render cores for deadlines without buying hardware
Clinic network's EMR on AlloyDB serves doctors and reports from one database
Small finance bank onboards fintech partners in 3 weeks instead of 4 months
Networking on Google Cloud: Frequently Asked Questions
How is Cloud Interconnect billed?
Dedicated Interconnect bills an hourly port charge per circuit plus an hourly charge per VLAN attachment, and egress over the link is billed at a lower per-GB rate than internet egress. Partner Interconnect bills per VLAN attachment based on capacity, plus the provider's own charges. Ingress is free. We model break-even against VPN using your measured monthly egress, which usually favours Interconnect above tens of terabytes.
Can we get a 99.99% SLA for connectivity between our Indian data centres and Google Cloud?
Yes. The 99.99% Interconnect topology needs at least four VLAN attachments across two metropolitan areas, with two attachments in different edge availability domains in each metro, connected to Cloud Routers in two regions. In India this is typically built across Mumbai and Delhi, aligning with asia-south1 and asia-south2. HA VPN with redundant peer tunnels also carries a 99.99% SLA.
How do we migrate from many separate VPCs with peering to Shared VPC?
We build the Shared VPC host project alongside existing networks, create new subnets from the agreed IP plan, and migrate workloads project by project. Stateless tiers are redeployed into the new subnets behind load balancers; stateful VMs move during planned windows. Temporary peering or PSC keeps old and new networks connected during the transition, typically over 6-12 weeks for a mid-size estate.
Does Network Connectivity Center replace our SD-WAN?
No, it complements it. NCC lets SD-WAN appliances from supported vendors run as router appliance spokes in your VPC, so Google's backbone carries traffic between regions and sites while your SD-WAN keeps managing branch links and application policy. It removes the need for a mesh of VPN tunnels between every site and every cloud region.
Why use Private Service Connect instead of VPC peering for Cloud SQL or partner services?
PSC creates an endpoint IP inside your own subnet, so there is no peering, no route exchange and no risk of overlapping ranges with the producer. It also works across organizations, which matters when a bank, insurer or SaaS partner publishes a service to you. Access is controlled per endpoint, and the producer only sees connections from approved consumer projects.
Does keeping traffic within India require special network configuration?
Data residency is mainly a storage and processing decision, but networking supports it. We restrict resource locations to asia-south1 and asia-south2 by organization policy, keep load-balancer backends in India regions, and terminate Interconnect in Mumbai and Delhi. Global load balancers still route through Google's edge, so payloads in transit are TLS-encrypted end to end, which satisfies most RBI and DPDP Act reviews.