Cloud Armor placement scenarios — Global vs Regional vs PA-only

Inbound HTTPS :443 → VM, with NSI / Palo Alto in the consumer VPC. Switch tabs to compare where the WAF sits and how traffic flows.
Ready
Reading the diagram: each solid link is bi-directional — the request travels one way and the response returns the SAME path (proxy load balancer). The numbered badge on each hop matches the numbered step on the right. During Start / Auto-Play, a yellow packet + arrow = the request going out; a blue packet + reverse arrow = the response coming back.

Config vs. traffic: The dashed CONFIG boxes (Backend service, NEG) are control-plane objects owned/billed by the service project — they are NOT places packets travel through. The load-balancer proxy just reads them (dotted purple line) to pick a target, then forwards straight to the VM inside the consumer VPC. Traffic does not detour into the service project and come back. Inspection (NSI → Palo Alto) happens because the VM sits on the host's Shared VPC subnet, where the ingress firewall policy fires.

Four distinct planes (verified from code): the EDGE host (hanuraiq-net-host-* (legacy), existing) owns the ALB+Cloud Armor; the NonProd consumer (hanuraiq-nonprod-host-001) holds the VMs; the Net-Sec project (hanuraiq-netsec-nonprod-001) holds the PA fleet. Separately, Shared-Services (hanuraiq-shared-host-001: DNS, CI/CD runners, zScaler connector) is a fourth project and is deliberately NOT NSI-inspected (D-08, to avoid a fail-closed DNS/CI-CD/PA-mgmt deadlock) — it is not on this ingress path.
Request path — Internet → VM :443
Side-by-side — Global CA vs Regional CA vs PA-only (all with NSI/PA)
All three share the same in-VPC NSI/Palo Alto inspection. They differ only in the north-south web WAF layer at the edge.