Cloud Armor
Cloud Armor is the web application firewall and DDoS protection that sits at Google's edge, in front of external Application Load Balancers. We touched on it in the Cloud Load Balancing chapter; this page is the deep dive. The mental model: every request to a public-facing app hits Google's network before it ever reaches your origin; Cloud Armor evaluates the request against a policy and either passes it through, blocks it, or rate-limits the source.
Cloud Armor is often confused with Cloud Firewall (Chapter 4). They are not alternatives. Cloud Firewall protects east-west and north-south traffic inside the VPC at L3 and L4. Cloud Armor protects public-facing web traffic at L7 at Google's edge. You usually need both; one is not a substitute for the other.
Edge WAF and DDoS Protection
DDoS protection at Google's scale is the headline feature non-engineering buyers care about: a 100 Gbps attack hits Google's edge, not your origin. Volumetric L3/L4 DDoS protection is on by default for any service behind an external Application LB; you do not configure it, it just works.
The WAF layer is what teams actually configure. Cloud Armor security policies attach to backend services on the LB; each policy contains an ordered list of rules that match request attributes and either allow, deny, or rate-limit. Rules can match by IP range, geography, custom CEL expressions on request attributes (headers, paths, query parameters — the request body is inspectable only through the preconfigured WAF rules), or by membership in a managed signature set.
Pre-Configured Rules (OWASP)
The pre-configured rule sets are the fastest path to baseline WAF coverage. The OWASP Top 10 categories — SQL injection, XSS, RCE, LFI, RFI, command injection, scanner detection, protocol attack, session fixation — each have a managed rule set that Google updates as attack patterns evolve. Attach the OWASP rules in preview mode first, observe what they flag on real production traffic for a week or two, tune the sensitivity to match your application's actual usage, then promote to enforce mode. Skipping the preview step is the single most common cause of "Cloud Armor blocked our legitimate users" incidents.
Custom Expressions
For application-specific rules, Cloud Armor accepts Common Expression Language (CEL) expressions matching arbitrary request attributes. Examples: block requests where request.headers['user-agent'].contains('badbot'); deny POST to /admin/* from outside corporate IP ranges; rate-limit by origin.ip when the path matches /api/expensive-operation. The expression language is rich enough for most rules teams want; complex policies are best built by combining many narrow rules in priority order rather than one mega-expression.
Rate Limiting at Edge
Edge rate limiting absorbs spikes before they reach your origin. Configure throttling per IP, per HTTP header value (like a user-id header or API token), or per arbitrary CEL key. Two modes: throttle (allow burst, then deny the excess — typically with a 429) and rate-based ban (block the source entirely for a window once the threshold is crossed). Rate limiting is the cheapest defense against L7 abuse — every public endpoint that does meaningful work should have a sensible rate limit.
Adaptive Protection
Adaptive Protection is the ML-based component that learns each backend's normal traffic patterns and detects evolving attacks the static rules miss. When an anomaly fires, Adaptive Protection suggests a specific Cloud Armor rule (with a confidence score and a CEL expression) that you can adopt with one click — note the full attack signatures and suggested rules require a Cloud Armor Enterprise subscription; the standard tier gets only basic anomaly alerts. The right pattern for production: Adaptive Protection in detection mode generates suggestions, an on-call engineer reviews them within hours during an attack, suggested rules get promoted to enforce. The fully-automated mode is available but most teams operate it human-in-the-loop because false positives in enforce mode are user-visible.
Cloud Armor vs Cloud Firewall
Different layers, different threats, complementary.
Cloud Armor — L7 protection at Google's edge, in front of external Application Load Balancers. WAF rules, rate limiting, DDoS, geo-based filtering, Adaptive Protection. Public-facing web traffic only.
Cloud Firewall — L3/L4 protection inside the VPC. Stateful rules on traffic between VMs, between subnets, in and out of the VPC. Network-level access control across all traffic, not just web.
Defense in depth uses both. Edge WAF stops the obvious public-facing attacks; in-VPC firewall constrains lateral movement if anything gets through.
- Treating Cloud Armor as a substitute for Cloud Firewall. Cloud Armor is L7 at the edge; Cloud Firewall is L3/L4 inside the VPC. You need both.
- Enabling new OWASP rules or custom rules directly in enforce mode without a preview-mode evaluation period. Legitimate users get 403s; the team scrambles to identify the bad rule under outage pressure.
- No rate limiting on public endpoints that do meaningful work. A trivial L7 attack or a runaway client floods your backend with traffic the edge could have absorbed.
- Aggressive geo blocks that catch CDN exit points, VPN concentrators, and corporate egress IPs. Legitimate users from those geos get blocked, and the support tickets are unspecific enough that the cause stays hidden for days.
- Adaptive Protection disabled or in fully-automated enforce mode without human review. The first means missing the ML signal; the second means false positives become outages.
- Cloud Armor rules without logging enabled. The team cannot answer "which rule blocked this request" during an incident.
- Cloud Armor security policy on every external Application LB. Baseline OWASP rules in preview mode for two weeks, then enforce.
- Rate limiting per IP (and per user where a user header exists) on every public endpoint. Tune to match real usage; conservative is better than the default of none.
- Adaptive Protection enabled with detection-mode suggestions reviewed by an on-call engineer; promote to enforce only after a review window.
- Logging enabled on every rule. The log line is what lets you debug false positives.
- Pair Cloud Armor with Cloud Firewall for defense in depth. Edge WAF for public-facing threats; in-VPC firewall for lateral movement constraints.
- Geo blocks tested against your actual user geography. Allow-list known-good infra IPs (CDN edges you depend on, partner endpoints) before broad geo rules.
Knowledge Check
How does Cloud Armor relate to Cloud Firewall?
- They are two names for the same product; Cloud Armor is the rebranded edge-aware successor that replaced Cloud Firewall in the modern console
- They protect different layers — Cloud Armor is L7 at Google's edge for public-facing web traffic; Cloud Firewall is L3/L4 inside the VPC for network-level access. You typically need both.
- Cloud Armor fully replaces Cloud Firewall for any VM workload sitting behind an external Application Load Balancer with a public address
- Cloud Armor exclusively handles all outbound egress filtering for the entire VPC, while Cloud Firewall is strictly limited to inspecting inbound ingress requests arriving from the public internet
Why should new OWASP or custom Cloud Armor rules be deployed in preview mode first?
- Preview mode is the only mode that records request logs to Cloud Logging; enforce mode runs completely silent
- To observe what the rules flag on real production traffic and tune sensitivity before enforcing — skipping preview is the most common cause of "Cloud Armor blocked our legitimate users" incidents
- Cloud Armor rules require a mandatory seven-day observation soak in preview mode by Google platform policy before they become eligible for promotion to active enforcement on the external load balancer
- Preview mode is required for the rules to take effect at Google's edge rather than being evaluated at the backend instances
What does edge rate limiting protect against?
- Volumetric L3 and L4 network-layer DDoS floods, which is precisely the high-bandwidth attack scenario that per-client edge rate limiting was originally designed to absorb and shed before backends notice
- L7 abuse and runaway clients — flooding traffic to a public endpoint is absorbed at Google's edge rather than reaching the backend, which is the cheapest defense available
- SQL injection payloads aimed at application backends, throttled once the request count crosses a set threshold
- Brute-force authentication attempts against Cloud Identity logins by validating the submitted credentials at the edge
What does Adaptive Protection do that static OWASP rules do not?
- Automatically negotiates a fair rate-limit ceiling with each offending source IP, adjusting the per-client threshold up or down dynamically based on that client's observed past request behavior over time
- Learns each backend's normal traffic patterns and detects evolving anomalies the static rules miss — suggesting specific CEL rules an on-call engineer can review and promote
- Generates refreshed OWASP rule sets every quarter by parsing newly published CVE feeds and threat advisories
- Replaces the entire static rule engine with one consolidated ML-based rule that captures every known attack pattern
A team enables aggressive geo blocking on their Cloud Armor policy and starts receiving customer complaints from legitimate users in the allowed countries. What is the typical cause?
- Geo blocks evaluate the destination TCP port number rather than the resolved source country, so the rule silently never matched the intended traffic at all
- CDN exit points, VPN concentrators, and corporate egress IPs sometimes route through unexpected countries; the geo rule blocks them, and the affected users do not know enough to mention the VPN in their support ticket
- Cloud Armor's underlying geolocation database carries a documented 90-day refresh lag, so recently redrawn or disputed country boundaries are not yet reflected in any of the geo rule matches until the next scheduled sync runs
- Geo blocks have a hard dependency on Adaptive Protection being enabled; without it, the rules fall back to denying all inbound traffic
You got correct