Vercel no longer bills you for the traffic its firewall blocks. Under the May 2026 pricing change, any request a Web Application Firewall rule denies, challenges, or rate-limits is waived on both the CDN-request and Fast Data Transfer axes, automatically, across every project using Vercel Firewall. That removes a cost distortion most managed WAFs still carry: the bill scales with the volume you inspect and drop, not just the volume you serve.
What changed in Vercel’s WAF pricing?
Vercel’s Firewall now zeroes out two of its metered dimensions, CDN Requests and Fast Data Transfer, for any traffic it mitigates. The waiver covers three outcomes: denied requests, challenged requests that fail or never complete, and rate-limited requests. It applies with no configuration change, so every project already using Vercel Firewall inherits it.
The change is narrow by design. It targets the bandwidth and edge-request meters, which are where attack volume inflicts the most damage. A sustained reflection attack can push terabytes of egress and tens of millions of requests without ever touching an origin or a function, and under the old model every one of those requests was metered at the same rate as legitimate traffic.
How did blocked traffic inflate bills before?
The pre-change economics were the part nobody noticed until the invoice arrived. Vercel bills Fast Data Transfer by the gigabyte past the included allowance. According to Usagebox’s bill-shock analysis, the $0.15/GB overage rate looks harmless until attack traffic multiplies it: one developer woke up to a $23,000 bill after a single DDoS, with every byte of attack traffic metered at the standard bandwidth rate. A few terabytes of attack egress at that rate is how a $20 Pro plan turns into five figures.
The mechanism is not exotic. Bandwidth is a pass-through cost on any platform running an allowance-plus-overage model. When an attacker can generate it for free and the victim pays the metered rate, the asymmetry is total. What made it sharper on Vercel specifically is that the WAF and the CDN are the same product surface: the component doing the inspecting and the component doing the billing share a counter.
Why does free mitigation change security posture?
Every managed WAF that bills per inspected request builds a perverse incentive into its own pricing: the stricter your rules, the more requests get evaluated, and the more you pay. A team running aggressive bot-blocking during a credential-stuffing window sees its WAF spend spike precisely because the rules are working. This is not a marginal effect. As CloudCostKit’s comparison guide notes, WAF cost comparisons fail outright when they don’t normalize for blocked traffic; if blocked requests are still evaluated and billed, aggressive policies paradoxically raise WAF spend during the exact windows where blocking matters most.
The rational response to that pricing, for a cost-sensitive team, is to under-block. Set thresholds loose enough to avoid inspecting, and paying for, traffic you’re uncertain about. Defer the long denylist. Flip the OWASP ruleset to count-only during noisy periods. None of those are security-first decisions; they are budget decisions wearing a security hat. And because they don’t surface in a cost dashboard as a problem, they persist.
Vercel’s change doesn’t fix bad rules. It removes the budget pressure that produced them. On the mitigation side, the marginal cost of adding a stricter rule is now zero. A denylist of 50,000 IPs costs the same as 50, whether every one hammers the edge or none do. The bottleneck shifts from “can we afford to block this” to “are we sure we want to block this,” which is the question security teams should have been answering all along.
What’s still billable after the change?
The waiver is not unconditional, and the exceptions matter more than the headline. Three things remain on the meter.
Traffic that passes a challenge. A request that completes a challenge, such as a CAPTCHA or managed challenge, and proceeds to the application counts as normal usage. The Vercel usage and pricing docs are explicit: only successfully mitigated traffic is waived, meaning denied, failed-challenge, or rate-limited. If your challenge has a high pass rate, you pay for the survivors.
Paid WAF features. The free tier covers DDoS mitigation, IP blocking, and custom rules on all plans. Per Vercel’s usage and pricing docs, rate limiting bills at $0.50 per million allowed requests, and the OWASP CRS bills at $0.80 per million inspected requests plus $0.20 per GB of inspected payload. Note the qualifiers: “allowed” and “inspected” are not mitigated-traffic meters, so the free-mitigation waiver doesn’t reach them.
Non-WAF bandwidth and the rest of the bill. The waiver covers traffic the firewall mitigates. Legitimate traffic that reaches your origin, your functions, and your static assets is billed as before. Function duration, invocations, image optimization, and the other multi-axis meters Vercel runs are untouched. A cost model that treats “Vercel bandwidth is now free” as the takeaway will be wrong; the correct takeaway is that bandwidth is now free when and only when the firewall blocks it.
How does Vercel’s WAF pricing compare to AWS and Cloudflare?
AWS WAF still bills per request processed, charging for every web ACL, every rule in it, and every request the ACL evaluates, whether that request ends up blocked or allowed. Under that model, a volumetric attack your WAF handles perfectly at the edge still generates a bill proportional to the attack’s request volume, because every blocked request was first processed and counted. The CloudCostKit comparison states the underlying problem directly: WAF cost comparisons fail when they don’t normalize for blocked traffic, because if blocked requests are still evaluated and billed, aggressive policies raise spend during exactly the windows where blocking matters most.
Cloudflare’s pricing varies by plan and add-on, but the per-inspected-request pattern holds for its metered components. The common thread across traditional providers is that blocked traffic is not free traffic; it is evaluated traffic, and evaluation carries a unit cost that doesn’t vanish when the request is dropped.
Vercel’s divergence is structural. By carving mitigated traffic out of the CDN-request and bandwidth meters, it aligns revenue with the traffic you actually serve rather than the traffic you deflect. For a team whose threat model includes volumetric attacks, that changes which platform is cheapest to run aggressive rules on, and it isn’t the one with the lowest per-million list price.
| Provider | Mitigated-traffic billing | Core WAF model | Cost behavior under volumetric attack |
|---|---|---|---|
| Vercel | Free (CDN requests + bandwidth) | Bundled DDoS, IP blocking, custom rules; metered rate limiting and CRS | Flat on mitigated axes; independent of attack volume |
| AWS WAF | Billed per processed request | Per-ACL + per-rule + per-request fees | Scales with attack request volume, even when fully blocked |
| Cloudflare | Bundled in plan tier; metered add-ons | Plan-tier with overages and feature add-ons | Depends on tier; metered add-ons scale with inspected volume |
How should you recompute your edge cost model?
Start with the assumption that’s now wrong. Any per-request or per-GB edge cost model that assumed blocked traffic was still billable on Vercel needs the mitigation line zeroed out.
- Separate mitigated from served. Pull your WAF logs and split traffic into three buckets: mitigated (denied, failed challenge, rate-limited), passed-challenge (served), and clean (served without firewall interaction). Only the last two carry the old cost profile.
- Re-evaluate rule aggressiveness. Rules tuned loose for cost reasons, denylists trimmed to limit inspection spend, CRS rules set to count-only, are candidates for strict enforcement. The budget argument that justified under-blocking no longer applies on the mitigation axes.
- Budget for false-positive monitoring instead. With the cost constraint removed, the binding constraint becomes correctness. Stricter rules mean more false positives, and false positives on a customer-facing app are a support ticket and a churn risk, not a line item. Redirect the WAF spend you’re saving into alerting on challenge pass rates, deny reasons, and rule-hit anomalies.
- Don’t generalize across providers. AWS and Cloudflare still bill for inspected and processed traffic. A multi-cloud or migration cost model that applies Vercel’s free-mitigation logic to another provider’s quotes will understate the cost of running aggressive rules elsewhere. Model each provider on its own meters.
- Watch the non-mitigation axes. Rate limiting and OWASP CRS still meter on allowed and inspected requests, and those are the features a stricter posture leans on hardest. Free mitigation on the bandwidth line does not mean a free WAF.
The recompute isn’t “Vercel got cheaper.” It is that Vercel changed which kind of traffic costs money, and the kind that went free is the kind that was distorting security decisions. Teams that had quietly optimized their firewall for the billing counter rather than the threat model now have one fewer reason to keep doing it.
Frequently Asked Questions
Does the free-mitigation waiver apply to traffic stopped by Vercel’s built-in DDoS protection?
Yes. The waiver applies to any denied, challenged, or rate-limited request, regardless of whether the rule is a custom WAF rule, an IP block, or Vercel’s built-in DDoS mitigation. The free tier includes DDoS mitigation on all plans, so that traffic is waived just like traffic dropped by custom rules.
What does a fully blocked attack cost on AWS WAF in concrete terms?
AWS WAF charges roughly $0.60 per million requests processed, plus $5 per web ACL per month and additional per-rule fees, even for blocked requests. A 100-million-request volumetric attack that never reaches your origin still produces about $60 in request-processing charges, plus the fixed ACL and rule costs, before any bandwidth or origin charges.
What is the first logging change teams should make to see the savings?
Teams should tag each WAF log entry as mitigated, passed-challenge, or clean, then reclassify their CDN request and bandwidth spend by those tags. Most billing dashboards show aggregate traffic only, so without this split the free-mitigation savings are invisible in internal cost reporting.
Which attack vectors can still generate a large Vercel bill under the new model?
Application-layer attacks that pass challenges or evade simple rules, such as credential-stuffing campaigns using rotating residential IPs, still incur normal CDN, bandwidth, function invocation, and rate-limiting allowed-request charges. The waiver removes the cost of traffic dropped at the edge, not traffic that reaches your application.
What new risk replaces the old under-blocking incentive?
With zero marginal cost for mitigated traffic, teams may leave overly broad denylists or aggressive bot rules in place longer than security justification supports. The budget signal that once forced periodic rule review disappears, so false-positive monitoring becomes the guardrail that prevents over-blocking.
