GCP Networking Fundamentals — VPC, Subnets, Firewalls

GCP networking surprises engineers coming from AWS or Azure because the fundamental scoping is different. VPCs are global. Subnets are regional. Firewall rules are global too (despite often being scoped by tags or service accounts). This guide walks through every networking concept ACE tests, with the focus on the bits that catch AWS-fluent candidates off guard.

VPC — the global container

A Virtual Private Cloud (VPC) in GCP is a global resource. One VPC can span every GCP region. VMs in us-central1 and asia-east1 can be in the same VPC and communicate over Google's backbone without any peering, transit gateway, or VPN.

A VPC contains:

• Subnets (one or more per region you use).
• Firewall rules (apply VPC-wide, can target specific resources via tags/SAs).
• Routes (programmatic paths for traffic, both system-generated and custom).
• References to peering connections, VPN gateways, Cloud Interconnect attachments.

You can have multiple VPCs in a project (default quota: 5; raisable). Each VPC is independent. Resources in different VPCs cannot communicate by default — you need peering, VPN, or Cloud Interconnect.

Subnets — regional CIDRs

A subnet is a regional resource: it lives in exactly one region and has one primary IP CIDR range plus optional secondary ranges. VMs in any zone within that region can use the subnet.

One subnet spans all zones in its region. Unlike AWS, you do not need a subnet per availability zone for HA — a single regional subnet is enough.

Subnet behaviour to know for ACE:

• Primary range is the main CIDR for VMs.
• Secondary ranges are for GKE pods and services (alias IP ranges). When you create a VPC-native GKE cluster, you allocate secondary ranges for pods and services.
• Reserved addresses: GCP reserves the first 2 and last 2 IPs in each subnet (network, default gateway, second-to-last, broadcast equivalent).
• Subnet expansion: you can expand a primary range to a larger CIDR without re-creating the subnet. You cannot shrink it.
• Private Google Access toggle: per-subnet setting that determines whether VMs without external IPs can reach Google APIs through the subnet.

Auto-mode vs custom-mode VPCs

Auto-mode

An auto-mode VPC automatically creates a subnet in every GCP region (currently ~40 regions) with predefined CIDR ranges in the 10.128.0.0/9 block. When new regions launch, GCP automatically adds subnets.

• Convenient for sandbox and learning projects.
• Default firewall rules allow internal traffic, SSH from anywhere (0.0.0.0/0:22), RDP, and ICMP.
• Not recommended for production — the predefined IP ranges may collide with on-prem networks, and the default SSH-from-anywhere rule is a security risk.

Custom-mode

A custom-mode VPC has no subnets initially. You create each subnet manually with the CIDR range you choose. No default firewall rules — you create those too.

• The right choice for production.
• Lets you plan IP space that fits your on-prem and multi-cloud topology.
• Forces you to define explicit firewall rules instead of relying on broad defaults.

You can convert an auto-mode VPC to custom-mode (one-way operation). You cannot convert custom-mode to auto-mode.

Firewall rules

GCP firewall rules are stateful (return traffic is automatically allowed if the inbound is allowed), global (defined at the VPC level), and priority-ordered (lower number = higher priority).

Each rule has:

• Priority: 0-65535. Lower number wins. Default 1000.
• Direction: ingress or egress.
• Action: allow or deny.
• Source (for ingress) or destination (for egress): IP CIDR ranges, network tags, or service accounts.
• Target: the VMs the rule applies to — all instances in the VPC, instances with a specific network tag, or instances using a specific service account.
• Protocol and ports: e.g., tcp:80,443 or icmp or all.

Default rules

• Implied allow all egress (priority 65535): traffic out is allowed unless an explicit egress deny rule blocks it.
• Implied deny all ingress (priority 65535): traffic in is blocked unless an explicit ingress allow rule permits it.
• The default VPC also has named pre-built rules: default-allow-internal, default-allow-ssh, default-allow-rdp, default-allow-icmp. Custom-mode VPCs have none of these.

