Professional Cloud Network Engineer

Configuring Google Cloud Armor Policies

Edge Security and Web Application Firewall Protection

Google Cloud Armor delivers distributed denial-of-service (DDoS) defense and web application firewall (WAF) capabilities at the Google network edge before traffic enters a private cloud network. Security policies attach directly to backend services of external application load balancers, filtering inbound web requests closest to the user. A Cloud Armor security policy contains prioritized rules that evaluate incoming Layer 7 traffic against IP address ranges, geographic regions, request headers, and preconfigured WAF rule sets like the OWASP Top 10 vulnerabilities. When an incoming request matches a rule, the policy executes an action to allow, deny with a specific HTTP status code, or rate-limit the client.

[ Internet Client ] ---> [ Google Edge / Cloud Armor Policy ] ---> [ External Load Balancer ] ---> [ Backend VMs ]
                               (Inspect & Filter L7)

Policy Evaluation and Rule Actions

A Google Cloud Armor security policy evaluates rules in ascending numerical order, stopping as soon as a request matches a rule's conditions. If a request does not match any custom rule, it encounters the default rule at priority 2,147,483,647, which is usually set to deny or allow all remaining traffic. Administrators can place rules into preview mode to log what action would have taken place in Cloud Logging without actually dropping or throttling live user traffic. Rate-limiting rules track connection counts from individual client IP addresses, redirecting or blocking abusive users who exceed set request thresholds over a defined time window.

Configuring and Managing NGFW Policies and VPC Firewall Rules

Hierarchical, Network, and Regional Firewall Policies

Google Cloud Next Generation Firewall (Cloud NGFW) policies and standard Virtual Private Cloud (VPC) firewall rules control bidirectional Layer 3 and Layer 4 traffic across cloud network interfaces. Security policies follow a strict evaluation hierarchy:

• Hierarchical firewall policies apply at the organization and folder levels, evaluating before any network-level rules to enforce broad organizational guardrails.
• Global network firewall policies apply across an entire VPC network, grouping reusable rules for consistent enforcement across all regions.
• Regional network firewall policies apply to specific Google Cloud regions inside a VPC network, allowing regional compliance and isolation.
• VPC firewall rules represent the legacy rule model that applies directly to a single VPC network and evaluates after higher-level policies.

[ Organization Policy ] -> [ Folder Policy ] -> [ Network Policy ] -> [ Regional Policy ] -> [ Legacy VPC Rules ]
                                     (Evaluation Order: Top to Bottom)

Advanced Threat Prevention and Identity-Based Targeting

Cloud NGFW Enterprise integrates intrusion prevention system (IPS) capabilities directly into the VPC network to detect and prevent malware, spyware, and command-and-control attacks. Instead of relying only on static IP address ranges, firewall rules use service accounts and secure tags to dynamically apply access controls to virtual machine (VM) instances. Secure tags are managed at the organization level through Identity and Access Management (IAM), preventing VM administrators from changing their own firewall boundaries by modifying local network tags. Traffic inspection occurs distributed across the virtualization layer, eliminating the need to re-route internal network packets through separate hardware choke points.

Configuring and Securing Internet Egress Traffic Using Public Cloud NAT and Secure Web Proxy

Outbound Network Address Translation with Public Cloud NAT

Public Cloud NAT provides managed outbound internet connectivity for private Compute Engine VMs and Google Kubernetes Engine (GKE) nodes that do not possess public IP addresses. Outbound packets travel from the private subnet to the Public Cloud NAT gateway, which maps the internal IP address and port to a regional external IP address before forwarding the traffic to the internet. The gateway automatically tracks connection states so that inbound response packets return directly to the originating private instance, while unsolicited inbound connections from the internet remain blocked. Public Cloud NAT supports both automatic IP allocation, where Google Cloud provisions IP addresses dynamically, and manual IP allocation for environments that must provide fixed egress IP addresses to external firewalls.

[ Private Subnet VM ] ---> [ Public Cloud NAT Gateway ] ---> [ Public Internet ]
  (Private IP Only)          (Translates Private to Public)

Layer 7 Egress Filtering with Secure Web Proxy

