DDoS mitigation, WAF vs AI model. The AI model is inside the WAF.

No, but they are not opposing choices either. A modern edge WAF (Cloudflare, Fastly Next-Gen, Akamai App and API Protector) ships with one or more ML models built in. Cloudflare runs CatBoost models on every request and exposes the result as cf.bot_management.score, a 1 to 99 field your rule expressions can match against. So when a vendor pitches you an 'AI-based DDoS solution' the honest description is one of two things: their own WAF that includes ML scoring, or a separate model that runs alongside a WAF and feeds it custom signals. There is no realistic 2026 deployment where you replace the rule engine entirely with a model.

It is the output of supervised CatBoost models running on Cloudflare's edge for every request. The model takes request features (headers, JA3/JA4 fingerprint, session shape, browser signals, inter-request patterns) and predicts the probability the client is human, mapped to 1 to 99. 1 means almost certainly automated, 99 means almost certainly human. Cloudflare runs multiple models in shadow mode and one in active mode that drives the visible score. The score is then used as an input variable inside wirefilter rules; you can write 'cf.bot_management.score lt 30' the same way you write 'ip.src.country in {"CN" "RU"}'. That is the actual integration. The ML output is a feature input to the rule engine, not a replacement for it.

Three concrete cases. First, you have application-specific signals the WAF cannot see: time on page, scroll velocity, mouse-move entropy, in-app event sequences, partial form fills. A custom scorer running in your origin can read those and reject or downgrade requests the WAF passed. Second, you have a request shape the WAF's score is bad at, such as a niche domain (low-traffic API where the global model sees too few examples to score well) or a domain where automation is expected (your own legitimate scrapers, partner integrations). A custom model trained on your own labels handles the long tail. Third, you have the volume and labelers to keep the model fresh; if you cannot retrain on a weekly cadence you do not have a model, you have a static heuristic that decays. For an SMB doing under 100 requests per second sustained, none of these usually applies.

For a 5 to 15 person SMB on a Shopify or Next.js stack, the realistic stack is: Cloudflare Pro at $25 per zone per month for the managed ruleset, Super Bot Fight Mode, page rules, and the bot management score; six to ten custom wirefilter rules tuned to the site's traffic; rate limits on /api/login, /api/cart, /search, and any webhook endpoint; a country challenge for traffic outside the customer base; and a hard block on the very-low-bot-score tail (under 5) for protected paths. The 'AI' in this stack is Cloudflare's CatBoost model, which you do not deploy or maintain; it is already running. You do not buy a separate AI DDoS product on top. The published $500 to $2,000 small-integration tier on this site covers a real ruleset with thresholds picked from the access logs, not a vendor swap.

It is half right. AI is genuinely accelerating reconnaissance, payload generation, and bypass discovery for application-layer attacks. The 2026 trend reports show large multi-vector growth and DDoS being used as cover for targeted intrusions. What that does not imply is that a small team should swap a WAF for a custom model. The defensive answer to 'attackers automate faster' is that the WAF's ML model also retrains continuously across every customer's traffic. Cloudflare publishes monitoring posts about retraining cadence; you get the benefit without owning the pipeline. The case for a custom model is application-specific signal, not a generic 'AI vs AI' framing.

Yes, but they are narrow. Layer 7 abuse where the request shape is indistinguishable from legitimate traffic and only behavior over a session reveals abuse: ticket-buying bots that throttle themselves to one request every two seconds, account farming that spreads across thousands of residential IPs, content scrapers that respect robots.txt and rotate through known-good user-agents. WAF rules cannot catch those without false positives. A behavioral model running at the application layer (Datadome, Kasada, HUMAN, Arkose, or a self-built one) can. Even then, the model is still a co-tenant with the WAF, not a replacement; the WAF handles volume and basic signal so the model only sees the part of traffic worth scoring.

Same shape, different vendors. Vercel's firewall on Pro and Enterprise includes DDoS mitigation and a managed WAF; the ML pieces are vendor-managed. Fastly Next-Gen WAF (formerly Signal Sciences) ships with an Adaptive Threat Engine that scores requests against multi-tenant signal at the edge. AWS Shield Standard handles volumetric L3/L4 free with every account; Shield Advanced adds AWS WAF managed rules and 24/7 incident response. None of these is a 'WAF or AI' choice. Each is a WAF with vendor ML inside. The decision is mostly about where your origin already lives and how much custom telemetry you want, not whether the product is rule-based or model-based.

If you start from a Cloudflare zone with no custom rules, 30 days of access logs to look at, and a written threat model (login brute force, cart scraping, foreign country abuse, webhook flooding), the work fits the published $500 to $2,000 small-integration tier on c0nsl.com. The deliverable is a written ruleset, the wrangler or Terraform config to deploy it, a 24-hour log-mode run, a reading of the action log, and a final promote-or-tune pass. If your stack also requires a Cloudflare Worker with custom request-shape logic, multi-zone alignment, a Fastly VCL component, or behavioral model integration, that is a custom-system tier engagement, $2,000 to $10,000 plus. Adding a third-party behavioral model (Datadome, Kasada, HUMAN) is its own line item with its own MRR and is rarely the right call for an SMB.

No, and this is the most common mistake on small sites. Cloudflare's Super Bot Fight Mode at default settings will challenge or block traffic from low-bot-score IPs on every path, including paths you want indexed by named bots (Googlebot, ClaudeBot, GPTBot, PerplexityBot). Without a user-agent allowlist before the bot rule, you can find your search traffic dropping in a week and not know why. The right pattern is: explicit allowlist of named good bots first, then the bot-score rule. The model gives you a number, the rule decides what to do with it. Skipping the rule layer because 'the AI handles it' lands you in conversion outages and SEO regressions.

Three steps. One, turn on Cloudflare Pro on your zone; the cost is $25 per month per zone and you get the bot management score field, the managed ruleset, and rate limiting that does not embarrass you. Two, write an allowlist rule for ClaudeBot, GPTBot, PerplexityBot, OAI-SearchBot, and Googlebot that bypasses your custom ruleset, and put it first in the rule order. Three, write one rate limit (10 per minute per IP, managed challenge on exceed) on /api/login. That is the 80 percent. The remaining work is the per-endpoint thresholds and the country and bot-score lines, which take an hour with the access logs in front of you. None of it requires picking 'WAF or AI model.' Both are already in the box.