How Cloud WAF Pricing Works: QPS, Domains, or Traffic — and the Traps

The short answer: cloud WAF vendors price on four main meters — requests per second (QPS), protected domains, traffic volume (bandwidth), or a hybrid of these plus per-rule and per-feature charges — and the traps live in the details: what counts as a request, what happens at peaks, what the "unlimited" tiers exclude, and which features are sold as add-ons. Understanding which meter your workload hits hardest is the difference between a predictable bill and a surprise invoice after a traffic spike. This article explains each model, compares them on the same dimensions, walks through how to estimate your bill, and flags the traps that show up in practice.

The short answer: which model fits which workload

• QPS-based pricing fits steady, predictable traffic — most SaaS APIs and internal portals.
• Domain-based pricing fits organizations with many small sites and low per-domain traffic.
• Traffic/bandwidth-based pricing fits media and download-heavy workloads where bytes matter more than request counts.
• Hybrid models are the norm in practice — most vendors mix a base tier with metered overages, and the mix determines the traps you need to watch.

What is a cloud WAF, and why pricing is complicated

A cloud WAF is a web application firewall delivered as a service: your traffic is routed to the vendor's edge network, inspected at Layer 7, and only clean requests are forwarded to your origin. This matters because DDoS attacks have evolved to the Layer 7 application layer — requests that look legitimate but exhaust application resources — and the WAF edge absorbs that traffic before it reaches you. Network firewalls making decisions at OSI Layers 3 and 4 (IP and port, such as port 80 for HTTP and port 22 for SSH) cannot inspect this traffic, which is one reason cloud WAFs are priced for application-layer inspection rather than simple packet rates.

Pricing is complicated because the vendor is selling several things at once: request inspection capacity, rule engineering, bot detection, DDoS absorption, dashboards, and support. Different vendors meter different slices of that stack, and the slice they choose determines how your bill behaves.

The three main pricing models

• Requests per second (QPS): you pay for sustained and peak inspection capacity. Predictable for steady workloads; expensive if your traffic has sharp, short spikes.
• Protected domains: you pay per domain or hostname placed behind the WAF, often tiered by site count. Cheap for low-traffic multi-site setups; misleading if one "domain" carries huge traffic.
• Traffic volume (bandwidth): you pay for bytes processed, sometimes including or excluding cached responses. Natural for media-heavy traffic; opaque when bots and attack traffic inflate volume.
• Hybrid and per-feature pricing: base tier plus overages for QPS or traffic, with add-ons for bot management, managed rule sets, DDoS protection, and log retention.

Comparison table: QPS vs. domain vs. traffic pricing

What actually drives your bill

• Peak, not average: several vendors price on the highest QPS seen in a window, so a single flash crowd or a short DDoS spike raises the meter for the whole period. Exact window definitions are pending verification and vary by vendor.
• What counts as a request: blocked requests, challenge responses, and cached responses may or may not count — the definitions differ, and the difference can be large.
• Attack traffic: if the WAF processes and meters attack traffic before blocking it, a DDoS event can inflate usage. Some vendors exclude mitigated attack traffic from billing; others do not (pending verification per vendor).
• Managed rules and features: OWASP rule sets, bot management, custom rules, log retention, and DDoS coverage are frequently separate line items.
• Bot traffic: scrapers and crawlers can dominate request counts while contributing zero revenue — a QPS meter charges you for them anyway.

The traps, ranked by how often they bite

1. Peak-based QPS metering: a five-minute traffic spike sets your bill for the month. Design for peak, not average.
2. Ambiguous request definitions: read whether blocked, challenged, and cached requests count toward the meter before signing.
3. Attack traffic billing: confirm in writing whether mitigated DDoS and attack traffic is excluded from the meter.
4. Domain definitions: check whether wildcards and subdomains count as separate protected domains.
5. Add-on stacking: the headline tier rarely includes bot management, advanced rules, or long log retention — those are separate.
6. Egress and origin fees: in multi-cloud setups, the WAF provider's egress plus the origin cloud's ingress can double-count the same bytes.
7. Free tier traps: free tiers exist mainly to funnel you into paid usage; verify what happens when you exceed the cap — throttling, blocking, or a bill.

Step-by-step: estimating your cloud WAF bill before you buy

1. Pull 90 days of real traffic data: average QPS, peak QPS, requests per month, bytes served, and percentage of bot traffic.
2. Separate attack traffic: how many requests were blocked or challenged in that window? Check whether the vendor counts those.
3. List the features you actually need: managed rules, bot management, DDoS coverage, log retention, custom rules, API protection.
4. Model the bill under each vendor's meter: QPS-based, domain-based, and traffic-based, using your real numbers.
5. Stress the model with your worst month: what happens at 5x peak QPS for an hour? Read the overage and throttling terms.
6. Ask the vendor, in writing, three questions: What counts as a request? Is mitigated attack traffic billed? Is there a peak-pricing clause?
7. Compare the worst-case modeled bills, not the headline prices, and include the cost of false-positive handling — every blocked legitimate user is support time.

How to pick a model for your workload

• Steady API traffic: QPS-based with a headroom buffer is usually the simplest; buy peak headroom explicitly.
• Flash-crowd-prone public sites: avoid strict peak-QPS meters; prefer traffic-based or flat tiers, or negotiate peak clauses.
• Many small properties: domain-based pricing is likely cheapest, but confirm subdomain and wildcard definitions.
• Media-heavy workloads: traffic-based pricing matches your cost driver, but verify whether cached responses count.
• Compliance-heavy orgs: optimize for features (log retention, data residency) first, price second — the cheapest meter with insufficient logs is not cheaper.

Budget reality check

Cloud WAF spend is a function of your traffic shape, not your vendor's marketing tier. The most common budgeting mistake is projecting from average QPS when the meter reads peak QPS; the second most common is forgetting that bots and attacks are metered traffic. Keep a line item for overage, re-model after every significant traffic change, and treat the vendor's "unlimited" claims with suspicion — unlimited usually means unlimited within a defined meter, and the definition is where the traps live. Specific vendor prices are pending verification; the structural dynamics above hold regardless of the numbers.

FAQ

Is QPS or traffic-based pricing better for an API?

For steady APIs, QPS is usually simpler and more predictable. For payload-heavy or bursty APIs, traffic-based can be cheaper per request but spikier — model both with your real peak data before choosing.

Do blocked attack requests cost money?

It depends on the vendor and the plan. Some exclude mitigated attack traffic; others meter everything that passes through the edge. This must be confirmed in writing — it is the single most common cause of surprise invoices.

How many domains does a wildcard count as?

Vendor definitions differ; some count a wildcard as one protected domain, others count each matched subdomain. Ask before signing, and test it in the console if you can.

Why does my bill spike after a DDoS event?

Either because the vendor meters attack traffic, or because the flood pushed your QPS over a peak-based threshold. Both are avoidable with the right contract terms — which is why the peak clause matters more than the base price.

Can a Layer 7 DDoS attack affect my WAF bill?

Yes. DDoS attacks have evolved to the Layer 7 application layer, where each request is a legitimate-looking HTTP call that the WAF must inspect — and if the meter counts inspected requests, the attack is billed as traffic. Verify the exclusion terms.

Sources and verification

Verified facts (evidence level A, from WAFNinja published content, last verified 2026-08-04): DDoS attacks have evolved to the Layer 7 application layer; network firewalls make decisions at OSI Layers 3 and 4; web traffic uses port 80 (HTTP) and SSH uses port 22. Vendor pricing figures, request-counting definitions, peak-window lengths, and attack-traffic billing policies vary by vendor and are marked as pending verification where not independently confirmed.