Cloud Armor: DDoS Protection and WAF Rules for GCP Applications
A web application firewall (WAF) and DDoS protection sound like two separate concerns, but they’re solving the same underlying problem from opposite directions — one filters malicious individual requests (SQL injection, XSS payloads), the other filters malicious volume (a flood of otherwise-legitimate-looking requests designed to overwhelm your infrastructure). Cloud Armor is Google’s answer to both, implemented at the edge of Google’s global network, in front of your load balancer, before traffic ever reaches your actual application servers.
The “at the edge” part matters more than it sounds. Google’s network absorbs attack traffic at points of presence distributed globally, geographically close to where the traffic originates — by the time a volumetric attack would reach your actual backend infrastructure in a traditional single-datacenter setup, Cloud Armor has already filtered or absorbed most of it using Google’s own globally distributed network capacity, not yours.
Where Cloud Armor Sits in the Request Path
Internet traffic (legitimate + attack traffic mixed) │ ▼Google's global edge network (points of presence worldwide) │ ▼ Cloud Armor (WAF rules + rate limiting + DDoS filtering) │ ▼ HTTP(S) Load Balancer │ ▼ Backend service (Compute Engine, GKE, Cloud Run)This placement is only available for traffic passing through Google’s external HTTP(S) Load Balancer — Cloud Armor is not a general-purpose firewall for arbitrary traffic; it specifically protects load-balanced HTTP(S) and, with backend service extensions, TCP/SSL proxy traffic. Traffic that bypasses the load balancer entirely doesn’t get Cloud Armor’s protection, which is a common point of confusion during initial setup.
Security Policies and Rules
A Cloud Armor security policy is an ordered list of rules, each with a priority, a match condition, and an action:
gcloud compute security-policies create my-security-policy \ --description="Baseline WAF policy"
# Block a specific malicious IP rangegcloud compute security-policies rules create 1000 \ --security-policy=my-security-policy \ --src-ip-ranges="198.51.100.0/24" \ --action=deny-403
# Enable a pre-configured OWASP rule for SQL injection detectiongcloud compute security-policies rules create 2000 \ --security-policy=my-security-policy \ --expression="evaluatePreconfiguredExpr('sqli-stable')" \ --action=deny-403
# Default rule — allow everything not explicitly matched abovegcloud compute security-policies rules create 2147483647 \ --security-policy=my-security-policy \ --src-ip-ranges="*" \ --action=allowRules evaluate in priority order (lowest number first), and the first match wins — this ordering is worth being deliberate about, because a broad allow rule placed before a narrow deny rule silently defeats the deny rule entirely, a mistake that’s easy to make and non-obvious to debug from the outside.
Pre-Configured WAF Rules
Rather than writing custom detection logic for common attack patterns, Cloud Armor ships pre-configured rule sets mapped to the OWASP Top 10 and other known attack signatures:
┌──────────────────────┬────────────────────────────────────────┐│ Rule set │ Detects │├──────────────────────┼────────────────────────────────────────┤│ sqli-stable │ SQL injection patterns ││ xss-stable │ Cross-site scripting payloads ││ lfi-stable │ Local file inclusion attempts ││ rfi-stable │ Remote file inclusion attempts ││ rce-stable │ Remote code execution patterns ││ scannerdetection-stable │ Known vulnerability scanner signatures ││ protocolattack-stable │ Protocol-level anomalies │└──────────────────────┴────────────────────────────────────────┘Each rule set has a sensitivity level (1-4), trading detection breadth for false-positive rate — a higher sensitivity catches more attack variants but also flags more legitimate traffic incorrectly. Starting at a lower sensitivity in “preview” mode (logging matches without blocking) and reviewing what actually triggers before enforcing is the responsible rollout pattern, rather than enabling maximum sensitivity in blocking mode from day one and discovering false positives in production.
Rate Limiting: Handling Abusive but Not-Quite-Attack Traffic
A lot of real-world abuse doesn’t look like a classic DDoS attack — it’s a scraper hitting an API too aggressively, or a misconfigured client retrying in a tight loop. Rate limiting rules address this middle ground:
gcloud compute security-policies rules create 3000 \ --security-policy=my-security-policy \ --expression="true" \ --action=rate-based-ban \ --rate-limit-threshold-count=100 \ --rate-limit-threshold-interval-sec=60 \ --ban-duration-sec=600 \ --conform-action=allow \ --exceed-action=deny-429 \ --enforce-on-key=IPThis configuration allows up to 100 requests per IP per 60-second window; exceeding it triggers a temporary 10-minute ban, returning HTTP 429 for the duration. The enforce-on-key setting is worth understanding — keying by raw IP is the simplest option, but for traffic behind shared corporate NATs or CDNs, keying by a more specific signal (a session cookie, an API key header) avoids collateral-damage bans against legitimate users who happen to share an egress IP with an abusive one.
Adaptive Protection: ML-Based Anomaly Detection
Beyond static rules, Cloud Armor’s Adaptive Protection uses machine learning trained on your application’s normal traffic patterns to detect and alert on Layer 7 DDoS attacks that don’t match any predefined signature — a volumetric pattern that’s anomalous specifically for your traffic baseline, even if each individual request looks legitimate in isolation. It surfaces a suggested rule to mitigate the detected pattern, which a human reviews and can apply — a genuinely useful middle ground between fully manual rule-writing and blind automated blocking that risks false positives during a legitimate traffic spike (a product launch, a viral social media mention).
How a Rate-Limit Decision Actually Gets Made
It’s useful to see the decision path a single request goes through against a rate-limiting rule, since the “conform” vs “exceed” distinction trips people up in configuration reviews.
The distinction between a plain “deny the exceeding request” and a “ban” action matters operationally: a ban punishes every subsequent request from that key for the configured duration, even ones that would otherwise be well within limits, while a non-ban rate limit simply rejects requests over the threshold and re-evaluates fresh on the next window. Bans are the right tool for clearly abusive, sustained traffic; a simple threshold-deny is usually better for legitimate clients that occasionally burst over a limit and shouldn’t be locked out entirely for it.
Real-World Use Case: Protecting a Public API During a Launch
A company launching a public-facing API anticipates both legitimate traffic spikes and the increased attack surface that comes with public visibility. A practical Cloud Armor setup layers: geographic restriction rules if the API only serves specific regions, rate limiting scoped per API key rather than per IP (since legitimate high-volume customers share the same rate-limit concerns as abusive ones, but shouldn’t be penalized identically), OWASP rule sets in blocking mode for known injection patterns, and Adaptive Protection running in monitoring mode to catch anything the static rules miss. This layered approach reflects how real production security policies actually look — no single rule type covers every threat category, and treating Cloud Armor as “one WAF rule set to enable” undersells what the service is actually capable of.
Pricing Model
Cloud Armor charges per security policy and per rule, plus a per-request fee for requests evaluated against a policy — which means the cost scales with both configuration complexity and traffic volume. For high-traffic public applications, this is usually a small fraction of overall infrastructure cost relative to the value of avoiding a successful DDoS or injection attack, but it’s worth modeling explicitly rather than assuming it’s negligible at genuinely large scale.
Best Practices
- Start new rules in preview mode, reviewing logged matches before switching to enforcement — this is the single most effective way to avoid blocking legitimate traffic during rollout.
- Rate-limit by the most specific reasonable key available (API key, session token) rather than defaulting to raw IP, especially for APIs with authenticated clients.
- Layer defense rather than relying on one rule category. OWASP rules, rate limiting, and Adaptive Protection each catch different attack shapes — using only one leaves real gaps.
- Review Cloud Armor logs regularly, not just during an active incident — patterns in blocked traffic often reveal reconnaissance activity worth knowing about even when the attack itself never succeeds.
- Document why each custom rule exists. A security policy that accumulates one-off rules over months, without any record of the incident or reasoning that prompted each one, becomes genuinely risky to modify later — nobody wants to remove a rule they don’t understand, so the policy only ever grows.
Common Mistakes
Placing a broad allow rule before a specific deny rule. Because Cloud Armor evaluates in priority order with first-match-wins, rule ordering mistakes silently neutralize intended protections without any error or warning.
Enabling maximum WAF sensitivity in blocking mode immediately. This reliably generates false positives against legitimate traffic — starting in preview mode and tuning sensitivity based on real traffic is the safer path.
Assuming Cloud Armor protects traffic that bypasses the load balancer. Direct connections to a Compute Engine external IP, or traffic to a service not fronted by Google’s HTTP(S) Load Balancer, doesn’t receive Cloud Armor’s protection — architecture needs to route all public traffic through a protected load balancer for the coverage to be complete.
Frequently Asked Questions
Does Cloud Armor protect against all types of DDoS attacks? It’s strongest against volumetric and Layer 7 application-layer attacks, leveraging Google’s global network capacity. Google also offers Cloud Armor’s “Managed Protection Plus” tier with additional DDoS response support and financial protection guarantees for qualifying attacks.
Can Cloud Armor block traffic based on country of origin? Yes, geographic-based rules are a standard configuration, commonly used when an application legitimately only serves specific regions and traffic from elsewhere is almost certainly not a real customer.
Is Cloud Armor a replacement for application-level input validation? No — it’s a strong additional layer, not a substitute for validating and sanitizing input in your own application code. Defense in depth means both layers matter; relying entirely on a WAF to catch every injection attempt is a fragile assumption.
How does Cloud Armor handle encrypted (HTTPS) traffic inspection? Because Cloud Armor sits at the load balancer, which terminates TLS, it inspects the decrypted request content at that point — the WAF rules operate on the actual request data, not blindly on encrypted traffic.
Can I test a new rule’s impact before it affects real traffic? Yes — preview mode logs what a rule would have matched without actually blocking anything, which is the recommended way to validate a rule’s real-world false-positive rate against production traffic before flipping it to enforcement.
Does Cloud Armor work with internal (non-public) load balancers? Cloud Armor’s protection is specifically designed for external-facing load balancers, since its purpose is defending against internet-originated attacks. Internal traffic protection relies on different mechanisms — VPC firewall rules and IAM-based access control rather than a WAF.
Summary
Cloud Armor’s real value is operating at a layer individual application servers structurally can’t match — Google’s global edge network absorbing and filtering traffic before it ever reaches infrastructure you’re paying to scale. Getting real protection out of it means treating it as a layered system (WAF rules, rate limiting, adaptive detection) rather than a single switch, rolling new rules out in preview mode before enforcing, and remembering that it only protects traffic actually routed through a Cloud Armor-enabled load balancer. Skipping any of those three practices is how teams end up with a false sense of security from a service that’s technically enabled but not actually doing the job they assumed it was — a gap that usually only becomes visible during the incident it was supposed to prevent.