100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
GCP

Subnets and Firewall Rules

Learn how GCP subnets divide a VPC's IP address space by region, and how stateful, priority-based firewall rules control what traffic is allowed in and out of your instances.

NetworkingBeginner10 min readJul 10, 2026
Analogies

Subnets: Carving Up a VPC's IP Space

A subnet is a regional range of IP addresses carved out of your VPC for a specific purpose, such as hosting web servers in us-central1 or database instances in europe-west1. Each subnet has a primary CIDR range for the resources' main internal IPs, and can optionally have secondary ranges used for things like GKE pod and service IP allocation via alias IP ranges. Choosing subnet sizes deliberately upfront matters because expanding a subnet's primary range later is possible but only by widening it (never shrinking), and you cannot resize a range in a way that would overlap another subnet.

🏏

Cricket analogy: This is like a franchise dividing its squad quota across departments: so many slots for batters, so many for bowlers, planned before the auction rather than improvised mid-season when slots run out.

How Firewall Rules Work in GCP

GCP firewall rules are stateful, attached to the VPC network (not individual subnets), and evaluated per VM instance based on network tags, service accounts, or all instances in the network. Every rule has a direction (ingress or egress), an action (allow or deny), a priority from 0 to 65535 (lower number means higher priority), and a target defined by tags or service accounts. Because rules are stateful, a response to an allowed inbound connection is automatically permitted outbound without needing a matching egress rule, and vice versa.

🏏

Cricket analogy: This is like an umpire applying the same LBW law consistently to every batter at the crease, checking specific conditions like impact and pitch of the ball each time, not the venue.

Implied and Priority-Based Rule Evaluation

Every VPC has two implied rules that cannot be removed: an implied allow for all egress traffic and an implied deny for all ingress traffic, both at the lowest possible priority (65535). This means that by default, nothing can reach your VM instances from outside, and you must explicitly create ingress allow rules for anything you want to permit, such as allowing TCP port 22 from a specific IP range for SSH, or TCP port 443 from all sources for a public web server. When multiple rules could apply to the same traffic, GCP evaluates them in priority order and the highest-priority (lowest number) matching rule wins.

🏏

Cricket analogy: This is like a fielding captain's default instinct to keep the field spread defensively unless a specific match situation, like a set batter needing a wicket, calls for an aggressive change.

bash
# Deny-all ingress exists by default; explicitly allow SSH from a bastion range only
gcloud compute firewall-rules create allow-ssh-from-bastion \
  --network=prod-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=10.0.5.0/28 \
  --target-tags=ssh-allowed \
  --priority=1000

# Allow HTTPS from the internet only to instances tagged 'web-server'
gcloud compute firewall-rules create allow-https-web \
  --network=prod-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web-server \
  --priority=1000

Network tags on firewall rules are not a strong security boundary by themselves: any user with permission to set instance metadata can add a tag like 'web-server' to a VM they control, potentially exposing it to rules meant for other instances. For stronger isolation, target firewall rules by service account instead of tags, since service accounts require explicit IAM permission to attach to an instance.

Subnet-Level Controls: Private Google Access and Flow Logs

Beyond IP ranges, subnets carry two important operational settings. Private Google Access lets VM instances that only have internal IP addresses reach Google APIs and services, like Cloud Storage or BigQuery, without needing an external IP or a NAT gateway. VPC Flow Logs, enabled per subnet, capture a sample of network flows to and from instances in that subnet, which is invaluable for security auditing, troubleshooting connectivity issues, and understanding traffic patterns between services.

🏏

Cricket analogy: Private Google Access is like a player getting direct access to the team's video analysis room without needing to leave the stadium, while flow logs are like the match's ball-by-ball commentary archive for later review.

  • Subnets are regional slices of a VPC's IP space, with primary and optional secondary ranges.
  • Subnet primary ranges can only be expanded, never shrunk, and must never overlap other subnets.
  • Firewall rules attach to the VPC and are evaluated per instance using tags or service accounts, not per subnet.
  • Every VPC has an implied deny-all ingress and implied allow-all egress rule at the lowest priority.
  • Lower priority numbers win when multiple firewall rules match the same traffic.
  • Service-account-based firewall targeting is stronger than tag-based targeting because tags can be self-assigned by anyone with metadata permissions.
  • Private Google Access and VPC Flow Logs are configured per subnet and support secure API access and traffic visibility respectively.

Practice what you learned

Was this page helpful?

Topics covered

#GCP#GCPFundamentalsStudyNotes#CloudComputing#SubnetsAndFirewallRules#Subnets#Firewall#Rules#Carving#Security#StudyNotes#SkillVeris