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. Because a subnet spans its whole region, VMs in every zone of that region can use the same subnet: you add a subnet only when you need a new region (or a separate range), never per zone.

VPCs come in two subnet modes. An auto mode VPC automatically creates one subnet per region from the fixed block 10.128.0.0/9, 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. Every auto mode network uses the same ranges, so two auto mode networks can never be peered with each other, and the block can collide with on-premises addressing; you also cannot control where subnets exist. You can convert an auto mode VPC to custom mode (its existing subnets keep their ranges), but never the reverse — and conversion does not fix an overlap, so resolving one means rebuilding a network in custom mode with unique ranges.

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

Primary ranges, expansion, and secondary ranges

A VM's primary internal IP address always comes from its subnet's primary range. When a subnet runs out of addresses you can expand the primary range in place, for example from /24 to /23:

gcloud compute networks subnets expand-ip-range web-subnet \
  --region=us-central1 --prefix-length=23

Expansion is non-disruptive — existing VMs keep their addresses and are not recreated — but it is one-way: you can never shrink a range afterwards, and the larger range must not overlap any other subnet in the network (or in peered networks). Leave growth room without being wasteful.

Subnets can also carry secondary IPv4 ranges. These supply alias IP addresses for things running on a VM, such as containers; they do not provide VMs' primary addresses, so adding a secondary range does not help a subnet that has run out of room for new VMs. Their best-known consumer is a VPC-native GKE cluster: nodes take their addresses from the subnet's primary range, Pods from one secondary range and Services from another secondary range of the same subnet (newer GKE versions can instead allocate Service addresses from a Google-managed range if you do not name one). If GKE is in your design, plan those ranges up front so they do not overlap anything you will connect later.

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 administers subnets, routes, and firewall rules in the host project, while application teams deploy Compute Engine instances or GKE clusters in their own service projects. Each service project keeps its own IAM, billing, and quotas — only the network is shared — and everything communicates over internal IPs because it is genuinely one network. Shared VPC works only within a single organization.

Two IAM roles make it work. A Shared VPC Admin (roles/compute.xpnAdmin, granted at the organization or folder) enables host projects and attaches service projects. Service project users who create VMs need the Compute Network User role (roles/compute.networkUser) in the host project — either on the whole host project, which lets them use every current and future shared subnet, or on individual subnets, which limits them to exactly those subnets. Granting it per subnet is the least-privilege choice when, say, developers may use a dev subnet but must not place anything in a prod subnet. Granting roles in the service project does nothing for the shared network.

VPC Network Peering connects two independent VPCs — in the same project, different projects, or even different organizations — so they exchange internal traffic privately over Google's network, with no gateways, tunnels, or extra hops. Each side keeps administering its own network, and both sides must create the peering before it becomes active. Peered networks cannot have overlapping subnet ranges — the reason two auto mode networks cannot be peered.

Peering is non-transitive — and how transit to on-premises works

Peering is not transitive: if a hub peers with spoke A and with spoke B, A and B cannot reach each other through the hub. Routes a network learns from one peering are never re-exported to another peering, so the fix for spoke-to-spoke traffic is a direct peering between the spokes (or a different design, such as Shared VPC).

Peering exchanges subnet routes automatically, but custom routes — static routes and dynamic routes learned by Cloud Router over VPN or Interconnect — cross a peering only when you ask: the exporting side enables export custom routes and the importing side enables import custom routes. That is how a spoke peered with a hub reaches on-premises through the hub's HA VPN: the hub exports its learned on-premises routes, the spoke imports them, and the hub's Cloud Router uses a custom route advertisement to announce the spoke's subnet ranges to the on-premises router, which would otherwise not know them. You cannot shortcut this with a static route in the spoke pointing at the hub's tunnel — a route's next hop must be in the route's own network.

gcloud compute networks peerings update hub-to-spoke \
  --network=hub --export-custom-routes
gcloud compute networks peerings update spoke-to-hub \
  --network=spoke --import-custom-routes

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: once a connection is allowed in one direction, its return traffic is automatically allowed — so an egress deny-all does not break responses to inbound connections an ingress rule already allowed.

How rules are evaluated

For each connection, the matching rule with the lowest priority number decides the outcome. If an allow rule and a deny rule both match at the same priority, the deny wins. Nothing else breaks ties: how specific a rule's source, ports, or targets are, and the order in which rules were created, have no effect. So a broad deny at priority 1000 blocks traffic that a narrow allow at priority 1000 also matches; to let the allow win, give it a lower number.

Implied rules and the default network

Every VPC has two implied rules you cannot delete: allow all egress and deny all ingress, both at the lowest priority (65535). Instances can reach out by default, but nothing can reach in until you write an allow rule. A new custom mode network has only these. The default network, created with every new project unless an organization policy prevents it, also gets prepopulated ingress rules at priority 65534:

