Build GCP VPC firewall rules with priority, direction, and target configuration.
Last verified: May 2026
Lowercase letters, numbers, and hyphens only (1-63 chars)
0 (highest) to 65535 (lowest). Default is 1000.
Output will appear here...The builder walks you through each component of a GCP firewall rule (direction, priority, action, target type, source/destination, protocol/ports) and assembles them into a rule definition. It generates output in three formats: gcloud CLI command, Terraform google_compute_firewall resource, and gcloud beta compute network-firewall-policies for the newer hierarchical firewall model. Each output includes inline comments explaining the priority and target choices.
GCP VPC firewall rules control traffic to and from instances based on direction, priority, protocol/port combinations, and target/source specifiers like network tags, service accounts, or IP ranges. Unlike AWS security groups, GCP firewall rules are defined at the VPC network level and use a priority system (0-65535, lower wins) that determines which rule takes effect when multiple rules match the same traffic. This builder provides a structured form for specifying direction, priority, targets, sources/destinations, and protocol/port pairs, generating valid gcloud commands or Terraform configuration for deployment.
Your team needs to allow a new monitoring agent to scrape metrics from 200 production instances. The naive approach is to tag every instance with 'monitoring-target' and create an allow rule, but that requires modifying every instance's tags. Instead, you use the builder to create a rule targeting the existing 'prod-app-sa' service account as destination, with the monitoring instance's service account as source. Zero instance changes, instant rollout, and the rule is pinned to identity rather than mutable metadata.
Always use service account-based targeting over network tags for production. Tags are mutable by anyone with compute.instances.setTags, which is a privilege escalation vector if your IAM model allows engineers to modify instance metadata but not firewall rules. Service account targets are immutable per VM and managed through IAM.
Leave priority gaps when building rule sets. Use 1000, 2000, 3000 instead of 1000, 1001, 1002. When you need to insert an exception rule next month, you can drop it in at 1500 without renumbering anything. Sequentially-numbered rule sets always become a refactor headache.
GCP firewall rules are evaluated *per-NIC*, not per-VM. A multi-NIC instance picks up rules based on the network each NIC is attached to, so a permissive rule on one VPC doesn't grant access via a NIC on another VPC. Map this carefully when designing east-west connectivity.
Service accounts are more secure because they are managed through IAM and cannot be modified by instance administrators. Network tags can be changed by anyone with compute.instances.setTags permission, which means a compromised instance could potentially add tags to gain access to additional firewall rules. Google recommends service account-based targeting for production workloads and uses network tags primarily for development environments or simpler configurations.
GCP firewall rules use explicit numeric priority (0-65535) where lower numbers take precedence. The default rules have priority 65534-65535. When multiple rules match, only the highest-priority (lowest number) rule applies. AWS Security Groups have no priority concept — all rules are evaluated together, and traffic is allowed if any rule matches. GCP's priority system allows you to create exception patterns (a specific allow at priority 900 overriding a broad deny at priority 1000) that are not possible with AWS Security Groups.
Every GCP VPC network has two implied firewall rules that cannot be deleted: an implied allow-all egress rule (priority 65535) and an implied deny-all ingress rule (priority 65535). This means all outbound traffic is allowed by default, and all inbound traffic is denied unless you create explicit allow rules. You can override these implied rules by creating rules at higher priority (lower numbers). The default network also includes pre-populated rules allowing internal traffic, SSH, RDP, and ICMP.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.