CDN WAF Pricing Models: Rule-Based, Request-Based, and Flat-Rate Comparisons

I got a call last year from a startup that'd just been hit with a $4,800 WAF bill after a bot spike. They'd enabled every managed rule set on their CDN and had no idea each rule group was metered. Their traffic hadn't even doubled, but their CDN WAF cost had tripled in a single month. If you've ever stared at a firewall pricing page and felt lost, you're not alone - I've seen teams with 10 years of infra experience get tripped up by this.

What You're Actually Paying For With a CDN WAF

When we talk about WAF pricing, we're not just talking about blocking SQL injection or XSS. You're paying for inspection time at the edge. Every HTTP request that hits your CDN - whether it's a real user, a bot, or cached content that still needs a header check - has to be evaluated against a set of rules. The CDN has to run that logic on its edge servers, log the decision, and often store it for you to review. That compute isn't free, and different providers package it very differently.

I've worked with clients who assumed the WAF was included with their CDN bandwidth bill. It's not, and that's where surprises happen. Your CDN Egress Cost Modeling: Understanding and Reducing Your Largest Bill Component is mostly about bytes out, but WAF is almost entirely about requests and rules. Even if 90% of your content is cached and you save on egress, the WAF still inspects the request before it knows it can serve from cache. The firewall pricing model decides how that inspection gets counted. I've had to explain this to finance teams who couldn't reconcile why their bandwidth went down but their security bill went up.

For beginners, think of it like this: the CDN is a bouncer at the door. You can pay the bouncer per person they check (request-based), per rule they have to memorize (rule-based), or pay a flat salary regardless of how busy the club gets (flat-rate). Each has trade-offs, and the right choice depends on your traffic pattern. The specs that define what the WAF is actually inspecting - methods, headers, status codes - are all documented in the HTTP Working Group Specifications, and understanding those basics helps you see why some rules are more expensive to evaluate than others.

# Simple way I estimate baseline WAF inspections per month
# This doesn't include retries or bot floods - just normal traffic

monthly_page_views = 2500000
avg_requests_per_page = 4.2  # HTML + 2 API calls + 1.2 assets that bypass cache
waf_inspected_requests = monthly_page_views * avg_requests_per_page

print(f"Estimated WAF inspections/month: {waf_inspected_requests:,.0f}")
# Example output: Estimated WAF inspections/month: 10,500,000
# Use this number as your baseline before you compare any pricing model

Rule-Based vs. Request-Based: Where Your Bill Really Comes From

Rule-based pricing is the oldest model I still see in the wild. You pay for the number of custom rules you create plus any managed rule sets you enable. A typical setup might give you 10-20 free rules and then charge $5 to $20 per additional rule per month, while managed sets like OWASP Top 10 or bot protection are billed as add-on bundles at $20-$150 each. I had a retail client who enabled 45 custom rules for different URL paths and wondered why their bill was $600 before they'd processed a single attack. They didn't need 45 rules - they needed 12 well-written ones that covered those paths with regex.

Request-based pricing flips that. You get a large bundle of managed rules included, but you pay for every thousand or million requests inspected. You'll often see pricing like $0.60 per million requests for WAF inspection, sometimes with a free tier of 1-5 million. This model is predictable if your traffic is steady, but it punishes you during spikes. I remember a media site that went viral during an election week - their normal 20 million requests/month jumped to 180 million. On a request-based plan, their WAF cost went from $12 to nearly $110 that month, even though they hadn't changed a single rule. If you're trying to forecast this, our CDN Request Pricing Analysis: Reducing Per-Request Costs at Scale breaks down how those per-request charges compound.

Neither model is inherently bad. Rule-based pricing rewards you for keeping your rule set clean and tight, which is actually good security hygiene. Request-based pricing rewards you for having efficient traffic and good caching. The problem is when you don't know which one you're on. Always check if your provider counts cached requests, blocked requests, and challenge requests the same way. Some count every request that hits the edge, others only count requests that reach origin. That one line in the docs can swing your bill by 40%. For performance-minded teams, the guidance on web.dev Articles about reducing unnecessary requests helps with both speed and WAF cost.

// Quick comparison I run for clients choosing between models
function estimateWAFBill(model, opts) {
  if (model === 'rule-based') {
    const baseFee = 25; // includes 10 rules + basic managed set
    const extraRules = Math.max(0, opts.totalRules - 10);
    const managedSetFee = opts.managedSets * 40;
    return baseFee + (extraRules * 8) + managedSetFee;
  }
  if (model === 'request-based') {
    const includedRequests = 2000000;
    const billable = Math.max(0, opts.monthlyRequests - includedRequests);
    return 20 + (billable / 1000000) * 0.60;
  }
  return null;
}

// Example: 30 rules, 2 managed sets vs. 12M requests/month
console.log(estimateWAFBill('rule-based', { totalRules: 30, managedSets: 2 })); // ~$265
console.log(estimateWAFBill('request-based', { monthlyRequests: 12000000 })); // ~$26

Flat-Rate WAFs and How I Compare All Three Side by Side

Flat-rate is the model everyone wishes they had until they outgrow it. You pay one fixed price, say $200 or $1500 per month per domain, and you get unlimited requests and a generous rule limit. For small to medium sites with spiky traffic, this is often the cheapest and least stressful option. I usually recommend it for startups doing under 50 million requests a month who don't have a dedicated security engineer to tune rules. You don't have to worry about a botnet doubling your bill overnight.

