Google Cloud offers several network and application security controls that are easy to collapse into the word “firewall.” VPC firewall rules and firewall policies govern network-layer traffic to and from workloads. Cloud Next Generation Firewall (Cloud NGFW) extends distributed firewalling with richer policy and advanced inspection capabilities. Cloud Armor protects supported internet-facing and load-balanced applications against web attacks and distributed denial-of-service threats at the edge.

For the Professional Cloud Security Engineer, the core skill is placing each control at the layer where it can see and enforce the relevant threat. A layer-3 or layer-4 rule cannot understand an SQL-injection payload in an HTTP request, while a web application firewall is not the right place to decide whether one internal subnet may reach an SSH service on another.

Start with the traffic layer and enforcement point

VPC firewall rules operate on network traffic associated with VPC resources and evaluate characteristics such as direction, protocol, ports, sources, destinations, and supported identity or tag selectors. Cloud NGFW builds on the same distributed enforcement model and adds capabilities such as centralized firewall policies, threat intelligence, intrusion prevention, URL filtering, FQDN objects, geolocation controls, and TLS inspection depending on the service tier and feature.

Cloud Armor is different because it protects supported services at Google’s edge and load-balancing layer. It can inspect HTTP requests, apply web application firewall expressions, enforce rate-based protections, and block or challenge unwanted clients before traffic reaches the application backend.

A defense-in-depth architecture can use all three. Cloud Armor filters hostile internet requests, Cloud NGFW or VPC firewall policy constrains network paths, and the application still performs authentication and authorization.

VPC firewall rules provide distributed stateful layer-3 and layer-4 filtering

VPC firewall rules are enforced in Google’s distributed network rather than by a customer-managed appliance placed in a subnet. Rules can allow or deny ingress or egress based on the supported match criteria and priority. The firewall is stateful for permitted connections, so return traffic for an established allowed flow is tracked without requiring a mirrored rule for every response packet.

Targets and sources should be based on the most stable identity available. Network tags can be useful, but service accounts or secure tags can express intent more strongly in supported policy designs because they relate policy to workload identity or centrally governed labels rather than just an address. IP ranges remain appropriate for external networks, fixed infrastructure segments, and protocols where identity selectors are not available.

Firewall policy should be least-privilege and explicit. Broad “allow internal” rules can turn an otherwise segmented VPC into a flat network. The general principles in firewall design still apply: permit the traffic the workload needs, log important decisions, and remove rules whose purpose is no longer known.

Firewall policies centralize governance beyond individual VPC rules

Google Cloud firewall policies allow organizations to manage rules centrally and apply them at different scopes. Hierarchical firewall policies can be associated with organization or folder resources so security requirements follow the resource hierarchy. Global and regional network firewall policies can provide centrally managed rules for VPC networks and supported targets.

This is valuable in large organizations because a security team can establish mandatory controls without editing every project independently. Application teams can still own narrower rules within the boundaries established by higher-level policy, depending on the policy design and evaluation order.

Centralization should not produce an unreadable rule base. Use consistent priorities, descriptive rule names, secure tags or other stable selectors, and logging for high-impact decisions. Periodically identify shadowed, redundant, expired, or overly broad rules so policy remains an operational security tool rather than an accumulated history of exceptions.

Cloud NGFW adds advanced network security capabilities

Cloud NGFW is Google’s managed next-generation firewall portfolio. The Essentials capabilities cover foundational distributed firewalling and policy management. Higher tiers add controls that can include FQDN-based policy, geolocation objects, threat-intelligence lists, intrusion prevention, URL filtering, TLS inspection, and advanced malware analysis features according to the selected tier and current regional availability.

The important architectural change is that teams can apply richer security controls without hairpinning all traffic through self-managed virtual firewall appliances. Policy remains integrated with Google’s network, while advanced inspection services can be inserted where supported.

That does not eliminate design work. Intrusion prevention requires deciding which traffic is inspected and how findings are handled. FQDN policy depends on name-resolution behavior. URL filtering applies at an application-aware layer. TLS inspection requires certificate trust, privacy review, workload compatibility, and careful exclusion rules for traffic that should not be decrypted.

Cloud Armor protects applications before requests reach the backend

Cloud Armor is designed for supported load-balanced applications and services. Security policies can allow or deny requests according to source information and request characteristics, apply preconfigured web application firewall rules, enforce custom expressions, and implement rate-based controls. Google also provides DDoS protections as part of the platform and enhanced capabilities through Cloud Armor service offerings.

