Networking Resources

Assumes you're comfortable with Part 4's default-VPC warning and Part 3's IAM conditions. This chapter is where the network Part 1 told you not to build production resources on gets designed properly.

Table of Contents#

1. What This Chapter Covers
2. VPCs and Subnets: Custom Mode, Shared VPC, and Peering
3. From VPC Firewall Rules to Cloud NGFW Policies
4. Secure Tags: Identity-Based Micro-Segmentation
5. Choosing a Load Balancer
6. Network Service Tiers: Premium vs. Standard
7. Hybrid Connectivity: Cloud VPN and Cloud Interconnect
8. Cloud DNS and Cloud NAT
9. Managing Subnets: Resizing, Static IPs, and Static Routes
10. A Full Worked Example: Meridian's Network Topology
11. Real-World Scenario: The Firewall Migration That Broke Nothing, on Purpose
12. Second Real-World Scenario: The Subnet That Ran Out of IP Addresses at 2 AM
13. Part 7 gcloud Cheat Sheet
14. Pre-Flight Checklist: Is This Network Design Production-Ready?
15. Common Mistakes and Interview Traps
16. Worked Practice Problems
17. Summary and What's Next

What This Chapter Covers#

🎯 By the end of this chapter, you'll be able to replace a default VPC with a deliberately designed network: custom subnets, Cloud NGFW policies driven by identity rather than IP ranges, the right load balancer for the traffic shape, and hybrid connectivity back to on-premises systems.

VPCs and Subnets: Custom Mode, Shared VPC, and Peering#

A custom-mode VPC (as opposed to the auto-mode default VPC from Part 1) starts with zero subnets, forcing an explicit decision about IP ranges per region rather than inheriting Google's default allocation. Shared VPC lets a central "host" project own the network while "service" projects attach their resources to it, the standard pattern for a platform team that wants centralized network control (firewall policy, subnet allocation) while still letting individual teams manage their own compute and IAM within their own project.

VPC Network Peering connects two separate VPCs (in the same or different projects/organizations) with private RFC 1918 connectivity, without traffic ever traversing the public internet, but critically, peering is non-transitive: if VPC A peers with VPC B, and VPC B peers with VPC C, A cannot reach C through B, each peering relationship is a direct, standalone connection.

Caption: the two service projects share one network fabric through Shared VPC, while the peered partner VPC is a separate, direct relationship, it cannot reach either service project through the host VPC's Shared VPC attachment.

From VPC Firewall Rules to Cloud NGFW Policies#

