VPC Networks, Firewall Rules, and Load Balancing on Google Cloud

A VPC network is a global resource, while each of its subnets is a regional resource — this inversion of most on-premises models is the single most tested VPC fact. One VPC can contain subnets in every Google Cloud region, and instances in different regions on the same VPC communicate over internal IPs across Google's private backbone without any gateways or extra configuration.

VPCs come in two subnet modes. An auto mode VPC automatically creates one subnet per region from a predefined IP range, and new subnets appear as Google opens new regions. A custom mode VPC starts with no subnets; you create each one deliberately, choosing its region and its primary IPv4 range. Production guidance is clear: use custom mode. Auto mode ranges overlap with every other auto mode network, which blocks future VPC Network Peering and hybrid connectivity, and you cannot control where subnets exist. You can convert an auto mode VPC to custom mode, but never the reverse.

Creating a custom mode network and a subnet looks like this:

gcloud compute networks create prod-vpc --subnet-mode=custom
gcloud compute networks subnets create web-subnet \
  --network=prod-vpc --region=us-central1 \
  --range=10.10.0.0/24

Two planning details matter. First, you can expand a subnet's primary range without downtime, but you cannot shrink it — so leave growth room without being wasteful. Second, subnets can carry secondary ranges, which GKE uses for Pod and Service IPs; if GKE is in your design, plan those ranges up front.

Shared VPC and VPC Network Peering solve two different problems: Shared VPC lets multiple projects use one network, while peering lets two separate networks talk to each other. Exam questions love to blur this line.

Shared VPC designates a host project that owns the VPC and its subnets, and attaches service projects whose resources plug into those shared subnets. A central network team controls subnets, routes, and firewall policy in the host project, while application teams deploy Compute Engine instances or GKE clusters in their own service projects using the shared subnets. Everything communicates over internal IPs because it is genuinely one network. Shared VPC works only within a single organization, and it is the recommended pattern when you want centralized network administration with delegated application ownership.

VPC Network Peering connects two independent VPCs — in the same project, different projects, or even different organizations — so they exchange internal traffic privately without traversing the public internet. Each side keeps administering its own network. Two gotchas are heavily tested: peering is not transitive (if A peers with B and B peers with C, A cannot reach C), and peered networks cannot have overlapping IP ranges — another reason auto mode networks cause trouble. Both sides must create the peering before it becomes active.

Rule of thumb: one organization, central control — Shared VPC. Separate teams, separate orgs, or SaaS-style private connectivity between independently managed networks — VPC Network Peering.

VPC firewall rules filter connections to and from workloads, and every rule is defined by the same set of attributes: a direction (ingress or egress), an action (allow or deny), a priority (0 to 65535, where a lower number wins), a source (for ingress) or destination (for egress), a set of targets the rule applies to, and the protocols and ports it matches. Rules are stateful: if a connection is allowed in one direction, its return traffic is automatically allowed.

Every VPC ships with two implied rules you cannot delete: allow all egress, and deny all ingress, both at the lowest priority (65535). So instances can reach out by default, but nothing can reach in until you write an allow rule. The default network additionally pre-populates permissive rules such as allow-internal and allow-ssh — convenient for experiments, another reason production uses custom mode networks where you author every rule.

Ingress sources can be IP ranges, source tags, or source service accounts; targets can be all instances in the network, instances with a target tag, or instances running as a target service account. A classic pattern:

gcloud compute firewall-rules create allow-web-ingress \
  --network=prod-vpc --direction=INGRESS --action=ALLOW \
  --rules=tcp:443 --source-ranges=0.0.0.0/0 \
  --target-tags=web-server

To troubleshoot or audit, enable Firewall Rules Logging on a rule and inspect matches in Cloud Logging. When a question says traffic is unexpectedly blocked, check rule priority first — a high-priority deny beats any lower-priority allow.

Cloud Next Generation Firewall (Cloud NGFW) is the evolution of per-network firewall rules into firewall policies — containers of rules that can be managed centrally and attached at different levels. A hierarchical firewall policy attaches to an organization or folder and applies to every VPC beneath it; global network firewall policies and regional network firewall policies attach to a specific VPC. Evaluation flows from the hierarchy downward: organization and folder policies are evaluated before network-level policies and rules, which lets a security team enforce guardrails no project owner can override.

NGFW policy rules use the same core attributes — action, direction, source, destination, targets, protocols, ports — but with two more expressive targeting mechanisms. Secure Tags are IAM-governed key-value resources defined in Resource Manager: creating a tag and binding it to a VM each require IAM permissions, so only authorized principals can place a workload inside a firewall rule's scope. That is the critical contrast with legacy network tags, which are plain strings that anyone who can edit an instance can add — a privilege-escalation hole secure Tags close. NGFW policy rules match secure Tags for both targets and ingress sources.

Service accounts are the other strong identity signal: a rule can apply only to VMs running as a given service account, or allow ingress only from VMs running as one. Because changing a VM's service account requires stopping it and holding IAM permissions on that account, service-account-based rules are harder to subvert than tag-based ones and pair naturally with per-workload identities.