Secure Web Proxy is a managed, cloud-first service that inspects and enforces security policies on outbound web traffic (HTTP and HTTPS) leaving a VPC network. Private VMs send their web traffic to the Secure Web Proxy endpoint without needing an external IP address or complex routing configurations. The proxy evaluates outbound requests against security policies based on source identities, fully qualified domain names (FQDNs), URL paths, and request headers. When Transport Layer Security (TLS) inspection is enabled, Secure Web Proxy decrypts the encrypted payload using a private Certificate Authority, checks the cleartext contents against security rules, and re-encrypts the traffic before sending it to the destination web server.

Configuring Self-Managed Network Virtual Appliance and Packet Mirroring

Network Virtual Appliance Routing and High Availability

A network virtual appliance (NVA) is a third-party virtual machine that performs specialized routing, deep packet inspection, or unified threat management between network boundaries. NVAs typically connect to multiple VPC networks using multiple network interface cards (multi-NIC), creating a clear boundary between an untrusted public-facing subnet and a trusted internal subnet. To provide high availability, multiple NVA instances sit behind an Internal Passthrough Network Load Balancer configured as a next hop in a VPC custom route. The internal load balancer uses health checks to detect failing appliances and distributes symmetric traffic evenly across healthy NVAs without altering the original packet headers.

[ Untrusted VPC ] ---> [ Internal Load Balancer (Next Hop) ] ---> [ Active NVA Pool ] ---> [ Trusted Internal VPC ]

Out-of-Band Traffic Inspection with VPC Packet Mirroring

VPC Packet Mirroring clones raw network packets from selected VM instances and forwards them out-of-band to a designated collector instance without disrupting production traffic. The packet mirroring policy defines the traffic source by subnet, network tag, or instance name, and applies optional packet filters based on IP protocol, CIDR ranges, and direction. The mirrored copy of each packet travels to an Internal TCP/UDP Load Balancer that distributes the mirrored stream across a pool of security monitoring tools or intrusion detection systems (IDS). Because packet mirroring runs entirely within the hypervisor layer, it captures all matching packets regardless of whether local firewall rules allow or deny the original traffic.

Key Facts

• Google Cloud Armor policies attach to external application load balancers at the network edge to block Layer 7 web attacks and mitigate distributed denial-of-service (DDoS) traffic before it enters a Virtual Private Cloud (VPC).
• Hierarchical firewall policies evaluate before global, regional, or legacy VPC firewall rules, enabling organization administrators to enforce non-negotiable security boundaries.
• Public Cloud NAT enables private virtual machines to initiate outbound Layer 3 and Layer 4 internet connections while preventing unsolicited inbound connections from reaching those instances.
• Secure Web Proxy inspects outbound Layer 7 HTTP and HTTPS traffic using fully qualified domain names, URL paths, and optional TLS decryption without requiring external IP addresses on source instances.
• VPC Packet Mirroring copies full Layer 3 network packets directly from the hypervisor to an internal collector pool without adding latency or modifying the original production traffic path.

Frequently Asked Questions

What is the difference between Public Cloud NAT and Secure Web Proxy?

Public Cloud NAT operates at Layer 3 and Layer 4 to allow private instances to initiate outbound connections to the internet by translating IP addresses and ports. Secure Web Proxy operates at Layer 7 to inspect, filter, and log outbound HTTP and HTTPS web requests based on domain names, URLs, and TLS certificates.

How does the evaluation order work between hierarchical firewall policies and VPC firewall rules?

Hierarchical firewall policies created at the organization level evaluate first, followed by policies at the folder level, global network firewall policies, and regional network firewall policies. Legacy VPC firewall rules evaluate last, meaning a higher-level hierarchical rule that blocks traffic will stop the packet before any local VPC rule is considered.

Why would an architecture use an Internal Load Balancer as a next hop for Network Virtual Appliances?

An Internal Passthrough Network Load Balancer configured as a next hop allows multiple Network Virtual Appliances to operate in an active-active, highly available pool. The load balancer monitors appliance health and automatically reroutes traffic away from failed instances while maintaining symmetric connection paths.

Does VPC Packet Mirroring affect production application latency or drop blocked packets?

VPC Packet Mirroring does not add latency to production traffic because the packet copying occurs asynchronously in the hypervisor. It captures all matching traffic traversing the virtual interface, including packets that are subsequently dropped by local firewall rules.