Cloudflare Rate Limiting Pricing 2026: Plans, Rules, Real Costs

Cloudflare rate limiting pricing has one detail that breaks most budget models: the rule counter is not the expensive part. The expensive part is the counting key. As of 2026, an IP-keyed fixed-window rule costs you nothing beyond your plan fee on Free, Pro, or Business. The moment you need to count by JWT subject, API key, session cookie, JSON body field, or JA4 fingerprint, you are in Enterprise negotiation territory, and the delta is usually four figures a month, not fifty dollars. This article gives you the per-plan rule table, how Advanced Rate Limiting is actually billed, three worked configurations with threshold math, and the break-even point where an origin-side limiter beats the upgrade.

Cloudflare rate limiting pricing by plan in 2026

Rate limiting is bundled into the plan, not sold as a line item at the self-serve tiers. What you are buying is rule capacity and the expressiveness of the counting expression. Figures below reflect publicly listed self-serve plan pricing as of Q1 2026; Enterprise remains quote-only.

Two practical consequences. First, plan pricing is per zone, so a portfolio of 40 apex domains on Business is roughly $10,000/month before anyone has written a rule. Second, the jump from Business to Enterprise is rarely justified by rate limiting alone; it is justified by rate limiting plus bot management plus mTLS plus log push, bundled.

How Advanced Rate Limiting is actually billed

There is no public per-rule or per-request list price for Advanced Rate Limiting as of 2026. It is an Enterprise add-on, and in practice deals are shaped by three variables: number of zones under contract, committed request volume (billed in millions of requests per month for the security suite), and which counting attributes you need. Body-field counting — where the edge must buffer and parse a JSON payload before deciding — is consistently the most expensive attribute to negotiate, because it forces work the edge would otherwise skip.

What returning readers should know changed: through 2025 and into 2026, Cloudflare has pushed more customers toward consumption-shaped security contracts rather than flat platform fees. That means your rate limiting cost now scales with request volume more directly than it did in 2023. Model it as cost-per-million-requests-inspected, not cost-per-rule. A 2-billion-request-per-month API will negotiate differently than a 50-million-request one with the same rule count.

Three configurations and what they imply for cloudflare rate limiting pricing

• Login brute-force guard (Pro-tier sufficient). Match on POST to the login path, count by client IP, threshold 5 requests per 60 seconds, action managed challenge, mitigation timeout 600 seconds. One rule. Marginal cost: $0 above the $25 plan. Failure mode: corporate NAT egress trips the rule for a whole office. Mitigate with an IP allowlist skip rule, not a higher threshold.
• Per-tenant API quota (requires Advanced). Match on the API path prefix, count by the value of the bearer token's subject claim, threshold 1,000 requests per 300 seconds, action block with a 429 and Retry-After. Cannot be done on Business at any threshold, because IP is the only available key and tenants share IPs behind their own egress. This is the single most common reason teams get quoted Enterprise.
• Checkout abuse control (hybrid). Cloudflare handles the volumetric layer with an IP-keyed rule at 60 requests per 10 seconds on the cart path. The origin runs a Redis token bucket keyed by session ID for the precise per-user quota. Total incremental cost: one Business zone plus a small Redis instance, roughly $250 + $30/month, versus an Enterprise quote in the thousands.

When does the Enterprise upgrade actually pay for itself?

Use a blunt break-even. Take the annualised Enterprise delta over your current spend, divide by twelve, and compare it against the engineering cost of running a distributed counter yourself. A Redis or DynamoDB token bucket with per-key quotas is a well-understood pattern; a competent team ships one in two to three weeks and then pays maybe $50 to $300/month to operate it at moderate scale.

Enterprise wins decisively when you need the decision made before the request reaches your origin — credential stuffing at 200k rps, scraper floods against unauthenticated endpoints, anything where origin CPU spent rejecting traffic is itself the damage. Origin-side limiting wins when the traffic is authenticated, moderate in volume, and the precision requirement is business logic rather than defence. Most teams need both, and the cheapest architecture puts the coarse volumetric filter at the edge and the fine-grained quota at the origin.

Tuning thresholds without generating false positives

Set thresholds from observed p99 per-key request rates over a 30-day window, then multiply by 3. Not p50, not average. If your p99 authenticated user makes 40 requests per minute against the search endpoint, a 120/minute threshold catches abuse while leaving power users alone. Deploy every new rule in log-only mode for at least seven days and diff the would-have-blocked set against your known-good user IDs before you flip it to block.

