# Google Cloud VPC Networking – Detailed Explanation
In Google Cloud, a Virtual Private Cloud (VPC) is a logically isolated network where you deploy resources such as Compute Engine VMs, GKE clusters, databases, and internal applications.
A VPC provides control over IP addressing, connectivity, routing, security, DNS, and access to private services.
One important difference from AWS is that Google Cloud VPC networks are global, while their subnets are regional.
## 1. Understanding the overall architecture
Consider a production application with a frontend, FastAPI backend, PostgreSQL database, and private access to Google Cloud services.
Conceptual architecture. Cloud SQL uses service networking or Private Service Connect, rather than being an ordinary VM inside your application subnet.
## 2. The nine VPC networking sections
1\. Subnets
A subnet is a regional IP address range within a VPC. VMs and other supported resources receive their internal IP addresses from a subnet.
Example: `10.10.1.0/24` in Mumbai (`asia-south1`), with VM addresses `10.10.1.10` and `10.10.1.20`.
Google Cloud automatically creates subnet routes. Unlike AWS, subnets are not inherently public or private based on an associated route table. Internet reachability depends on external IPs, routes, firewall rules, and related connectivity.
2\. Static Internal IP Addresses
These are private IP addresses reserved for consistent use. Unlike an automatically allocated ephemeral internal IP, a reserved address can be retained for reuse, subject to its reservation type and scope.
Example: reserve `10.10.1.50` for an internal application VM or internal load balancer.
Useful when other applications depend on a stable private endpoint. Internal addresses may be regional or global, depending on the resource.
3\. Firewalls
VPC firewall rules allow or deny network traffic based on direction, source or destination, protocol, port, priority, and target.
Example: allow TCP port `443` to an application while restricting SSH port `22` to approved administration sources.
Rules can target VMs through network tags or service accounts. Google Cloud also supports hierarchical and network firewall policies for centralized management.
Firewall rules are stateful: permitted connection response traffic is generally allowed automatically.
4\. Endpoint Groups
Network endpoint groups (NEGs) represent collections of endpoints that can serve as backends for load balancers.
Endpoints might be VM IP-and-port combinations, GKE Pod endpoints, serverless services, or internet endpoints, depending on NEG type.
Example: an application load balancer distributes requests to three FastAPI backends using a NEG.
Important: A Network Endpoint Group is not the same as a Private Service Connect endpoint or a Cloud NGFW firewall endpoint.
5\. Firewall Endpoints
Cloud NGFW firewall endpoints are managed resources used for advanced Layer 7 inspection, including capabilities such as intrusion prevention and TLS inspection when appropriately configured.
These endpoints are associated with VPC networks and integrated with the applicable firewall policies.
Example: inspect outbound application traffic for known malicious signatures.
A standard VPC firewall rule does not require a firewall endpoint.
6\. Routes
Routes determine where IP packets travel to reach their destination.
Common route types include subnet routes, static routes, and dynamically learned routes through Cloud Router.
Example: `10.10.1.0/24` is a subnet route, while `0.0.0.0/0` may direct traffic toward the default internet gateway.
Routes determine the network path, but they do not independently authorize traffic. Firewall rules and other connectivity conditions still apply.
7\. VPC Network Peering
VPC Peering provides private IP connectivity between two VPC networks, including networks in different projects or organizations.
Example: a production application in `vpc-app` communicates with internal services in `vpc-shared`.
Peering is non-transitive: if VPC A peers with B, and B peers with C, A does not automatically reach C.
Subnet ranges must not conflict, and firewall rules must permit the intended traffic.
8\. Private Service Access
Private Service Access (PSA) enables private connectivity to supported Google-managed service producer networks using private services access connections.
Example: configure Cloud SQL private IP access using an allocated address range and a private service connection.
Your application connects to the database using private addressing rather than a public database endpoint.
PSA is different from Private Service Connect (PSC), which provides endpoint-based private access to supported services.
9\. DNS Configuration
DNS converts domain names into IP addresses. Cloud DNS supports private DNS zones, forwarding, and other resolution configurations.
Example: `api.internal.example.com` resolves to `10.10.1.20`.
Applications can use service names rather than hardcoded IP addresses. Private DNS zones can be authorized for specific VPC networks.
## 3. How these components work together
Imagine deploying your FastAPI multi-agent application with a PostgreSQL database and a load balancer.
| Requirement | Google Cloud networking component |
| --------------------------------------------- | --------------------------------- |
| Allocate private IPs to application VMs | Subnets |
| Give a backend a stable private IP | Static Internal IP |
| Permit HTTPS and restrict SSH | Firewall rules |
| Register backend endpoints for load balancing | Endpoint Groups (NEGs) |
| Inspect traffic for advanced threats | Firewall Endpoints |
| Decide how packets reach destinations | Routes |
| Connect application and shared-service VPCs | VPC Network Peering |
| Access supported managed services privately | Private Service Access |
| Resolve internal service names | DNS Configuration |
## 4. Important differences between AWS VPC and Google Cloud VPC
Since AWS networking concepts are closely related, this comparison is useful.
| Feature | AWS | Google Cloud |
| ------------------------------------ | ----------------------------------------- | ------------------------------------------------ |
| VPC scope | Regional | Global |
| Subnet scope | Availability Zone | Region |
| VM-level firewall | Security Groups | VPC firewall rules/policies |
| Subnet-level filtering | Network ACLs | No direct equivalent |
| Routing | Route tables associated with subnets | VPC routes and policy-based routes |
| Private network connectivity | VPC Peering | VPC Network Peering |
| Private managed-service connectivity | PrivateLink / service-specific networking | Private Service Connect / Private Service Access |
| DNS | Route 53 Resolver | Cloud DNS |
| Advanced traffic inspection | AWS Network Firewall | Cloud NGFW |
## 5. Recommended hands-on exercise
For learning, create a small VPC called `demo-vpc` in Google Cloud and configure the following:
VPC setup checklist
Interactive
0 of 8 completed
Reset
Create a custom-mode VPC named demo-vpc
Create a subnet 10.10.1.0/24 in asia-south1
Create two Compute Engine VMs in the subnet
Reserve a static internal IP for one VM
Create a firewall rule allowing required internal traffic
Inspect automatically created subnet routes
Configure a private DNS zone and record
Test private communication between the VMs
This exercise covers the foundational VPC features. VPC Peering, Private Service Access, endpoint groups, and advanced firewall endpoints can be explored afterward because they require additional resources or services.
One key concept: VPC networking is not just about connecting resources. It separates responsibilities: subnets allocate addresses, routes determine paths, firewalls control permitted traffic, DNS resolves names, and private connectivity mechanisms link networks and services.
For a production AI application, understanding these distinctions is particularly important when designing private connectivity between GKE, Compute Engine, Cloud SQL, Vertex AI, and internal services.
Official reference: [Google Cloud VPC documentation](https://cloud.google.com/vpc/docs/vpc?utm_source=chatgpt.com).
