Cloud Armor: WAF Rules, DDoS Protection, and Rate Limiting

In 2023, a major e-commerce platform lost $2M in 30 minutes because their rate limiting was based on IP alone — attackers rotated through a botnet of 10,000 residential proxies. Cloud Armor could have stopped that with adaptive rate limiting and fingerprinting. Most teams treat WAF as a checkbox: enable OWASP rules, set a few IP blocks, and call it done. That's like locking your front door but leaving the windows open. Cloud Armor is not just a firewall; it's a programmable edge security layer that can inspect requests, enforce complex logic, and scale to absorb multi-terabit DDoS attacks. This article walks through building production-grade WAF rules, configuring DDoS protection, and implementing rate limiting that actually works — with real code, real failure modes, and no fluff.

Understanding Cloud Armor's Architecture

Cloud Armor operates at the edge of Google's network, before traffic reaches your backend. It integrates with External HTTP(S) Load Balancers and Cloud CDN. Policies are evaluated in order: first, preconfigured WAF rules (e.g., OWASP), then custom rules, then rate limiting. Each rule has a priority (lower number = higher priority). If a rule matches, the action (allow, deny, redirect, rate limit) is taken. If no rule matches, the default is to allow. This is critical: if you misconfigure priorities, you might accidentally allow malicious traffic. For example, a deny rule with priority 1000 might be overridden by an allow rule with priority 999. Always plan your rule numbering with gaps (e.g., 1000, 2000, 3000) to insert new rules later. Cloud Armor also supports edge security policies for Cloud CDN, which can block traffic before it even reaches the load balancer.

gcloud compute security-policies create prod-waf-policy \
    --description "Production WAF policy"

gcloud compute security-policies rules create 1000 \
    --security-policy prod-waf-policy \
    --expression "evaluatePreconfiguredExpr('sqli-stable')" \
    --action deny-403 \
    --description "Block SQL injection"

gcloud compute security-policies rules create 2000 \
    --security-policy prod-waf-policy \
    --expression "evaluatePreconfiguredExpr('xss-stable')" \
    --action deny-403 \
    --description "Block XSS"

Preconfigured WAF Rules: OWASP Top 10 Protection

Cloud Armor offers preconfigured rule sets for common attack vectors: SQL injection (sqli-stable), cross-site scripting (xss-stable), local file inclusion (lfi-stable), remote file inclusion (rfi-stable), and more. These are maintained by Google and updated regularly. To use them, you write a rule with evaluatePreconfiguredExpr('rule-set-name'). You can also use versioned rules (e.g., sqli-v0.9-ea) for early access. Important: these rules are evaluated against the request body, headers, and query parameters. However, they can produce false positives. For example, a blog post about SQL might trigger the SQLi rule if it contains the word 'SELECT'. To mitigate, you can use the 'request.headers' or 'request.path' in your expression to narrow scope. Also, you can set the action to 'throttle' instead of 'deny' to slow down suspicious traffic instead of blocking it outright. Always test preconfigured rules in a staging environment with real traffic before enabling in production.

gcloud compute security-policies rules create 3000 \
    --security-policy prod-waf-policy \
    --expression "evaluatePreconfiguredExpr('sqli-stable') || evaluatePreconfiguredExpr('xss-stable')" \
    --action deny-403 \
    --description "Block SQLi and XSS"

gcloud compute security-policies rules create 4000 \
    --security-policy prod-waf-policy \
    --expression "evaluatePreconfiguredExpr('lfi-stable')" \
    --action deny-403 \
    --description "Block LFI"

Custom WAF Rules with CEL Expressions

Cloud Armor uses Common Expression Language (CEL) for custom rules. CEL is a simple, fast expression language that can inspect request attributes like IP, headers, path, query parameters, and even geolocation. For example, you can block requests from a specific country, require a custom header, or match a regex pattern. CEL expressions are evaluated in a sandboxed environment with limited functions. You can use boolean operators (&&, ||, !), string functions (startsWith, contains, matches), and IP functions (inIpRange). One powerful pattern is to block requests that don't have a specific User-Agent header, which can stop many automated scanners. However, be careful: blocking based on User-Agent can also block legitimate clients like curl. A better approach is to allow known good User-Agents and deny everything else. Also, you can use the 'request.headers' map to access any header. For example, to block requests without a valid API key: !has(request.headers['x-api-key']) || request.headers['x-api-key'] != 'expected-value'.

gcloud compute security-policies rules create 5000 \
    --security-policy prod-waf-policy \
    --expression "origin.region_code == 'CN' && request.path.startsWith('/admin')" \
    --action deny-403 \
    --description "Block China IPs from /admin"

gcloud compute security-policies rules create 6000 \
    --security-policy prod-waf-policy \
    --expression "!has(request.headers['x-forwarded-for']) && request.path.matches('^/api/') " \
    --action deny-403 \
    --description "Block API calls without X-Forwarded-For"

Rate Limiting: Beyond Simple IP Throttling

