--- cuppy_hub: gcp cuppy_path: reference/networking/cloud-armor.md cuppy_section: docs cuppy_doc: 0R8V-400D cuppy_doc_uuid: 730e872f-b318-4d8d-89a1-8f4df58cc520 cuppy_permalink: https://cuppy.io/gcp/d/0R8V-400D cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/gcp/docs/reference/networking/cloud-armor cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 4ca4bb83f26bb2da1eab2e3a4435d8fd92bec7c59128a04b3e9937d9e0db58c6 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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 | | | |---|---| | custom rules | the **"Cloud Armor custom rules language"** | | preconfigured WAF rules | based on the **OWASP ModSecurity Core Rule Set (CRS)**, versions **4.22, 3.3 and 3.0** | | also named | **Adaptive Protection** and **rate limiting** | 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. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.