Why WAF Prices Vary So Much: Requests per Second or Protected Domains?

The direct answer: WAF prices vary so much because vendors are not selling the same thing — they meter different units, bundle different features, and target different buyers. Some price per request (or requests per second), some per protected domain, some per plan tier with feature gates, and enterprise vendors quote per bandwidth or per contract. Requests per second and domains are both real pricing inputs, but neither explains the spread on its own. The largest price differences come from what is bundled with the meter: DDoS absorption capacity, bot management, managed rulesets, support SLAs, and analytics.

The short answer

Think of WAF pricing as three stacked components. First, a base meter — requests, domains, or bandwidth — which sets the "size" of your bill. Second, a feature bundle — managed rules, bot protection, DDoS scrubbing, analytics — which multiplies the price far more than raw traffic does. Third, a sales model: self-serve plans are standardized, while enterprise deals are quoted case by case and often include volume commitments. Comparing two WAFs by price per domain is meaningless if one includes L7 DDoS absorption and the other charges extra for it.

• Per request / per rps: scales with traffic; predictable only if you know your request volume.
• Per domain: cheap at low volume, surprising if you have many hostnames or subdomains.
• Per plan tier: the common self-serve model; features, not traffic, drive the price.
• Per bandwidth / enterprise quote: the legacy and high-end model; negotiated, not published.

Why the meter matters more than the number

The unit of measurement defines how your bill behaves as your traffic changes. Per-request pricing means an attack that multiplies request counts hits your wallet as well as your origin. This is not theoretical: a published WAFNinja article documents cache-bypass attacks that multiply effective request load by 10,000, and hash-collision attacks where a few thousand requests can drive parser CPU to 100%. Under per-request metering, both of those attack shapes inflate cost before the WAF even blocks anything. Per-domain pricing behaves differently — it is stable under traffic spikes but punishes architectural sprawl: a microservice-per-hostname setup can cost many times more than a single consolidated domain.

Context matters too. A network firewall makes decisions at OSI Layers 3 and 4 (IP, port, protocol), while a WAF inspects application-layer HTTP — which normally arrives on port 80 (HTTP) or 443, with SSH on port 22 being a different concern entirely. Because DDoS attacks have evolved to Layer 7 application-layer attacks, modern WAF products now bundle L7 mitigation and absorption capacity, and that bundle is a major price driver. Two vendors can show similar "per request" prices while differing by an order of magnitude in what happens when a real flood hits.

Comparison dimensions used in this guide

• Pricing unit: requests, rps, domains, bandwidth, or tier.
• Feature bundle: ruleset, bot management, DDoS absorption, analytics.
• Metering definition: peak vs. average, request size, rule-count multipliers.
• Overage behavior: hard limits, throttling, or pay-as-you-go.
• Contract model: self-serve, annual commitment, enterprise quote.
• Hidden costs: egress, support tiers, add-on modules.
• Operational cost: managed vs. self-hosted (license vs. staff).

Comparison table: common WAF pricing models

The real price drivers behind the spread

• DDoS absorption: whether L7 mitigation and scrubbing capacity are included is often the single biggest line-item difference between a cheap and an expensive quote.
• Bot management: device fingerprinting, challenge flows, and ML-based detection are priced as premium add-ons by most vendors.
• Managed rulesets: who writes, updates, and tunes the rules — you or the vendor — changes both price and ongoing effort.
• Rule and feature count: some vendors meter custom rules per number of active rules, which quietly raises cost as you add endpoints.
• Metering definition: peak rps costs more than average rps; "request" definitions vary (some count only inspected requests, others count everything).
• Support tier: 24/7 phone support and response SLAs are a real, often under-quoted cost.
• Data and analytics: retention of logs, attack forensics, and SIEM exports are frequently separate line items.

How to estimate your real bill (step by step)

1. Measure your actual request volume: average and peak rps per domain over 90 days — do not guess from marketing materials.
2. Count protected hostnames and wildcard needs; decide whether per-domain or per-request pricing fits your shape.
3. List the features you genuinely need: managed rules, bot management, L7 DDoS absorption, analytics, SIEM export.
4. Get quotes in the same unit: convert each vendor's proposal to estimated monthly cost at your measured peak, not your average.
5. Ask what happens on overage: hard block, throttle, or pay-as-you-go — and model your worst attack month, not your quietest.
6. Add hidden costs: egress fees, support tier, setup/onboarding, and the staff time for tuning if rules are unmanaged.
7. Compare 12-month totals including migration and re-tuning, and re-run the model after any traffic-growth forecast changes.

Total cost of ownership beyond the invoice

• Self-hosted open source: zero license, but staff time for tuning and patching dominates; you also own DDoS capacity (see the open source replacement guide for the full tradeoff).
• Self-serve managed: predictable monthly cost; watch feature gates that push you into higher tiers as you add domains or rules.
• Enterprise managed: highest invoice, but includes capacity, support, and managed rules — often the cheapest option per hour of security-team time.
• The hidden line: false positives are an operational cost, not a pricing cost — an over-blocking WAF costs you in support tickets and lost API calls regardless of the vendor.

Common mistakes to avoid

• Comparing vendors by per-domain price while ignoring that one includes DDoS absorption and the other sells it separately.
• Budgeting from average traffic when peak rps is the metered unit — under-attack months are the ones that hurt.
• Ignoring the overage clause: "unlimited" plans usually mean "unlimited until we throttle you."
• Multiplying domains with microservice hostnames and then wondering why per-domain pricing exploded.
• Forgetting the 3 a.m. support question: the cheapest quote with no SLA is expensive when the WAF blocks your own production traffic.

FAQ

Is WAF pricing based on requests per second or protected domains?

Both exist, plus plan tiers and bandwidth. Per-request and per-rps models dominate cloud WAFs for APIs; per-domain and plan-tier models dominate website-focused products. Read the quote's meter definition carefully — it changes your bill more than the headline rate.

Why is one WAF 10x more expensive than another?

Usually because of what is bundled: L7 DDoS absorption, bot management, managed rulesets, support SLAs, and analytics. Strip the bundles to the same feature set and the spread narrows considerably (exact market price ranges pending verification).

Does an attack make my WAF bill go up?

With per-request metering, yes — attack traffic is still inspected traffic. Attack shapes that amplify request counts, like cache-bypass patterns that multiply load, are documented (a WAFNinja article reports a 10,000x multiplier) and will hit per-request meters hard. Per-domain or committed-rps plans are more predictable under attack.

Should I choose the cheapest WAF?

Only if the cheapest one covers the features and capacity you need. For a public API, the difference between a plan with and without L7 DDoS absorption is the difference between surviving a flood and not. Price the failure mode, not just the invoice.

Sources and verification

Verified facts (evidence A, from WAFNinja's published documentation, verified 2026-08-04): DDoS attacks have evolved to Layer 7 application-layer attacks; network firewalls make decisions at OSI Layers 3 and 4; web traffic uses port 80 (HTTP); SSH uses port 22; a WAFNinja article lists 10 WAF bypass techniques every security engineer should know; cache-bypass attacks can multiply request load by 10,000; hash-collision attacks can drive parser CPU to 100% with a few thousand requests. All vendor pricing figures and market price ranges are pending verification unless a specific source is cited. Last verified: 2026-08-04.