Cloud Armor's rate limiting can be based on IP, IP range, or even custom keys like a session cookie or API key. You define a rate limit rule with a threshold (e.g., 100 requests per minute) and an action (deny or throttle). Throttling slows down requests instead of blocking them, which is useful for APIs. However, IP-based rate limiting is easily bypassed by botnets. A better approach is to use a combination of IP and a fingerprint like User-Agent or a custom header. For example, you can rate limit based on the 'x-session-id' header. But beware: if an attacker can spoof that header, they can bypass the limit. For production, consider using Cloud Armor's 'enforceOnKey' feature with a key like 'http-request-cookie' or 'http-request-header'. Also, you can set a 'rateLimitThreshold' per minute and a 'conformAction' for requests that exceed the limit. Always set a 'banDurationSec' to temporarily block offenders. A common pattern is to allow 100 requests per minute, then throttle for 10 minutes, then ban for 1 hour.

gcloud compute security-policies rules create 7000 \
    --security-policy prod-waf-policy \
    --expression "true" \
    --action rate-based-ban \
    --rate-limit-threshold-count 100 \
    --rate-limit-threshold-interval-sec 60 \
    --conform-action allow \
    --exceed-action deny-429 \
    --enforce-on-key IP \
    --ban-duration-sec 3600 \
    --description "Rate limit: 100 req/min per IP, ban 1 hour"

DDoS Protection: Google's Edge Defense

Cloud Armor includes Google's global DDoS infrastructure, which can absorb attacks up to multiple Tbps. This is always-on and requires no configuration. However, you can fine-tune protection with 'threat intelligence' rules that block known malicious IPs from Google's threat database. You can also enable 'Adaptive Protection' which uses machine learning to detect anomalous traffic patterns and automatically generate rules. Adaptive Protection is especially useful for application-layer DDoS attacks that mimic legitimate traffic. It learns your normal traffic profile over 24 hours and then flags deviations. When enabled, it can create a suggested rule that you can review and apply. For volumetric attacks, Cloud Armor automatically drops traffic at the edge. But for application-layer attacks, you need to configure rules. A common mistake is to rely solely on Cloud Armor's DDoS protection without setting up rate limiting or WAF rules. DDoS protection is a layered approach: network-layer is automatic, application-layer needs your rules.

gcloud compute security-policies update prod-waf-policy \
    --enable-adaptive-protection

gcloud compute security-policies rules create 8000 \
    --security-policy prod-waf-policy \
    --expression "evaluateThreatIntelligence('google-threat-intel')" \
    --action deny-403 \
    --description "Block known malicious IPs from Google Threat Intelligence"

Logging and Monitoring: Visibility is Key

Cloud Armor logs all requests that match a rule (allow or deny) to Cloud Logging. You can also enable 'enforceOnKey' logging for rate limiting. To get meaningful insights, export logs to BigQuery and create dashboards in Looker Studio. Key metrics: deny rate, top blocked IPs, top blocked paths, and rate limit triggers. Set up alerts for sudden spikes in deny rate, which could indicate an attack. Also, monitor false positives: if a legitimate endpoint is being blocked, you need to adjust rules. Cloud Armor also integrates with Cloud Monitoring for metrics like 'blocked_requests' and 'throttled_requests'. Use these to create alerting policies. A common mistake is not logging enough: by default, only denied requests are logged. Enable logging for allowed requests as well to understand your traffic baseline. But beware of costs: logging all requests can be expensive. Use sampling or filter to log only specific rules.

gcloud compute security-policies update prod-waf-policy \
    --enable-logging

gcloud logging metrics create cloud-armor-deny-rate \
    --description "Deny rate from Cloud Armor" \
    --log-filter 'resource.type="http_load_balancer" AND jsonPayload.@type="type.googleapis.com/google.cloud.loadbalancer.type.LoadBalancerLogEntry" AND jsonPayload.enforcedSecurityPolicy.action="deny"' \
    --metric-type "cumulative"

Testing and Deploying WAF Rules Safely

Before deploying a new rule to production, test it in a staging environment with mirrored traffic. Cloud Armor supports 'preview' mode: you can create a rule with action 'preview' that logs what would have happened without actually blocking. This is invaluable for testing. Also, use the Cloud Armor policy simulator to test individual requests. For rate limiting, you can set a low threshold temporarily to see if it triggers on legitimate traffic. Another technique: deploy rules with a 'throttle' action first, then switch to 'deny' after confirming no false positives. Always have a rollback plan: keep a copy of the previous policy and be ready to apply it. Use infrastructure as code (e.g., Terraform) to manage policies, so you can version control and rollback easily. Never edit a policy directly in the console in production — it's too easy to make a typo.

resource "google_compute_security_policy" "waf" {
  name        = "prod-waf-policy"
  description = "Production WAF policy"

  rule {
    action   = "deny(403)"
    priority = 1000
    match {
      expr {
        expression = "evaluatePreconfiguredExpr('sqli-stable')"
      }
    }
    description = "Block SQL injection"
  }

  rule {
    action   = "rate_based_ban"
    priority = 7000
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["0.0.0.0/0"]
      }
    }
    rate_limit_options {
      conform_action = "allow"
      exceed_action  = "deny(429)"
      rate_limit_threshold {
        count        = 100
        interval_sec = 60
      }
      enforce_on_key = "IP"
      ban_duration_sec = 3600
    }
    description = "Rate limit per IP"
  }
}