Classic VPC firewall rules attach directly to a network, matching traffic by IP range, network tag, or service account. Cloud NGFW (Next Generation Firewall) network firewall policies are the newer, evolved model: policies attach at the global or regional level (and can be associated with a folder or organization for hierarchical enforcement, the same inheritance pattern from Part 1's org policies), and they introduce Secure Tags as a first-class targeting mechanism instead of legacy network tags.

Secure Tags: Identity-Based Micro-Segmentation#

Secure Tags (the Resource Manager tags from Part 1, applied specifically to firewall targeting) are centrally managed, IAM-governed key-value tags that let you write a firewall rule matching "any resource carrying env=production," regardless of which subnet, IP range, or even which peered VPC it happens to live in, as of a 2026 update, Secure Tags now work across VPC Network Peering boundaries too, not just within a single network.

# A Cloud NGFW rule allowing traffic only between resources
# tagged as the same tier, regardless of IP range
action: ALLOW
direction: INGRESS
match:
  srcSecureTags:
    - "tagValues/meridian-freight-prod-8f2k/env/production"
targetSecureTags:
  - "tagValues/meridian-freight-prod-8f2k/env/production"

💡 This is the actual mechanism behind "identity-based micro-segmentation": instead of a firewall rule that has to be rewritten every time an IP range changes (a resize, a new subnet, a migration), a Secure-Tag-based rule keeps working correctly as long as the tag stays correctly applied, since the rule matches an identity attribute, not a network address.

Choosing a Load Balancer#

GCP's load balancer family splits along two axes: scope (global vs. regional) and layer (Application/HTTP(S), Network/TCP-UDP, or a proxy variant):

Caption: the first fork that matters is layer, not scope, a raw TCP/UDP requirement rules out every Application Load Balancer option before global-versus-regional ever becomes the question.

Network Service Tiers: Premium vs. Standard#

Premium Tier routes traffic across Google's own private global fiber backbone (over 200 points of presence worldwide), entering and exiting that backbone as close to the end user as possible, the lower-latency, higher-cost option. Standard Tier routes traffic over regular public internet transit for a larger portion of its path, costing less but with less consistent latency and no SLA-backed performance guarantee.

⚠️ Not every load balancer type supports both tiers: the global external Application Load Balancer supports Premium Tier only, while the regional external Application Load Balancer supports both. This asymmetry is a specific, testable exam fact, choosing "global" implicitly chooses Premium Tier pricing too.

Hybrid Connectivity: Cloud VPN and Cloud Interconnect#

Choose Cloud VPN when bandwidth needs are modest or the connection is a backup path. Choose Cloud Interconnect when sustained bandwidth or latency consistency matters enough to justify the longer lead time and higher commitment.

Cloud DNS and Cloud NAT#

Cloud DNS provides both public zones (internet-facing DNS) and private zones (resolvable only within your VPC), the latter being how internal services reference each other by name (dispatcher.internal.meridianlogistics.com) without depending on IP addresses that can change. Cloud NAT provides outbound-only internet connectivity for instances with no external IP (exactly the --no-address pattern from Part 4), translating outbound requests through a pool of external IPs without ever exposing those instances to unsolicited inbound traffic from the internet.

Managing Subnets: Resizing, Static IPs, and Static Routes#

Resizing a subnet's IPv4 range (expanding its CIDR block) is possible without disrupting existing resources, as long as the expansion doesn't collide with another subnet's range, a genuinely useful operational escape hatch when a subnet was originally sized too small. Reserving a static external or internal IP address decouples an address from a specific resource's lifecycle, letting you point DNS at a fixed address even as the underlying VM is recreated (via an instance template rolling update, for instance). Custom static routes override the VPC's default routing behavior for specific destination ranges, most commonly to direct traffic through a network virtual appliance or a specific Cloud Interconnect path rather than the default internet gateway.

A Full Worked Example: Meridian's Network Topology#

# 1. Custom-mode VPC, no default subnets
gcloud compute networks create meridian-shared-network --subnet-mode=custom

# 2. A subnet per environment folder from Part 1's resource hierarchy
gcloud compute networks subnets create prod-us-central1 \
  --network=meridian-shared-network --region=us-central1 --range=10.10.0.0/20

# 3. A Cloud NGFW policy using Secure Tags, not IP ranges
gcloud network-firewall-policies create meridian-tier-policy --global

gcloud network-firewall-policies rules create 1000 \
  --firewall-policy=meridian-tier-policy \
  --action=ALLOW --direction=INGRESS \
  --src-secure-tags=tagValues/PROJECT/env/production \
  --target-secure-tags=tagValues/PROJECT/env/production

# 4. Cloud NAT for outbound-only internet access, no external IPs anywhere
gcloud compute routers create meridian-nat-router --network=meridian-shared-network --region=us-central1
gcloud compute routers nats create meridian-nat-config \
  --router=meridian-nat-router --region=us-central1 --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

Real-World Scenario: The Firewall Migration That Broke Nothing, on Purpose#

Meridian's platform team migrated their production network from classic VPC firewall rules to a Cloud NGFW network firewall policy, aware from the outset that plain network tags aren't supported by policies. Rather than a risky big-bang cutover, they ran both mechanisms in parallel for two weeks: every classic rule stayed active while an equivalent Secure-Tag-based policy rule was added alongside it, and Secure Tags were applied to every relevant resource ahead of time. Only after confirming (via VPC Flow Logs, covered in Part 8) that the new policy rules were correctly matching the same traffic the old rules had been did they remove the classic rules entirely. The migration completed with zero unplanned denials, specifically because the team treated "does the new mechanism actually match the same traffic" as something to verify before removing the old one, not something to assume.

Second Real-World Scenario: The Subnet That Ran Out of IP Addresses at 2 AM#

A GKE cluster's node pool, configured to autoscale up during a batch processing window, hit a hard wall at 2 AM when its subnet's available IP range was exhausted: new nodes couldn't be allocated an IP at all, and the autoscaler's requested capacity simply never materialized, silently capping throughput well below what the workload needed. The immediate cause was a subnet sized for the cluster's original expected scale, never revisited as the workload grew over the following year. The underlying condition: nobody had a standing alert on subnet IP utilization, so the constraint was invisible until it was actively blocking autoscaling in production. The fix was twofold: an immediate non-disruptive subnet range expansion (confirmed not to collide with any neighboring subnet), and a new Cloud Monitoring alert on subnet IP utilization crossing 80%, so the next capacity ceiling would be caught weeks in advance instead of during an active incident.

Part 7 gcloud Cheat Sheet#

Pre-Flight Checklist: Is This Network Design Production-Ready?#

• Every production VPC is custom-mode, never the auto-created default VPC
• Firewall targeting uses Secure Tags, not plain network tags, for anything migrating to (or newly built on) Cloud NGFW policies
• The load balancer choice matches both the traffic's scope requirement and its actual layer (HTTP(S) vs. raw TCP/UDP)
• Compute resources needing outbound-only internet access use Cloud NAT, never a public IP granted "just in case"
• Subnet IP utilization has a standing Cloud Monitoring alert, not just a one-time sizing decision
• Any firewall migration between mechanisms was validated with real traffic logs before the old mechanism was removed

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: Meridian is migrating from classic VPC firewall rules (using network tags) to a Cloud NGFW network firewall policy. An engineer proposes simply copying each rule's network-tag targets directly into the new policy. Will this work, and if not, what has to change?

Answer: This won't work as-is. Cloud NGFW network firewall policies don't support plain network tags at all, only Secure Tags. Every resource that was targeted by a network tag needs to be tagged with an equivalent Secure Tag first, and the new policy rules must reference those Secure Tags instead of the original network tags; there's no direct syntax translation from one to the other.

Problem 2: Meridian needs a global, internet-facing HTTP(S) service with the lowest possible latency for users worldwide, and is deciding between the global external Application Load Balancer and the regional external Application Load Balancer with Premium Tier selected. Is there a meaningful difference, or are they equivalent once Premium Tier is chosen for both?

Answer: They're not equivalent. The global external Application Load Balancer uses a single global anycast IP with traffic entering Google's network at the point of presence closest to each user, then routing over Google's backbone to the nearest healthy backend, regardless of region. The regional external Application Load Balancer, even on Premium Tier, is inherently tied to one region's backends; a user far from that region still incurs the latency of reaching it, since there's no multi-region backend selection happening. For a genuinely global, latency-sensitive audience, the global load balancer remains the better fit.

Problem 3: A GKE cluster's node autoscaling silently stops adding new nodes during a load spike, with no error surfaced to the application layer, and the team eventually traces it to the subnet running out of available IP addresses. What preventive measure would have caught this before it became a production incident?

Answer: A Cloud Monitoring alert on the subnet's IP address utilization, set to fire well before exhaustion (80% utilization is a reasonable threshold), would have surfaced the constraint days or weeks in advance, giving the team time to expand the subnet's range (a non-disruptive operation, as long as the expansion doesn't collide with a neighboring subnet) before it became a hard capacity ceiling during an actual load event.

Summary and What's Next#

This chapter moved networking from Part 1's warning to avoid the default VPC through a fully deliberate design: custom-mode VPCs and Shared VPC, the shift from classic firewall rules to Cloud NGFW policies driven by Secure Tags rather than IP ranges or plain network tags, load balancer selection across scope and layer, Network Service Tiers, hybrid connectivity, and the operational subnet/IP/route management the exam's "ensuring successful operation" domain expects.

Part 8, the final chapter, covers monitoring, logging, and operations: Cloud Monitoring and Cloud Logging in depth, the diagnostic tools (Cloud Trace, Cloud Profiler, Query Insights) this course has referenced without fully explaining, and the newest additions to this domain, Personalized Service Health, Active Assist, and Cloud Hub.