Targeting by tag vs service account

Both are valid. The exam may give scenarios where one is more appropriate:

• Network tags are simple string labels attached to VMs. Anyone with permission to modify the VM can add or remove tags.
• Service account targeting is more secure: only the VM's configured service account can be targeted. Service accounts cannot be changed without IAM permissions on the SA. Preferred for security-sensitive rules.

Example firewall rule (gcloud)

gcloud compute firewall-rules create allow-web-to-db \ --network=my-vpc \ --direction=INGRESS \ --action=ALLOW \ --priority=1000 \ --rules=tcp:3306 \ --source-tags=web \ --target-tags=db

Routes

Routes determine the next hop for traffic leaving a VM. Two types:

• System-generated: GCP creates these automatically. The default-internet route (0.0.0.0/0 → default internet gateway) and per-subnet routes for in-VPC traffic.
• Custom routes: you create these. Common use cases — sending egress through a VPN gateway, routing traffic through a firewall appliance VM (next-hop instance), peering routes, etc.

Routes have a priority (lower = higher priority) and apply globally within the VPC, or can be scoped by network tag. Routes are stateless — return traffic is handled by the firewall stateful tracking, not by reverse routes.

VPC peering

VPC peering creates a direct private connection between two VPCs. Each side sees the other's subnet routes (or a configurable subset). VPC peering works across projects and across organisations.

Key properties:

• Non-transitive: if VPC A peers with B and B peers with C, A and C cannot communicate directly. You need separate peering between A and C, or a hub-and-spoke design with NCC.
• No bandwidth charges for traffic within the same region. Inter-region peering traffic is charged at egress rates.
• Cannot have overlapping CIDR ranges. Plan IP addresses to avoid collisions before establishing peering.
• One-way private services access peering connects your VPC to Google-managed services (e.g., Cloud SQL with private IP).

Shared VPC

Shared VPC lets multiple projects share a single VPC network. One project becomes the host project; others become service projects. Service-project resources (VMs, GKE clusters, Cloud SQL) live in the host project's VPC.

Common scenario: a central platform/networking team owns the host project and the VPC, firewall rules, and routing. Application teams own service projects where they deploy their workloads but cannot modify the underlying network. IAM stays project-scoped — application teams cannot mess with networking.

To set up Shared VPC, the host-project admin grants service-project admins the roles/compute.networkUser role on specific subnets in the host VPC. Service-project admins can then deploy VMs into those subnets.

Private Google Access

By default, VMs without external IPs cannot reach Google APIs (Cloud Storage, BigQuery, Cloud Logging, etc.). Private Google Access is a per-subnet setting that routes API traffic to Google services privately, without traversing the public internet.

Enable it on a subnet to let private VMs use Google services. No firewall changes needed — the traffic stays within Google's network. The VM still needs egress firewall permission for the Google API endpoints.

Related but distinct: Private Service Connect (PSC) lets private VMs reach Google APIs and your published services via private endpoints in your VPC. Restricted Google APIs (VIP 199.36.153.4/30) lets you block public Google API access entirely and only allow specific APIs via VPC Service Controls.

Cloud NAT

Cloud NAT provides outbound internet access for VMs without external IPs. Configure Cloud NAT on a VPC and region; VMs in subnets without external IPs can make outbound connections through it.

Key properties:

• Outbound only. Cloud NAT does not allow inbound connections from the internet.
• Regional resource. One Cloud NAT gateway per region per VPC.
• Automatic NAT IP allocation by default; you can also allocate static external IPs to Cloud NAT.
• Logging: optional. Logs source/destination/port for troubleshooting and compliance.
• Common use case: GKE private clusters where pods need to pull images or call third-party APIs without public IPs on the nodes.

Load balancers — the decision tree