Watch the boundary-burst problem on fixed windows. A 100-per-60s fixed window permits 200 requests in a two-second span straddling the window edge. If that matters for your origin's connection pool, you need the sliding-window behaviour in Advanced Rate Limiting, or a shorter window with a proportionally lower threshold — 20 per 10 seconds caps the burst at 40.

Failure modes teams hit in production

The section the top-ranking pages skip: what breaks after you ship the rule.

• Counting the wrong IP. If traffic reaches Cloudflare through another proxy, the client IP the edge sees is the proxy's. Every rule keyed on IP then counts one giant bucket and either blocks everyone or nobody.
• Cached responses not counted. Rate limiting evaluates at the edge, but hits served from cache in some configurations do not increment counters as you expect. Scrapers hammering cacheable URLs can stay invisible to a rule you assumed was protecting that path.
• Mitigation timeout longer than the attack. A 24-hour block on a mobile carrier CGNAT range is a customer support incident. Keep mitigation timeouts at or below 10 minutes unless you have per-user keying.
• Rule ordering. Rules evaluate in order and the first match with a terminating action wins. A broad IP rule placed above your narrow path rule silently shadows it. Audit ordering whenever you add a rule.
• Retry amplification. Returning 429 without Retry-After invites aggressive client retry loops that make the flood worse. Always set it.

Where delivery cost dominates rate limiting cost

For media, game patching, and software distribution, the security line item is noise next to egress. A 500 TB month on a premium platform can run six figures; the rate limiting rules on top are rounding error. If your actual problem is bandwidth economics rather than attribute-level counting, splitting the workload makes sense: keep the security-heavy dynamic endpoints where they are and move the bulk object delivery to a cost-optimised layer.

In that high-volume league — alongside Bunny.net, CDN77, Gcore and Fastly for streaming — BlazingCDN's volume pricing is worth modelling: $100/month covers 25 TB with additional GB at $0.004, and the curve drops to $4,000/month for 2,000 TB with additional GB at $0.002, roughly $2 per TB at the top tier. It offers stability and fault tolerance comparable to Amazon CloudFront at materially lower cost, with 100% uptime, NVMe SSD edge storage, flexible configuration, and onboarding measured in about an hour. Bunny.net is genuinely cheaper for small spiky workloads; the advantage here shows up on committed multi-hundred-terabyte months where per-TB math decides the budget.

FAQ

Is Cloudflare rate limiting free?

Yes, on the Free plan you get one rate limiting rule keyed on client IP with a fixed counting window, as of 2026. It is enough for a single login endpoint. It is not enough for an API with multiple protected paths, since you cannot spend your one rule on more than one expression.

How many rate limiting rules do I get on Pro and Business?

Pro provides roughly 10 rules and Business roughly 15 as of 2026, both keyed on client IP with fixed windows. Consolidate overlapping paths into a single expression using OR conditions to stay within the allocation. Rule counts are plan defaults and can differ on legacy or bundled accounts, so check your dashboard before you design around them.

What is the difference between basic and Advanced Rate Limiting?

Basic counts by client IP over a fixed window. Advanced lets you count by header, cookie, query parameter, JWT claim, JSON body field, or TLS fingerprint, supports longer and sliding-behaviour windows, and can key on multiple attributes at once. Advanced is an Enterprise add-on with no published list price in 2026.

Can I get per-API-key quotas without Enterprise?

Not at the Cloudflare edge. The self-serve plans cannot read a token or header as a counting key. The standard workaround is an origin-side token bucket in Redis keyed on the API key, with a coarse IP-based Cloudflare rule in front to absorb volumetric floods.

Does rate limiting count requests served from cache?

Behaviour depends on where the rule sits in the request pipeline and your cache configuration. Do not assume cached hits increment your counters. Validate it directly by replaying traffic against a cacheable path in log-only mode and comparing the counter against your access logs.

What threshold should I start with?

Measure the p99 request rate per key over 30 days and set the threshold at three times that value. Run the rule in log-only mode for a week, diff the would-have-blocked set against known-good users, then enable blocking. Adjust down only after you have clean data.

Run this before your next renewal call

Pull 30 days of edge logs and compute two numbers: the p99 requests-per-minute per client IP, and the p99 per authenticated user ID. If those two distributions look similar, IP-keyed rules on Business will do the job and you can walk into the renewal without the Advanced add-on. If the user-ID distribution is tight while the IP distribution has a long fat tail, you have NAT or shared-egress tenants and IP keying will never give you clean enforcement — that is your actual business case for Enterprise, with numbers attached.

Then run the second calculation: annual Enterprise delta versus three sprints of engineering plus $300/month of Redis. Post your break-even number. We are curious how many teams land on the hybrid split rather than the upgrade.