These apply to every instance in the network. HTTP and HTTPS are not open by default: ticking the Allow HTTP or HTTPS traffic boxes when creating a VM in the console adds the http-server or https-server network tag and creates a matching rule that targets only VMs with that tag. Internet-wide SSH and RDP are one more reason production uses custom mode networks where you author every rule.

Sources and targets

Ingress sources can be IP ranges, source network 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 network tag is a plain string that anyone allowed to edit an instance can add, so a tag-targeted rule can be extended to an unrelated VM by whoever edits it. A service account target is harder to subvert: changing a VM's service account requires stopping the VM and holding IAM permission to use that account. VPC firewall rules support network tags and service accounts but not secure Tags — those belong to Cloud NGFW policies (next sections). 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 traffic is unexpectedly blocked or allowed, list every rule that matches it and compare priorities — and remember that hierarchical firewall policies can decide traffic before any VPC rule is consulted.

Three access paths come up constantly, and each needs specific rules or settings beyond the implied ones.

SSH through Identity-Aware Proxy

IAP TCP forwarding lets administrators SSH or RDP to VMs that have no external IP address, without opening those ports to the internet. Two things are required: an ingress firewall rule allowing the port (for example tcp:22) from IAP's forwarding range 35.235.240.0/20 to the target VMs, and the IAP-secured Tunnel User role (roles/iap.tunnelResourceAccessor) for the administrators on the project or the specific VMs. Users still need the usual permission to log in to the VM, such as an OS Login role. Connect with gcloud compute ssh VM_NAME --tunnel-through-iap. No external IP, Cloud NAT, or bastion host is involved.

Private Google Access and egress rules

Private Google Access lets VMs that have only internal IP addresses reach Google APIs and services such as Cloud Storage. It is a per-subnet setting, so two subnets of the same network can behave differently; VMs with external IPs do not need it.

gcloud compute networks subnets update batch-subnet \
  --region=us-central1 --enable-private-ip-google-access

Two conditions often trip people up. First, the network needs a route to the Google API destinations whose next hop is the default internet gateway; the default 0.0.0.0/0 route provides this, so if you delete it you must add custom routes (next hop default internet gateway) for the destinations your VMs actually use. With the default domain names, *.googleapis.com resolves to Google's public API addresses, so those ranges need the route. To use the smaller private.googleapis.com (199.36.153.8/30) or restricted.googleapis.com (199.36.153.4/30) ranges instead, you also configure DNS, typically a Cloud DNS private zone, so that *.googleapis.com resolves to that range; a route alone does nothing if names still resolve to the public addresses. The traffic still stays on Google's network. Second, API traffic is ordinary egress and still obeys egress firewall rules. To block the internet but keep Google APIs, allow egress to the Google API ranges at a lower priority number than an egress rule that denies 0.0.0.0/0. The reverse order denies everything.

Load balancer health checks and proxies

Google Cloud health check probes come from 35.191.0.0/16 and 130.211.0.0/22, so backends behind most load balancers need an ingress rule allowing those ranges on the serving port. Proxy-based regional load balancers also need a rule allowing their proxy-only subnet (see Choosing and deploying load balancers).

Cloud Next Generation Firewall (Cloud NGFW) organises firewall rules into firewall policies — containers of rules that can be managed centrally and attached at different levels. A hierarchical firewall policy is associated with the organization or a folder (not with an individual project) and applies to every VPC in every current and future project beneath it. Global network firewall policies and regional network firewall policies are associated with a specific VPC network. This is how a security team enforces guardrails that project owners cannot override.

NGFW policy rules use the same core attributes — direction, action, source, destination, targets, protocols, ports — with two differences. Inside one policy each rule has a unique priority, evaluated lowest number first, so there are no ties. The actions are allow, deny, goto_next, and apply_security_profile_group (used for Layer 7 inspection).

Evaluation order and goto_next

Traffic is evaluated level by level. By default the order is:

1. The organization's hierarchical firewall policy.
2. Folder hierarchical policies, from the top folder down to the project's folder.
3. The network's VPC firewall rules.
4. The global network firewall policy, then the regional network firewall policy.
5. The implied rules.

This default enforcement order is called AFTER_CLASSIC_FIREWALL. Setting a network's enforcement order to BEFORE_CLASSIC_FIREWALL moves the network firewall policies ahead of the VPC firewall rules. Hierarchical policies always come first either way.

At any level, a matching allow or deny is final: nothing lower is evaluated. So an allow in a folder policy lets traffic through even if a VPC rule in the project denies it at a far lower priority number — priorities only compete within a policy or within the VPC rules. A matching goto_next rule hands the decision to the next level, and traffic that matches no rule in a policy also continues down. To let a folder or project decide about a port that a catch-all deny would otherwise block, add a goto_next rule for it at a lower priority number than the catch-all deny; placed after the deny, it would never be reached.

