Skip to main content
In this lesson we cover Cloud firewall rules in Google Cloud Platform (GCP): what they are, how they’re defined, and why they matter for data engineers. Firewalls act like digital bouncers for your virtual machines—deciding who can connect, who is blocked, and under what conditions. In GCP, firewall rules live in a VPC network and control traffic to and from instances in that VPC.
An infographic slide titled "Cloud Firewall Rules" showing a dashed boundary around server/database icons protected by a shield checkmark. To the right are three colored icons with labels: "Who gets in," "Who stays out," and "Under what conditions."
Why this matters for data engineers
  • When connecting to a database, message broker, or other data service, network teams will ask which ports, source CIDR ranges, or service accounts require access.
  • Knowing how VPC firewall rules work lets you provide precise requirements, speed up approvals, and troubleshoot connectivity issues faster.
An illustration titled "Why This Matters for Data Engineers" showing a person at a laptop with speech bubbles asking about ports and firewall rules, connected through a GCP cloud icon to a database icon.
Core concepts — how a firewall rule is defined When you create a firewall rule in a VPC you specify several properties. The table below summarizes each key field, what it controls, and an example.
ComponentWhat it controlsExample
DirectionWhether the rule inspects entering or leaving trafficINGRESS or EGRESS
ActionPermit or block matching trafficallow or deny
TargetsWhich instances the rule applies totarget-tags: db-server or instances with a specific service account
Source / DestinationWhere traffic originates (ingress) or goes (egress) — CIDR, tags, or service accounts--source-ranges 10.1.0.0/16
Protocols & portsProtocols (TCP/UDP/ICMP) and port ranges allowed or denied--allow tcp:5432
PriorityNumeric order for rule evaluation — lower = higher priority--priority 1000
  1. Direction
  • Ingress: traffic entering instances in the VPC (incoming).
  • Egress: traffic leaving instances in the VPC (outgoing).
  1. Action
  • Allow: permit the matching traffic.
  • Deny: block the matching traffic.
A presentation slide titled "Configuring VPC Firewall Rules" with a teal VPC cloud icon on the left. The slide lists two steps: "Define Rule Direction" (ingress/egress) and "Set Rule Action" (allow or deny traffic).
  1. Targets
  • Apply rules to:
    • All instances in the network (no target specification).
    • Instances with specific network tags (e.g., frontend, db-server).
    • Instances running under specific service accounts.
  • Use targets to scope rules only to the intended VMs and reduce blast radius.
  1. Source and destination
  • Specify where traffic comes from (for ingress) or goes to (for egress):
    • IP ranges using CIDR (e.g., 10.0.0.0/8, 0.0.0.0/0).
    • Source tags or service accounts (useful for internal VPC communications).
  • This controls which systems are allowed to talk to each other.
  1. Protocols and ports
  • Specify allowed or denied protocols (TCP, UDP, ICMP) and port ranges.
  • Common examples:
    • tcp:5432 for PostgreSQL
    • tcp:22 for SSH
  1. Priority
  • Numeric value where lower numbers have higher priority.
  • GCP evaluates rules starting with the lowest numeric priority and stops when a matching rule explicitly allows or denies the traffic. If multiple matching rules share the same priority, DENY rules take precedence over ALLOW rules.
When creating or requesting firewall changes, be ready to provide: direction, action, targets (tags or service accounts), source/destination ranges, allowed/denied protocols and ports, and the desired priority.
Example: allow inbound PostgreSQL (TCP 5432) from a specific CIDR to VMs tagged db-server 
gcloud compute firewall-rules create allow-postgres-ingress \
  --network my-vpc \
  --direction INGRESS \
  --priority 1000 \
  --allow tcp:5432 \
  --source-ranges 10.1.0.0/16 \
  --target-tags db-server \
  --description "Allow Postgres from internal network to db servers"
Common best practices and tips
  • Principle of least privilege: allow only the ports and source ranges that are required.
  • Prefer network tags or service accounts for targets (instead of broad all-instances rules).
  • Use specific CIDR ranges; avoid 0.0.0.0/0 unless absolutely necessary and documented.
  • Use priorities to ensure more specific rules take effect before broad ones.
  • Test changes in a staging VPC before applying to production.
Be cautious when using 0.0.0.0/0 as a source or destination. Broad exposure increases security risk—document and justify any open ranges.
Notes on permissions and organizational roles
  • Many organizations restrict who can create or modify firewall rules. Data engineers often need to request changes from network or cloud operations teams.
  • Providing a clear, minimal set of requirements reduces back-and-forth and speeds approvals:
    • Which ports and protocols (e.g., tcp:5432)
    • Source CIDR(s) or source tags/service accounts
    • Target tags or service account for the VM(s)
    • Direction (INGRESS/EGRESS)
    • Desired priority and a short description
Troubleshooting checklist
  • Confirm the VM has the expected network tag or service account.
  • Verify the rule priority and whether another rule is blocking traffic.
  • Check that the GCE instance-level firewall (iptables) or application firewall isn’t blocking traffic.
  • Use gcloud compute firewall-rules list and gcloud compute firewall-rules describe <NAME> to inspect rules.
  • Test connectivity with telnet <host> <port> or nc -vz <host> <port> from an allowed source.
References and further reading That covers the essentials of VPC firewall rules and why they matter for data engineers. Understanding these elements will help you design secure connections between your data sources and sinks. That concludes this article.

Watch Video