Advanced: Geolocation and IP Reputation Rules

Cloud Armor can use geolocation (origin.region_code) and IP reputation (evaluateThreatIntelligence) to block traffic from high-risk regions or known malicious IPs. For example, you might block all traffic from countries where you don't do business. However, be careful: attackers can use VPNs to appear from allowed regions. IP reputation rules use Google's threat intelligence to block IPs known for scanning, phishing, or malware. These are updated in real-time. You can also use custom IP lists (e.g., from your own threat feeds) by creating a 'security policy with a list of IPs'. For geolocation, you can allow only specific countries or block specific ones. A common pattern: allow all traffic, but apply stricter rate limiting to high-risk countries. For example, allow 100 req/min from US, but only 10 req/min from other countries. This can be done with multiple rules and priorities.

gcloud compute security-policies rules create 9000 \
    --security-policy prod-waf-policy \
    --expression "origin.region_code != 'US' && origin.region_code != 'CA'" \
    --action rate-based-ban \
    --rate-limit-threshold-count 10 \
    --rate-limit-threshold-interval-sec 60 \
    --conform-action allow \
    --exceed-action deny-429 \
    --enforce-on-key IP \
    --ban-duration-sec 3600 \
    --description "Strict rate limit for non-US/CA traffic"

gcloud compute security-policies rules create 10000 \
    --security-policy prod-waf-policy \
    --expression "evaluateThreatIntelligence('google-threat-intel')" \
    --action deny-403 \
    --description "Block known malicious IPs"

Integrating with Cloud CDN and Load Balancers

Cloud Armor policies are attached to backend services or target proxies of External HTTP(S) Load Balancers. You can also attach them to Cloud CDN's edge security policies. When attached to CDN, rules are evaluated at the edge before the CDN cache, which can block attacks before they hit your origin. However, CDN edge policies have fewer features (e.g., no rate limiting). For full protection, attach the policy to the load balancer's backend service. You can also use multiple policies: one at the CDN edge for basic filtering, and one at the load balancer for deeper inspection. A common architecture: use Cloud CDN with an edge security policy that blocks known bad IPs and geos, and then a more comprehensive WAF policy on the backend service. This reduces load on the WAF and improves performance.

gcloud compute backend-services update my-backend-service \
    --security-policy prod-waf-policy \
    --global

gcloud compute backend-buckets update my-cdn-bucket \
    --edge-security-policy edge-waf-policy \
    --global

Cost Optimization: Balancing Security and Budget

Cloud Armor pricing is based on the number of policies, rules, and requests evaluated. Each policy has a monthly cost, and each rule adds a small cost. Additionally, you pay per million requests evaluated. To optimize costs: consolidate rules into fewer policies, use preconfigured rules instead of custom ones when possible, and enable logging selectively. Also, consider using 'throttle' instead of 'deny' for some rules — throttled requests still incur evaluation costs but may reduce backend costs. Another tip: use Cloud Armor's 'preview' mode sparingly in production, as it logs all requests and can increase logging costs. For high-traffic sites, costs can add up. Monitor your Cloud Armor usage in the billing console and set budgets. A common mistake is to create many fine-grained rules that each cost money. Instead, combine conditions using OR (||) in a single rule.

gcloud compute security-policies rules create 11000 \
    --security-policy prod-waf-policy \
    --expression "evaluatePreconfiguredExpr('sqli-stable') || evaluatePreconfiguredExpr('xss-stable') || evaluatePreconfiguredExpr('lfi-stable')" \
    --action deny-403 \
    --description "Combined OWASP rules"

Incident Response: Handling a WAF Bypass

No WAF is perfect. Attackers constantly find ways to bypass rules. When a bypass is detected, the first step is to analyze the logs to understand how the attack evaded detection. Common bypass techniques: encoding, case variation, parameter pollution, and using different HTTP methods. Update your rules to cover the bypass. For example, if an attacker used URL encoding, add a rule to normalize the request before evaluation (Cloud Armor does some normalization automatically, but not all). Also, consider using 'evaluatePreconfiguredExpr' with a stricter version. If the bypass is due to a missing rule, create a custom CEL rule. After fixing, test the rule in preview mode. Finally, communicate with your team about the incident and update your runbook. A good practice is to have a 'WAF bypass' playbook that includes steps to quickly create a temporary rule while you develop a permanent fix.

# Step 1: Analyze logs
# Step 2: Create a temporary rule to block the bypass
# Example: block requests with 'union' in query string (case-insensitive)
gcloud compute security-policies rules create 12000 \
    --security-policy prod-waf-policy \
    --expression "request.query.matches('(?i)union')" \
    --action deny-403 \
    --description "Temporary block for SQLi bypass using UNION"

# Step 3: Test in preview
# Step 4: After testing, update the permanent rule
# Step 5: Remove temporary rule