Secure Tags and service accounts

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 network tags, which are plain strings that anyone who can edit an instance can add. Hierarchical, global, and regional network firewall policies all support secure Tags as rule targets and as ingress sources; VPC firewall rules do not.

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. Service-account rules work in both VPC firewall rules and NGFW policies and pair naturally with per-workload identities.

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. It is quick to set up and cheap, but throughput is bounded per tunnel and latency depends on the internet.

HA VPN and the 99.99% SLA

HA VPN is a regional gateway with two interfaces, each with its own external IP address. It uses dynamic routing only: a Cloud Router runs BGP sessions over the tunnels to exchange routes. HA VPN carries a 99.99% availability SLA on the Google Cloud side when both interfaces have a tunnel to the peer. The peer can be two devices, one device with two IP addresses, or even a single device with a single public IP address — in that last topology each HA VPN interface runs a tunnel to the same peer IP, and the Google Cloud side still qualifies for 99.99% (the peer device itself remains a single point of failure on your side). A gateway with only one interface's tunnel configured gets no 99.99% SLA. Classic VPN, the older single-interface gateway, has a 99.9% SLA.

Cloud Interconnect

Cloud Interconnect provides private connectivity that does not traverse the public internet, with availability SLAs when built with redundant connections. There are three options:

• Dedicated Interconnect: your own physical circuits between your router and Google's network in a colocation facility where Google has a presence. Circuits are 10, 100, or 400 Gbps, and you can bundle several for more capacity.
• Partner Interconnect: reach Google through a supported service provider, with capacities from 50 Mbps to 50 Gbps per attachment. Choose it when you cannot meet Google in a colocation facility or need less than a full circuit.
• Cross-Cloud Interconnect: dedicated physical links between Google Cloud and another cloud provider (such as AWS, Microsoft Azure, or Oracle Cloud Infrastructure), for private multicloud traffic.

Traffic on Interconnect is not encrypted by default. Questions sometimes test this.

VPC Network Peering is different in kind: it connects two VPC networks inside Google Cloud, not a VPC to an on-premises site. A peered spoke can still reach on-premises through a hub's VPN or Interconnect by exchanging custom routes (see Shared VPC and VPC Network Peering).

A common pattern: start with HA VPN for speed of delivery, then add Interconnect as bandwidth needs grow. The two can 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 and route requests with a URL map by host name and path to different backend services. The global external Application Load Balancer serves worldwide users from a single anycast IP that sends each client to the nearest Google edge with healthy backend capacity, and integrates with Google Cloud Armor and Cloud CDN. Cloud CDN works only with the global external Application Load Balancer and the classic Application Load Balancer. 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 proxy and open a new connection to backends. The global external proxy Network Load Balancer gives a non-HTTP TCP service one anycast IP and terminates connections at the edge closest to each client. Passthrough Network Load Balancers forward packets without terminating the connection, preserving the client source IP, and support protocols beyond TCP such as UDP. Passthrough balancers are regional.

Which load balancers show the client's IP?

Proxy-based load balancers (all Application Load Balancers and proxy Network Load Balancers) open their own connection to the backend, so the backend sees the proxy's address as the packet source. The client IP is passed along in the X-Forwarded-For HTTP header (Application Load Balancers) or in an optional PROXY protocol header (proxy Network Load Balancers). Only passthrough Network Load Balancers deliver packets whose source address is the original client.

Deploying one

Deployment uses the same skeleton for every type: create a health check, a backend service pointing at instance groups or network endpoint groups, any Layer 7 routing configuration (URL map and target proxy), and a forwarding rule that holds the IP address. Backends need an ingress firewall rule for the health-check ranges 35.191.0.0/16 and 130.211.0.0/22.

Regional proxy-based load balancers, including the regional internal Application Load Balancer, also need a proxy-only subnet. This is a dedicated subnet in the same region and VPC network, created with purpose REGIONAL_MANAGED_PROXY, and the load balancer's proxies draw their addresses from it. Two consequences follow. Backends see connections from the proxy-only range, so they need an ingress allow rule from that range on the serving port, in addition to the health-check rule. And the load balancer's own forwarding-rule IP comes from a regular subnet, never the proxy-only subnet.

gcloud compute networks subnets create proxy-only-us-east1 \
  --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE \
  --network=prod-vpc --region=us-east1 --range=10.129.0.0/23

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 external load balancers, such as the regional external Application Load Balancer, the regional external proxy Network Load Balancer, and the external passthrough Network Load Balancer. Treat Standard as a 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 a scenario emphasizes best global performance or a single anycast IP, Premium fits; when it emphasizes minimizing egress cost for a single-region, latency-tolerant workload whose users are near the region, Standard fits.

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 non-overlapping subnets in both regions, plus GKE secondary ranges reserved for a future cluster, and enables Shared VPC. Each team gets Compute Network User only on the subnets it should use. 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. Administrators reach VMs through IAP TCP forwarding instead of public SSH.

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 with its proxy-only subnet, 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.