GCP load balancers split along three axes: internal vs external, regional vs global, and L7 (HTTP/S) vs L4 (TCP/UDP).

Decision shortcuts for the exam:

• Public HTTPS, multi-region → Global external HTTP(S).
• Internal microservice routing → Internal HTTP(S).
• Non-HTTP traffic to game servers / VoIP → External TCP/UDP Network LB.
• Internal VM-to-VM TCP → Internal TCP/UDP Network LB.

Cloud DNS

Cloud DNS is GCP's managed authoritative DNS service. Two zone types:

• Public zones: authoritative answers for queries from the internet. Used for your public domain (e.g., example.com).
• Private zones: visible only within a specified VPC. Used for internal hostnames (e.g., db.internal.example.com).

DNS peering and forwarding lets you resolve names across VPCs and to on-prem DNS servers. Cloud DNS responses are AnyCast — low latency from anywhere in the world.

Hybrid connectivity

Three options for connecting on-prem to GCP:

• Cloud VPN (HA VPN): IPsec tunnels over the public internet. Cheap, encrypted, suitable for moderate bandwidth (up to ~3 Gbps per HA VPN gateway).
• Dedicated Interconnect: physical 10 Gbps or 100 Gbps connection between your on-prem data centre and a Google peering edge. Requires colocation at a Google PoP.
• Partner Interconnect: connect via a service-provider partner. 50 Mbps to 50 Gbps. Suitable when you cannot reach a Google PoP directly.

All three integrate with Cloud Router for dynamic BGP routing between on-prem and GCP. ACE expects you to know which is which but not deep configuration details.

Common exam traps

1. Assuming VPCs are regional. They are global. VMs across regions in the same VPC communicate without peering.
2. Forgetting that custom-mode VPCs have no default firewall rules. If a VM cannot SSH in a custom-mode VPC, the answer is “you need an ingress allow rule for tcp:22” not “the default rule is wrong.”
3. Confusing Private Google Access with Cloud NAT. Private Google Access = reach Google APIs from private VMs. Cloud NAT = reach the public internet from private VMs. They solve different problems.
4. VPC peering is non-transitive. A↔B and B↔C does not mean A↔C. Many exam questions hinge on this.
5. Firewall rules are stateful. You do not need a reverse rule for return traffic. AWS engineers often write redundant ingress rules thinking they need them.
6. Subnet primary range cannot overlap with on-prem. If on-prem uses 10.0.0.0/16, you cannot use it in your VPC if you intend to peer or VPN.
7. One subnet per region is enough for HA. Spread VMs across zones within that subnet; the regional subnet covers all zones.

Worked examples

Example 1: Private VM needs to reach BigQuery

Enable Private Google Access on the subnet. The VM (with only internal IP) routes BigQuery API traffic privately through Google's network. No Cloud NAT involved (BigQuery is a Google API, not the public internet).

Example 2: Private GKE cluster pods need to pull container images from Docker Hub

Configure Cloud NAT for the region the cluster runs in. Docker Hub is on the public internet, so the pods need NAT to reach it from their private subnet.

Example 3: Allow only the “web” tier to reach the “db” tier on port 5432

Create an ingress firewall rule: source-tags=web, target-tags=db, rules=tcp:5432, action=ALLOW. Tag web VMs with “web” and db VMs with “db”. The implied deny-ingress handles blocking everything else.

Example 4: Networking team owns the VPC; app teams deploy independently

Use Shared VPC. Networking team owns the host project with the VPC, firewall rules, and routes. App teams have service projects, granted roles/compute.networkUser on specific subnets. App teams deploy VMs but cannot modify the network.

Example 5: Site-to-site connectivity from on-prem data centre

For moderate bandwidth (under 3 Gbps) and quick setup: HA VPN. For high bandwidth (>10 Gbps) and dedicated reliability: Dedicated Interconnect. For mid-range and cannot colocate: Partner Interconnect.

Frequently asked questions