The networking domain on the GCP-ACE exam demands more than memorization — it tests your ability to make architectural decisions. When do you choose Shared VPC over VPC Peering? Why is Network Load Balancer the wrong answer when serving global HTTPS traffic? What tool separates cost estimation from actual billing? These judgment calls define the difference between passing and guessing. This guide walks through what makes GCP networking unique, how to select the right load balancer, which supporting services to reach for, and how to avoid the cost traps that catch engineers off guard.
---
How GCP Networking Differs from Other Clouds
The first thing that surprises engineers coming from AWS or Azure is that GCP VPC is a global resource. In AWS and Azure, a VPC or VNet belongs to a specific region. Connecting a Seoul VPC to a US-East VPC requires explicit peering or a Transit Gateway.
GCP works differently. A VPC has no region — it is a global construct. You can place subnets in Seoul (asia-northeast3), US East (us-east1), and Europe (europe-west1) inside the same VPC, and the VMs attached to those subnets can communicate via private IPs without any additional configuration.
A second differentiator is Google's global private backbone. When traffic hits a global load balancer, it is received at the nearest Google PoP, then carried over Google's private fiber — not the public internet — to the backend region. This is what makes a single global Anycast IP capable of delivering low-latency responses worldwide.
| Attribute | GCP | AWS | Azure | |-----------|-----|-----|-------| | VPC Scope | Global (no region) | Per-region | Per-region | | Subnet Scope | Per-region, spans all zones | Per-availability zone | Per-region | | Global LB | Single Anycast IP | Requires separate setup | Requires separate setup | | Global Backbone | Google private network | AWS internal network | Microsoft internal network |
---
VPC and Subnets: The Global VPC Model
When you create a VPC in GCP, you do not select a region — it is a global network container. Regions come into play at the subnet level. When you create a subnet, you specify a region, and that subnet automatically spans all availability zones in that region. A Seoul subnet and a US subnet living in the same VPC allow their attached VMs to talk via private IPs with no extra routing or peering configuration.
GCP subnets support secondary IP ranges in addition to the primary CIDR block. These are used primarily for GKE pods and services, giving Kubernetes workloads an independent address space that does not collide with the primary VM IP space.
Firewall rules operate at the VPC level. To apply a rule to a specific set of VMs, you use network tags or service accounts as targets. This differs from AWS security groups, which attach directly to instances. In GCP, the rule is defined on the VPC and the tag on the instance determines whether the rule applies.
| Element | Description | Key Limitation | |---------|-------------|----------------| | VPC | Global resource, no region affinity | Default limit of 5 VPCs per project | | Subnet | Region-scoped, covers all zones in that region | No overlapping CIDRs allowed | | Secondary IP Range | Extra IP pool for GKE pods and services | Up to 30 ranges per subnet | | Firewall Rule | VPC-level, targeted via tags or service accounts | Stateful processing |
---
Auto Mode vs Custom Mode VPC and IP Planning
When creating a VPC, you choose between auto mode and custom mode. You can convert an auto mode VPC to custom mode, but the reverse is not possible — so the initial choice matters.
Auto mode automatically creates a /20 subnet in each region from the 10.128.0.0/9 block. It is convenient for development, testing, and learning environments where speed of setup matters more than IP precision. Custom mode gives you full control over subnet creation — you define each subnet manually, choosing the region and CIDR block.
For production workloads, custom mode is the correct choice whenever you anticipate connecting to on-premises networks via Cloud Interconnect or VPN. The 10.128.0.0/9 block used by auto mode overlaps with address ranges commonly used in corporate data centers. If an overlap exists when you try to connect, redesigning the VPC is your only option.
| Attribute | Auto Mode | Custom Mode | |-----------|-----------|-------------| | Subnet Creation | Automatic (/20 per region) | Manual (user-defined) | | IP Range | 10.128.0.0/9 fixed | User-defined | | Recommended For | Dev/test, learning | Production, enterprise | | On-Premises Connectivity | High IP conflict risk | Conflict avoidable | | Conversion | Auto → Custom allowed | Custom → Auto not allowed |
!Auto Mode versus Custom Mode VPC
Shared VPC and VPC Peering: Two Connectivity Models
When you need network connectivity across multiple GCP projects, you have two options: Shared VPC and VPC Peering. This is consistently one of the most frequently confused topics on the exam.
Shared VPC designates one project as the host project, which owns and manages the VPC. Other projects — called service projects — are attached to the host and deploy their VMs into subnets that belong to the host VPC. The VMs communicate via private IPs within the same VPC, and there is a clean separation between the network administrators (host project team) and the application teams (service project teams).
VPC Peering connects two VPCs point-to-point. Each VPC remains independently managed, and peering enables private IP communication between them. The critical property to remember is non-transitivity. If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A and VPC C cannot communicate. You would need to establish a direct peering between A and C. Shared VPC avoids this entirely because all service projects share the same VPC.
| Attribute | Shared VPC | VPC Peering | |-----------|------------|-------------| | Network Ownership | Single host project | Each VPC independently owned | | Management Model | Centralized (host project) | Distributed (each team) | | Service Project Scale | Up to 1,000 service projects | Requires N:N peerings | | Non-transitivity | Not applicable (same VPC) | Applies (A-B-C cannot transit) | | Cross-organization | Not supported (same org only) | Supported | | Primary Decision Factor | Central network governance | Independent network ownership |
Exam trigger: multiple project VMs needing private IP communication with central management → Shared VPC. Two independent VPCs needing private connectivity → VPC Peering.
---
GCP Load Balancer Types and Decision Framework
Load balancer selection is a high-frequency topic on the GCP-ACE exam. The decision tree runs along three axes: scope (global vs regional), direction (external vs internal), and layer (L7 application vs L4 network).
The global external Application Load Balancer (formerly Global HTTP(S) LB) accepts traffic via a single Anycast IP from anywhere in the world, routes requests to different backends based on URL path and host header, and handles SSL termination with Google-managed certificates. It operates at Layer 7. If you need to route /api/orders and /api/users to separate backend services, this is the load balancer you want.
The internal Application Load Balancer handles HTTP traffic inside a VPC. It is used for private communication between microservices and as a private API gateway. It has no public IP.
Network Load Balancer operates at Layer 4 and handles TCP and UDP. It cannot inspect URLs, making it unsuitable for path-based routing. It excels in ultra-low-latency scenarios like game servers and real-time UDP applications.
| Load Balancer Type | Scope | Layer | Key Capabilities | Choose When | |--------------------|-------|-------|------------------|-------------| | Global External Application LB | Global | L7 | URL routing, global Anycast, SSL offload | Global HTTPS, URL path routing | | Regional External Application LB | Regional | L7 | URL routing, SSL offload | Single-region HTTPS | | Internal Application LB | Regional | L7 | Private HTTP traffic within VPC | Microservice-to-microservice HTTP | | External Network LB (passthrough) | Regional | L4 | TCP/UDP, ultra-low latency | Gaming, streaming, legacy apps | | Internal Network LB (passthrough) | Regional | L4 | Private TCP/UDP within VPC | Internal high-throughput workloads | | Proxy Network LB | Global/Regional | L4 | TCP proxy | TCP + global distribution |
Decision guide: global HTTPS with URL routing → Global External Application LB. Internal microservice HTTP → Internal Application LB. UDP with ultra-low latency → Network LB. Automatic regional failover → Global Application LB.
---
Cloud DNS, Cloud CDN, and Cloud NAT: Roles and Boundaries
Supporting network services show up on the exam, and their boundaries matter. Knowing what each one does — and does not do — prevents misidentification under time pressure.
Cloud DNS manages DNS records with a 99.99% SLA. A public zone handles externally resolvable domain names. A private zone is attached to one or more VPCs and is only visible to VMs within those VPCs — external resolvers cannot query it. When VMs inside a VPC need to reach internal services by name, you attach a private zone to the VPC.
Cloud CDN caches static content at Google edge locations close to users. It works alongside the global external Application Load Balancer. On a cache hit, the response is served from the edge, reducing backend load and inter-region egress costs. Images, videos, CSS, and JavaScript files are ideal candidates. Cloud CDN is not the right answer for dynamic content that changes per request.
Cloud NAT allows private VMs — those without external IP addresses — to initiate outbound connections to the internet. Package updates, third-party API calls, and software downloads all benefit from Cloud NAT. Inbound connections from the internet are blocked, which impro