Introduction to VPC Network Topologies
In Google Cloud, the Virtual Private Cloud (VPC) is the foundation of your infrastructure. Unlike traditional networking, a GCP VPC is a global resource, while subnets are regional. This unique architecture allows for seamless global communication without the need for complex VPNs between regions within the same VPC.
A Professional Cloud Architect must be able to design complex topologies that balance isolation, security, and connectivity.
A virtual version of a physical network, such as a data center network, implemented inside Google Cloud. It provides networking functionality to Compute Engine VM instances, GKE clusters, and the App Engine flexible environment. Reference: https://cloud.google.com/vpc/docs/vpc
Plain-Language Explanation: VPC Network Topologies
Networking can be abstract, so let's use some real-world comparisons.
Analogy 1 — The Multi-Story Office Building (VPC & Subnets)
Think of a VPC as a large office building. The building has a secure outer perimeter (VPC Firewall). Inside the building, each floor is a Subnet (Region). People on the 2nd floor (Iowa) can talk to people on the 10th floor (Belgium) through the internal stairs (Google's Global Fiber) without going outside. Each room on a floor is a VM instance with its own door lock (Internal Firewall Rules).
Analogy 2 — The Shared Campus (Shared VPC)
Imagine a university campus where one central department (Host Project) manages the roads, electricity, and security. Various other departments (Math, Science, History) have their own buildings (Service Projects) but use the central infrastructure. This is Shared VPC. It allows for centralized control of networking while letting individual teams manage their own applications.
Analogy 3 — The Secret Tunnel (Private Service Connect)
Private Service Connect is like a secret, secure tunnel between two different buildings that are owned by different companies. You don't want to walk on the public sidewalk (The Internet) to get to your partner's office. Instead, you build a tunnel that connects your basement directly to their basement. It's safe, private, and doesn't expose you to the public.
On the PCA exam, if a scenario requires "centralized network management" across multiple projects, the answer is almost always Shared VPC. Reference: https://cloud.google.com/vpc/docs/shared-vpc
Creating and Managing VPCs
GCP offers two types of VPC networks:
- Auto mode: Automatically creates a subnet in each region with pre-defined IP ranges. Avoid this for production as it can lead to IP overlaps.
- Custom mode: You manually define subnets and their IP ranges. This is the architect-preferred method for production.
For any PCA scenario involving hybrid connectivity (Cloud VPN / Interconnect) or future VPC Peering, you must choose Custom mode VPCs. Auto mode subnets use the fixed 10.128.0.0/9 range, which almost always collides with on-prem CIDRs or peered VPCs — and peered VPCs cannot have overlapping IP ranges. Custom mode lets you allocate non-overlapping ranges aligned with your IP plan.
Custom Subnet Configuration
Subnets are regional. Key considerations:
- Secondary IP Ranges: Used for GKE (Pods and Services).
- Expandable Subnets: You can increase the size of a subnet without downtime (e.g., from /24 to /22).
- Internal IPv6: GCP supports dual-stack (IPv4/IPv6) networking.
Firewall Rule Management
GCP firewalls are stateful and distributed.
- Ingress vs. Egress: Control traffic coming in or going out.
- Priority: Lower numbers have higher priority (0-65535).
- Targets: Use Network Tags or Service Accounts for dynamic rule application (Service Accounts are more secure and recommended for PCA).
- Hierarchical Firewall Policies: Apply rules at the Organization or Folder level to enforce global security standards.
Configuring Private Google Access
This allows VMs with only internal IP addresses to access Google APIs and services (like Cloud Storage, BigQuery) without an external IP or a NAT gateway.
- Requirement: The subnet must have "Private Google Access" enabled.
- Benefit: Increases security and reduces egress costs.
VPC Flow Logs for Troubleshooting
Flow Logs record a sample of network flows sent from and received by VM instances.
- Use Cases: Network monitoring, forensics, real-time security analysis, and expense optimization.
- Integration: Can be exported to Cloud Logging, BigQuery, or Pub/Sub.
Network Topology Visualization
Network Topology is a tool in the Intelligence Center that provides a graph of your VPC networks, including connectivity to on-prem and other clouds. It helps visualize traffic patterns and identify bottlenecks.
Packet Mirroring for Security
Packet Mirroring clones traffic from specified sources (VMs, GKE nodes) and sends it to a destination (IDS/IPS, packet collector) for inspection.
- Key Point: It captures all traffic (both allowed and denied by firewalls).
Configuring Private Service Connect (PSC)
PSC allows you to consume services (Google APIs or third-party services) privately within your VPC.
- Endpoints: A private IP address in your VPC that points to a service.
- Backends: Allows you to publish your own service for others to consume.
Managing Internal and External IP Addresses
- Static vs. Ephemeral: Use Static IPs for resources that need a consistent address (e.g., NAT gateways).
- External IPs: Minimize their use. Use Cloud NAT for VMs that need internet access without a public IP.
VPC Peering Configuration
VPC Peering connects two VPC networks so that resources can communicate using internal IP addresses.
- No Transitive Peering: If VPC A is peered with B, and B is peered with C, A cannot talk to C through B.
- IP Overlap: Peered VPCs cannot have overlapping IP ranges.
Candidates often pick VPC Peering for a "hub-and-spoke" topology where many spoke VPCs need to reach shared services through a hub VPC. This fails because peering is non-transitive — spokes peered to the hub still cannot reach each other, and cannot reach services that the hub itself reaches via another peering. For true hub-and-spoke routing of internal traffic, use Network Connectivity Center (NCC) with VPC spokes, or consolidate workloads under a Shared VPC Host Project.
When a scenario describes a single organization centralizing network and security administration while letting application teams own their own projects, the answer is Shared VPC (Host Project owns the VPC + subnets, Service Projects attach to it) — not VPC Peering. Peering is the correct answer only when the connected VPCs are owned by separate administrative groups or organizations, as called out in Q1 of the FAQ.
Firewall rule priority is an integer 0–65535, where lower numbers win. There are two implied default rules at priority 65535: an implied allow-egress to anywhere and an implied deny-ingress from anywhere. Any custom rule you create must use a priority less than 65535 to override these defaults, and Service Account targets are preferred over Network Tags because tags can be edited by anyone with VM-edit permission.
FAQ — VPC Network Topologies
Q1. When should I use VPC Peering instead of Shared VPC?
Use VPC Peering when you need to connect networks owned by different administrative groups or organizations. Use Shared VPC when you have a single organization that wants to centralize network administration while decentralizing application management.
Q2. Does a VPC Firewall rule apply to a whole VPC or a single VM?
Firewall rules are defined at the VPC level but are distributed to each VM instance's virtual network interface (vNIC). Only rules that match the VM's tags or service account are applied.
Q3. What is the difference between Cloud NAT and Private Google Access?
Private Google Access is only for reaching Google services (like GCS). Cloud NAT is for reaching the public internet (like OS updates or external APIs).
Q4. Why should I use Service Accounts in firewall rules instead of Network Tags?
Service Accounts provide identity-based security. Tags are just strings that anyone with VM edit permissions can change. Service accounts are more robust and less prone to configuration errors in large environments.
Q5. Can I peer a VPC in Project A with a VPC in Project B?
Yes, VPC Peering works across different projects and even different organizations, provided the IP ranges do not overlap.
Final Architect Tip
In the PCA exam, always aim for zero trust and least privilege in your network design. Avoid "Allow All" rules. Use VPC Service Controls to add an extra layer of protection around sensitive data, even if your network is technically secure.