Cloud Armor pricing (GCP): model baseline traffic, attack spikes, and logging

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

WAF pricing is a request-volume problem with tail risk. A good model includes two scenarios: baseline traffic and an incident spike. If you only model baseline, the bill will surprise you exactly when you are under attack.

0) Define the layer (where Cloud Armor sits)

Make sure you understand which requests Cloud Armor sees: edge traffic, load balancer traffic, or a subset by hostname and path. This prevents double counting.

• CDN requests: counted at the CDN edge.
• WAF requests: counted where the WAF is enforced (often at the edge/load balancer).
• Origin requests: what reaches your backend after caching and filtering.

Guide: CDN request pricing.

1) Baseline request volume (requests/month)

Convert baseline RPS to monthly requests. If your traffic is seasonal, model the high-traffic month rather than the average month.

Tool: RPS to monthly requests.

2) Incident scenario (peak RPS × duration)

Budget an incident scenario: peak RPS multiplied by hours or days. This captures bot surges and DDoS windows. If you do not have history, choose a conservative multiplier (e.g., 5× baseline for 24–72 hours) and refine later.

• Peak requests ~= peak RPS × 86,400 × days
• Keep incident traffic as a separate line item, not blended into baseline.

3) Logging and analytics (the hidden second bill)

Logging is often the second spike driver. If you log every request during an incident, log ingestion can become material even when WAF request pricing is acceptable.

Tools: Log ingestion, Tiered log storage, Log scan.

• Decide whether you log all requests, blocked only, or a sampled subset.
• Model retention separately (hot window + archive) so incident logs do not create a long-term bill.

Worked estimate template (copy/paste)

• Baseline requests/month = baseline RPS × 86,400 × days
• Incident requests = peak RPS × 86,400 × incident days
• Logs = requests × bytes/request (baseline + incident), then retention + scan if applicable

Common pitfalls

• Modeling baseline only and ignoring attack spikes.
• Double-counting requests across CDN + WAF + origin layers.
• Turning on verbose logging during incidents without modeling ingestion and retention.
• Using one blended request volume that hides a short but expensive attack window.
• Not validating what is actually logged (all vs blocked vs sampled).

How to validate

• Validate baseline and peak RPS from historical analytics or load balancer metrics.
• Validate incident duration assumptions (hours vs days) using real timelines.
• Validate logging strategy and retention (do not keep incident noise forever).
• After changes, validate that request and log volumes move in the expected direction.

Related tools

Sources

• Cloud Armor pricing
• Cloud Armor documentation

Related guides

Related calculators

FAQ