What Is a VPC in Google Cloud?
A Virtual Private Cloud (VPC) in Google Cloud is a logically isolated, software-defined network that lives inside a single GCP project and provides the networking layer for VM instances, GKE clusters, Cloud SQL private connections, and other resources. Unlike a physical data-center network, a VPC has no inherent regional boundary: it is a global resource made up of subnets, routes, and firewall rules that you attach to it, and every resource you place inside it can communicate using the Google backbone rather than the public internet.
Cricket analogy: Think of a VPC like a franchise's central playing squad list in the IPL: the squad (VPC) is one entity, but players (resources) can be fielded in matches played in Mumbai, Chennai, or Bangalore (regions) under the same franchise umbrella.
Global Resource, Regional Subnets
Because the VPC itself is global, two VM instances in different regions but the same VPC can talk to each other using their internal RFC 1918 IP addresses over Google's private backbone, with no VPN, no public IP, and no extra egress cost for cross-region traffic within the same VPC compared to crossing the internet. Subnets, however, are strictly regional: when you create a subnet you must pick one region, and the subnet's primary and secondary IP ranges are only meaningful within that region, even though the routes for that range propagate globally within the VPC.
Cricket analogy: This is like how a single ODI series scorecard (global VPC) links matches played at different regional grounds (subnets in Eden Gardens vs Wankhede), yet each ground has its own local pitch conditions and boundary dimensions.
Auto Mode vs Custom Mode VPCs
When you create a VPC, you choose between auto mode and custom mode. Auto mode immediately creates one subnet in every GCP region using a predetermined /20 CIDR block per region, which is convenient for quick experiments but leaves you with no control over IP ranges and often causes overlap problems later. Custom mode starts empty, and you explicitly create each subnet with the region and CIDR range you choose, which is the recommended approach for production because it lets you plan non-overlapping ranges for future VPC peering, hybrid connectivity via Cloud VPN or Interconnect, and clean IP address management.
Cricket analogy: Auto mode is like accepting the toss and batting first out of habit without reading the pitch report, while custom mode is like a captain studying the surface at the Chepauk before deciding the batting order.
# Create a custom-mode VPC (no subnets are created automatically)
gcloud compute networks create prod-vpc \
--subnet-mode=custom \
--bgp-routing-mode=regional
# Add a subnet explicitly in a chosen region and CIDR range
gcloud compute networks subnets create prod-subnet-us-central1 \
--network=prod-vpc \
--region=us-central1 \
--range=10.10.0.0/20 \
--enable-private-ip-google-access
# List subnets to confirm the ranges don't overlap across regions
gcloud compute networks subnets list --network=prod-vpcEvery new GCP project ships with a 'default' auto-mode VPC pre-populated with firewall rules that allow internal traffic and SSH/RDP from anywhere. For production workloads, Google recommends deleting or disabling the default VPC and building a custom-mode VPC with deliberately scoped firewall rules instead.
VPC Peering and Shared VPC
VPC Network Peering establishes a private connection between two separate VPCs, even across different projects or organizations, allowing internal IP traffic to flow between them without traversing the public internet or requiring a VPN gateway. Peering is non-transitive, meaning if VPC A peers with VPC B and VPC B peers with VPC C, resources in A cannot reach C through B; each pair of VPCs that needs connectivity must establish its own direct peering relationship, and the peered CIDR ranges must not overlap.
Cricket analogy: Peering is like two IPL franchises agreeing to loan a player directly to each other for a season; that arrangement doesn't automatically extend to a third franchise the second team also has a deal with.
Shared VPC solves a related but different problem: instead of connecting independent VPCs, it lets a central host project own the VPC network, subnets, and firewall rules, while one or more service projects attach to it and deploy resources like VMs or GKE clusters into those shared subnets. This is the standard pattern for organizations that want centralized network administration and IP address governance owned by a networking team, while individual product teams retain full control over the compute and application resources inside their own service projects.
Cricket analogy: Shared VPC is like a stadium (host project) owned and maintained by the cricket board, while individual franchises (service projects) book it for their matches without owning the ground themselves.
VPC peering does not automatically propagate on-premises routes learned via Cloud VPN or Interconnect, and custom routes are not exported by default. If your peered VPC needs to reach an on-premises network through the other VPC's hybrid connectivity, you must explicitly enable 'export custom routes' and 'import custom routes' on the peering connection, or the traffic will silently fail to route.
- A VPC is a global, project-scoped resource; subnets are always regional.
- Auto mode creates a /20 subnet per region automatically; custom mode starts empty and is recommended for production.
- Resources in the same VPC communicate across regions over Google's private backbone without public IPs.
- VPC Peering connects two separate VPCs privately but is non-transitive and requires non-overlapping CIDR ranges.
- Shared VPC centralizes network ownership in a host project while service projects deploy resources into shared subnets.
- The default auto-mode VPC created with every project should be reviewed or disabled before production use.
- Custom route export/import must be explicitly enabled on peering connections to propagate hybrid connectivity routes.
Practice what you learned
1. Which statement correctly describes the scope of a VPC and its subnets in GCP?
2. What is the main risk of using an auto-mode VPC for a production environment?
3. If VPC A is peered with VPC B, and VPC B is peered with VPC C, can resources in VPC A reach resources in VPC C?
4. In a Shared VPC setup, which statement is accurate?
5. What must be explicitly enabled on a VPC Peering connection for on-premises routes learned via Cloud VPN to propagate to the peered VPC?
Was this page helpful?
You May Also Like
Subnets and Firewall Rules
Learn how GCP subnets divide a VPC's IP address space by region, and how stateful, priority-based firewall rules control what traffic is allowed in and out of your instances.
Cloud Load Balancing Basics
Learn how GCP's fully managed, globally distributed load balancers route traffic to healthy backends, and the key differences between global, regional, external, and internal load balancer types.
Cloud DNS Basics
Understand how Google Cloud DNS serves authoritative public and private zones from a global anycast network, the core record types you'll configure, and how DNSSEC and delegation establish trust.