But flat-rate isn't magic. Providers make up for that predictability with limits elsewhere. I've seen flat-rate plans that cap you at 100 custom rules, throttle your log retention to 3 days, or charge extra for advanced bot management and DDoS mitigation beyond a threshold. One e-commerce client of mine was on a $300 flat plan and assumed API abuse protection was included - it wasn't, and adding it would have pushed them to an enterprise tier at $2,000. That's why you have to compare more than just the headline price. It also helps to look at how your bandwidth commitment interacts with security costs, which we cover in CDN Bandwidth Commitment Pricing: When Committed Plans Save Money vs Pay-As-You-Go.

When I'm helping a team choose, I build a simple three-scenario table using their actual numbers from the last 3 months - low month, average month, and spike month. Don't use the marketing calculator on the pricing page; use your own logs. Pull your real monthly request count, your real number of active WAF rules, and how many managed sets you actually need. Then run each pricing model against those three scenarios. The table below is a realistic example for a mid-size SaaS app I audited recently. You'll see quickly which model hurts you when traffic spikes.

Practical Implementation: Deploying Rules Without Torching Your Budget

Look, picking a pricing model on paper is the easy part. Making it behave in production without a surprise invoice is where most teams get burned. If you’re on a rule-based or hybrid plan, don't just enable the full OWASP managed set and call it a day. You'll pay for 40 rules you don't need and you'll drown in false positives. Instead, start in count/log mode. I typically deploy the baseline managed ruleset (SQLi, XSS, RCE) in count for 48-72 hours on a high-traffic property doing 50-100M requests/day, then I’ll look at which rules actually fired. You’ll usually find 5-7 rules account for 90% of legitimate blocks.

Once you’ve got that data, you can prune hard. Disable the noisy low-value rules and convert the rest to block/challenge. Order matters more than people think — put your cheapest, highest-signal checks first. Bot checks, rate limits, and geo blocks should run before your expensive managed SQLi inspection. If 18% of your traffic is junk bots from two ASNs, why are you paying to deeply inspect every single request? Filter it at the edge first and you’ll cut your effective inspected request count by nearly a fifth. This is also where good caching strategy pays off — if your static assets are properly cached and bypass WAF inspection entirely, that's a direct saving on request-based models. We dig into that interplay in CDN Storage Cost Optimization: Tiering, Compression, and Lifecycle Policies because origin offload and WAF inspection costs are two sides of the same coin.

For Terraform users, here's the pattern I use to keep costs predictable. We'll deploy managed rules in count initially, add a sampled logging rule, and enforce a strict rate limit with a challenge action instead of a hard block — challenges cost the same but kill false-positive support tickets:

# Cost-aware WAF deployment - start in COUNT, promote after 72h of logs
resource "aws_wafv2_web_acl" "main" {
  name  = "prod-edge-waf"
  scope = "CLOUDFRONT"

  rule {
    name     = "rate-limit-api-abuse"
    priority = 0
    action { challenge {} } # cheaper than block for UX, same enforcement
    statement {
      rate_based_statement {
        limit              = 2000
        aggregate_key_type = "IP"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      sampled_requests_enabled   = true
      metric_name                = "api-rate-limit"
    }
  }

  rule {
    name     = "aws-managed-core-rules"
    priority = 10
    override_action { count {} } # flip to none after tuning
    statement {
      managed_rule_group_statement {
        vendor_name = "AWS"
        name        = "AWSManagedRulesCommonRuleSet"
        rule_action_override {
          name = "SizeRestrictions_BODY"
          action_to_use { count {} }
        }
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      sampled_requests_enabled   = true
      metric_name                = "managed-core"
    }
  }
}

Advanced Patterns: Taming False Positives and Runaway Request Bills

Here's the scenario that kills budgets on request-based pricing: you're paying $0.60 per million requests, averaging 800M requests/month (~$480 for WAF alone), and then a credential stuffing attack spikes you to 4.2B requests in a weekend. Your WAF did its job, but your bill just 5x'd to $2,520 for those three days. I've seen this exact pattern take down a quarterly budget in August. The fix isn't just "get a flat-rate plan" — it's layered enforcement. Use edge rate limiting and JavaScript challenges *before* the WAF engine bills you. Most providers don't charge (or charge far less) for requests dropped at the edge network layer versus deeply inspected WAF requests. If you can shed 70% of that bot flood with a $5/month bot management rule or an edge worker, you’ve saved $1,400.

On rule-based plans, the silent killer is false positives that force you to add exceptions, which then require more custom rules. You start with 8 rules at $12/month, then you add 6 exception rules for your marketing site's weird admin path, then 4 more for your API's JSON payloads that look like XSS. Suddenly you're at 18 rules and hitting the next pricing tier at $25 per 10-rule pack. My rule of thumb: if you're writing more than 30% custom exceptions, your managed set is too broad. Switch to anomaly scoring mode if your provider offers it — most do now — where requests only block if they hit a threshold score of 5+, not on any single rule match. It cuts false positives by 60-80% in my experience without adding a single new rule.

When you're running custom logic at the edge, whether it's custom WAF response handling or bot scoring functions, you're often paying for that compute separately from the WAF inspection itself. That $0.15 per million edge function invocations adds up fast when you're firing it on every request. Check your function pricing and batch logic where you can. For a deeper breakdown of how that math works, see CDN Edge Compute Cost Optimization: Function Pricing Models and Efficiency Tricks. And if your traffic is predictable — say you know you'll do 1B+ requests every month — don't pay list price. Most vendors will cut 20-35% off request-based or flat-rate pricing with an annual commit. We cover how to negotiate that in CDN Reserved Capacity Pricing: Locking In Rates for Predictable Workloads. For pure troubleshooting, always enable sampled logging and ship it to S3/BigQuery for 7 days. When finance asks why the bill spiked $3k, you’ll have the proof that it was a single IP range hammering /login.

Frequently Asked Questions