Cloud Firewall

Cloud Firewall on Google Cloud is not one product but a family of layers stacked on top of each other. The foundation is the stateful VPC firewall rules covered on the previous page. On top sit Network Firewall Policies, Hierarchical Firewall Policies for org-wide guardrails, and at the top tier Cloud Next-Generation Firewall (NGFW) — a managed firewall service with L7 inspection, intrusion prevention, and TLS decryption.

For most production workloads, basic VPC rules are not enough. The hierarchy separates a default-allow free-for-all from an enterprise security posture, and the right NGFW tier catches threats that traditional L3/L4 rules cannot see.

VPC Rules vs Network Firewall Policies

Network Firewall Policies are the modern replacement for legacy VPC firewall rules. They support the same allow/deny actions and the same matching criteria — priorities and target service accounts exist in both models — with several capabilities VPC rules lack: rules grouped into a single policy object you can attach, reuse, and audit as a unit; IAM-governed secure tags instead of freeform network tags; both global and regional scope for blast-radius control; and the goto_next action that is the building block of layered policies.

Hierarchical Firewall Policies

Hierarchical Firewall Policies apply at the organization or folder level and evaluate before any VPC-level or network policy. They are the right place for security guardrails that must be true everywhere: "no SSH from public internet," "no outbound traffic to high-risk geographies," "deny inter-project traffic by default." Owners of individual projects cannot weaken these guardrails — they can only add more permissive rules below them, which the hierarchy already rejected. Use hierarchical policies as the org-wide security baseline; reserve network policies and VPC rules for application-specific allow lists.

Rule Evaluation Order

Traffic evaluation walks down the hierarchy in this order: hierarchical policies at the organization level, then folder level; then — in the default configuration — VPC firewall rules; then network firewall policies at the global scope, then regional scope. (A per-network setting can move network policies ahead of VPC rules; check which order your VPC uses before debugging.) At each layer, the highest-priority matching rule wins. A goto_next action explicitly defers to the next layer.

The most common "I allowed it but the connection is still blocked" debugging session is caused by an earlier-evaluated rule — usually a forgotten hierarchical deny — terminating evaluation before the application-level allow rule fires. Check the top of the hierarchy first.

Cloud NGFW Tiers

Cloud Next-Generation Firewall has three tiers stacked on the same policy infrastructure. Essentials is included by default — stateful L3/L4 inspection, the rules engine described above. Standard adds threat intelligence feeds (malicious IP lists, Tor exit nodes, geolocation filters) and FQDN-based filtering, billed by the volume of traffic evaluated (per GiB). Enterprise adds L7 inspection, intrusion prevention (IPS) with managed signature databases, and TLS inspection. Enterprise is the most expensive tier; reserve it for workloads where compliance or threat profile genuinely requires the visibility.

Threat Intelligence and IDS

Threat intelligence in Standard and Enterprise tiers uses managed feeds that Google updates automatically: known-malicious IP addresses, Tor exit nodes, anonymizing proxies, and country-level geo blocks. Apply them as a coarse first-line filter — they catch obvious bad actors before any other rule runs. Watch the false-positive rate, especially on geo blocks: VPN concentrators and CDN edges sometimes land in unexpected regions and break legitimate traffic.

TLS Inspection

TLS Inspection (Enterprise tier only) decrypts HTTPS traffic at the firewall, applies L7 rules, then re-encrypts before forwarding. You upload a CA certificate pool that clients trust; the firewall mints leaf certificates on the fly. This gives genuine visibility into encrypted traffic — and creates real obligations: certificate lifecycle management, compliance and legal review of decrypting end-user traffic, and operational overhead when applications pin certificates. Enable it deliberately, not by default.

Firewall Insights and Logs

Firewall Insights analyzes rule usage and surfaces problems: shadowed rules (higher-priority rules cover them, so they never fire), overly permissive rules, and rules with zero hits over a long window. Review the recommendations quarterly. Firewall logs (off by default) record allow and deny decisions; enable them on rules near public boundaries and leave them off on high-volume internal allow rules where the log noise overwhelms the signal.