Cloud Armor

1. What it defends

"Google Cloud Armor helps protect your Google Cloud deployments from threats such as distributed denial-of-service (DDoS) attacks and application attacks like cross-site scripting (XSS) and SQL injection (SQLi)."

Two layers of job in one product: volumetric/DDoS defence, and application-layer rule enforcement.

2. What it attaches to — the list, exactly

• external Application Load Balancers
• classic Application Load Balancers
• regional internal Application Load Balancers
• global external proxy Network Load Balancers
• regional external passthrough Network Load Balancers

This is not every load balancer type, and the gaps follow from the proxy/passthrough distinction (reference/networking/cloud-load-balancing.md §2): application-layer inspection needs a terminated connection. Check your chosen balancer against this list before promising WAF coverage — picking the balancer first and discovering the policy cannot attach is a rework of the whole front door.

3. The rules

The CRS version list is the detail to carry into a migration: a rule set tuned against CRS 3.3 on another platform maps directly, and one tuned against a vendor's proprietary managed rules does not map at all. It has to be re-derived from the traffic, and that is a measurement task with a lead time, not a configuration step.

Rate limiting is part of the security policy here, not a separate product and not an API-gateway feature. That is where to put a per-client request ceiling in front of a Google Cloud service.

4. An absence, recorded

The overview page read here does not name distinct policy classes — "backend security policy", "edge security policy", "network edge security policy" — as separate categories; it speaks of "security policies". Those class names appear elsewhere in Cloud Armor's documentation. This document does not assert them, because the page read does not. If a design depends on which policy class attaches where, read the security-policy reference.

5. For a migration

Cloud Armor is the counterpart of AWS WAF plus Shield and of Azure's WAF on Application Gateway or Front Door — Google's own cross-cloud table pairs it with "AWS WAF, Shield" and "Azure WAF, DDoS Protection". The mapping of names is clean; the mapping of rules is not, and the distinction matters:

• custom rules port with effort, because the expression languages differ but the intent is explicit;
• preconfigured/managed rules do not port — they are each vendor's own curation. Where both sides are CRS

based, the CRS version is the common ground. Where the source used proprietary managed rules, budget a tuning cycle with real traffic.

See guides/parity/networking.md §5.