For the exam: firewall rules live on one VPC; firewall policies scale across the resource hierarchy; secure Tags and service accounts are the identity-aware way to scope NGFW rules.

Choosing a connectivity product comes down to what you are connecting and how much private, reliable bandwidth you need. Cloud VPN sends IPsec-encrypted traffic over the public internet; HA VPN deploys redundant interfaces and offers a 99.99% availability SLA when configured with the recommended tunnel pairs, and routes are exchanged dynamically over BGP via a Cloud Router. It is quick to set up and cheap, but throughput is bounded per tunnel and latency is at the internet's mercy.

Cloud Interconnect provides a private physical connection that bypasses the public internet. Dedicated Interconnect gives you your own 10 Gbps or 100 Gbps links from your router in a colocation facility; Partner Interconnect reaches Google through a supported service provider with capacities from 50 Mbps up to 50 Gbps — the answer when you cannot meet Google at a colocation facility or need less than 10 Gbps. Both offer availability SLAs when built with redundant attachments. Traffic on Interconnect is not encrypted by default, which questions occasionally probe.

VPC Network Peering is different in kind: it connects two VPC networks inside Google Cloud, not a VPC to an on-premises site.

A common exam pattern: start with HA VPN for speed of delivery, then migrate to Interconnect as bandwidth needs grow — the two can even run side by side, with VPN as an encrypted backup path.

Pick a Cloud Load Balancing product by answering three questions in order: what layer is the traffic (HTTP and HTTPS mean an Application Load Balancer; TCP, UDP, or other IP protocols mean a Network Load Balancer), who are the clients (internet-facing means external; clients inside your VPC or connected networks mean internal), and what scope do you need (one anycast IP serving backends in many regions means global; a single region means regional).

Application Load Balancers are proxy-based Layer 7 balancers: they terminate TLS, route on hostnames and URL paths, and integrate with Cloud CDN and Google Cloud Armor. The global external Application Load Balancer fronts worldwide users with a single anycast IP and picks the closest healthy backend region. Regional external and internal variants cover single-region and private HTTP(S) services.

Network Load Balancers come in two families. Proxy Network Load Balancers terminate TCP (optionally with TLS) at the edge and open a new connection to backends — useful for global TCP services. Passthrough Network Load Balancers forward packets without terminating the connection, preserving the client source IP, and support protocols beyond TCP such as UDP — the answer whenever a question mentions preserving client IPs or non-TCP traffic. Passthrough balancers are regional.

Deployment is the same skeleton regardless of flavor: create a health check, a backend service pointing at instance groups or network endpoint groups, any Layer 7 routing configuration, and a forwarding rule that holds the IP address.

Network Service Tiers decide how your traffic travels between the internet and Google Cloud. Premium Tier, the default, carries traffic on Google's private global backbone for as much of the journey as possible — packets enter and exit at the edge point of presence closest to the user (cold-potato routing), which delivers lower latency and higher consistency. Standard Tier hands traffic to the public internet close to the Google Cloud region hosting the workload (hot-potato routing), trading performance for lower egress pricing.

The tier choice constrains your architecture: global external load balancing and global anycast IPs require Premium Tier. On Standard Tier, external addresses are regional and you are limited to regional load balancer variants. Premium is also required for several networking features that ride the global backbone, so treat Standard as the deliberate cost optimization, not the default.

You can set a project-wide default tier and override it per resource — for example, keep Premium for the customer-facing global Application Load Balancer while assigning Standard to a batch VM that pushes bulk exports to a nearby destination. When an exam scenario emphasizes best global performance or a single anycast IP, answer Premium; when it emphasizes minimizing egress cost for a single-region, latency-tolerant workload, answer Standard.

Put the pieces together. A retailer runs its storefront on Google Cloud: web and API tiers on managed instance groups in us-central1 and europe-west1, a payments service that must stay private, an on-premises warehouse system that needs steady private connectivity today and roughly 5 Gbps within a year, and three application teams in separate projects under one organization.

The network team creates a custom mode VPC in a host project with subnets in both regions, plus GKE secondary ranges reserved for a future cluster, and enables Shared VPC so each team's service project deploys into centrally governed subnets. Traffic policy lives in a global network firewall policy: an ingress rule allows tcp:443 from the internet to workloads bound to the secure Tag role=web, a second rule allows the web tier to reach the payments backends only via their service account identity, and an organization-level hierarchical policy denies all RDP from the internet everywhere.

Users worldwide hit a global external Application Load Balancer on Premium Tier — one anycast IP, Cloud CDN for product images, Cloud Armor in front. The payments service sits behind an internal Application Load Balancer, unreachable from outside the VPC. For the warehouse, the team ships HA VPN with BGP over Cloud Router this quarter for the 99.99% SLA, and orders Partner Interconnect at 5 Gbps for the bandwidth milestone, keeping the VPN as an encrypted failover path. Every choice here maps to a decision rule from this lesson — which is exactly how the exam will test you.