This enforcement point is valuable because malicious traffic can be rejected at Google’s edge or load-balancing infrastructure rather than consuming application capacity. An HTTP attack can be evaluated using properties that a basic VPC firewall cannot see, such as request paths, headers, query parameters, or signatures associated with common web exploits.

Cloud Armor should still be tuned against the real application. Aggressive WAF rules can block legitimate requests, while permissive default rules can leave obvious attack paths exposed. Preview or staged evaluation, logging, and application-specific tests are important before broad enforcement changes.

Layer the controls instead of asking which firewall is best

Imagine an internet-facing application behind a Google Cloud Application Load Balancer. Cloud Armor can reject known malicious sources, abusive rates, and web-attack patterns at the frontend. The backend VMs or GKE nodes can still use VPC firewall policy to accept traffic only from the required load-balancer and health-check paths. Cloud NGFW can add network threat prevention for east-west or egress traffic where inspection is needed.

Those controls solve different problems and should not be used to imitate one another. Allowing the backend to accept the entire internet because “Cloud Armor is in front” weakens defense in depth. Trying to block SQL injection with only a TCP port rule asks the wrong layer to understand application content.

The Google Cloud security engineering mindset is therefore architectural: place controls where the needed context exists and preserve independent layers so one configuration mistake does not expose the whole application.

Encrypted traffic changes what inspection can understand

Encryption protects confidentiality, but it also hides application content from network inspection unless traffic is terminated or explicitly decrypted at an authorized inspection point. Cloud Armor can inspect HTTPS requests on supported proxy load balancers because TLS is terminated in the load-balancing path. A layer-3 or layer-4 firewall that sees only encrypted packets cannot evaluate the HTTP payload inside them.

Cloud NGFW TLS inspection can make selected encrypted flows available to supported advanced security services, but the operational implications are significant. Clients must trust the inspection certificates, privacy and compliance teams must approve decryption scope, certificate pinning or mutual TLS can affect compatibility, and sensitive destinations may require exclusions.

The goal is not to decrypt everything. It is to inspect traffic where the threat model and business requirement justify the loss of end-to-end opacity while maintaining strong controls around keys, certificates, logs, and administrative access.

Rule evaluation and logging should make decisions explainable

When several policy layers exist, troubleshooting can become difficult unless the organization knows which rule won. Record policy priority, target scope, source and destination selectors, and whether logging is enabled. Use firewall logs, load-balancer logs, Cloud Armor request logs, intrusion-prevention telemetry, and application logs together.

Do not change multiple layers during an incident without evidence. A timeout might be a VPC firewall denial, a routing problem, an unhealthy backend, or an application listener issue. An HTTP 403 might come from Cloud Armor, IAM-aware application logic, or the application itself. The status code and log source should guide the next check.

Policy testing should include both allowed and denied cases. Security controls are working only when legitimate traffic succeeds and prohibited traffic fails for the expected reason.

Governance should also distinguish preventive policy from detection and response. A deny rule can stop a known path, while intrusion-prevention alerts, Cloud Armor telemetry, and application logs can reveal attack behavior that does not yet justify a universal block. Security teams need a process for promoting repeated observations into policy, testing the change, and retiring temporary emergency rules after the incident.

That lifecycle prevents the firewall stack from becoming a permanent collection of incident artifacts. Every exception should have an owner, purpose, review date, and evidence that it remains necessary. The same principle applies to WAF exclusions and TLS-inspection bypasses: exceptions may be operationally required, but unmanaged exceptions gradually become the real security policy.

Use a policy stack that matches the threat model

Use VPC firewall rules or firewall policies for foundational network segmentation and least-privilege connectivity. Use Cloud NGFW when centralized network security needs richer objects or advanced inspection beyond basic layer-3 and layer-4 policy. Use Cloud Armor for edge, DDoS, rate-control, and web application protection on supported services.

Then keep application identity and authorization separate. A packet reaching an HTTPS frontend should not imply the user can read sensitive data. Network security controls reduce attack surface and inspect traffic; the application and service IAM model still decide what an authenticated principal may do.

The strongest design is layered but comprehensible: edge protection for hostile internet traffic, network policy for service-to-service paths, advanced inspection where risk justifies it, and application authorization for business actions. More rules are not automatically more secure. Clear ownership, narrow scope, current threat intelligence, tested failover, and explainable logs matter more than the number of products enabled.