Google VPC implementation is very different than traditional Cloud VPC (AWS/Azure) implementation. First take a look at how a traditional VPC (AWS/Azure) concepts.
Traditional VPC
In traditional VPC (AWS/Azure/etc.), the VPC boundary is based on a physical location/region.
For instance when AWS VPC is created, it must be specified by a region such as VPC in US-West or VPC in US-East.
In the topology below, notice that there are two VPCs present. One in US West and the other in US East. Each VPC has its own subnet.
In order for these VPCs to communicate with each other, there are mainly two options available
- Either configure something called VPC peering (it has its own limitations)
- Or use VPN/IPSec technology to connect over public internet (this has its own limitations as well for example 1.25 Gbps throughput per VPN tunnel)
In traditional VPC, subnet and VPC are regional.
GCP VPC
In the following GCP VPC topology, notice that VPC is globally available but subnets are regional entities.
So instead of building a VPC in US-West and another VPC in US-East, GCP builds VPC across globe and then customer builds subnets in specific regions. Here there is no inter-VPC VPN requirement. All the routing within the VPC is handled by GCP under the hood. There are way to control the traffic using Firewall rules etc.
In GCP VPC, subnet is regional but VPC is global.