CDN Rate Limiting: Protecting APIs at the Edge

Q: What is Rate Limit Dimensions in CDN?

What identifies a \"client\" for rate limiting purposes:

July 13, 2026 · Priya Sharma · 4 min read

Rate Limiting at the Edge

Rate limiting restricts how many requests a client can make within a time window. Implementing it at the CDN edge stops abusive traffic before it reaches your origin, protecting both your servers and other users from resource exhaustion. For foundational context, read CDN DDoS Protection: How CDNs Absorb Volumetric Attacks — FlyFish NWA.

Rate Limiting Algorithms

Fixed Window

Count requests in fixed time windows (e.g., per minute). Simple but allows bursts at window boundaries.

Performance Comparison: Edge vs Origin Processing
Metric	Edge Processing	Origin Processing	Improvement
Latency (p50)	8–15 ms	120–300 ms	15–20x faster
Cache Hit Ratio	85–95%	N/A	Reduces origin load
TLS Handshake	1–5 ms (nearby PoP)	50–150 ms	10–30x faster
Bandwidth Cost	$0.01–0.04/GB	$0.05–0.12/GB	3–5x cheaper
Availability	99.99% (multi-PoP)	99.9% (single DC)	10x fewer outages

Figure 1: CDN Security Architecture — Defense-in-depth protection layers

Window: 1 minute, Limit: 100
T=0:58 → 90 requests (allowed)
T=1:02 → 90 requests (allowed — new window)
# 180 requests in 4 seconds across window boundary

Sliding Window

Weighted average of current and previous window counts. Smooths out boundary bursts.

Previous window: 80 requests, Current window: 50 requests
Time into current window: 40%
Weighted count: 80 × 0.6 + 50 = 98
Limit: 100 → Request allowed (98 < 100)

Token Bucket

A bucket holds tokens; each request consumes a token; tokens refill at a constant rate. Allows controlled bursts while maintaining a long-term average rate.

Bucket capacity: 100 tokens
Refill rate: 10 tokens/second
Burst: up to 100 requests instantly
Sustained: 10 requests/second

Rate Limit Dimensions

What identifies a "client" for rate limiting purposes:

Dimension	Use Case	Considerations
Source IP	General protection	CGNAT: thousands of users share one IP
API key	API access control	Requires API key in request
User session	Authenticated users	Requires session cookie parsing
URL path	Endpoint-specific limits	Protects specific resources
Combination	Precise targeting	IP + path: 10 login attempts per IP per minute

Configuration Examples

# API endpoint: 100 requests per minute per API key
Path: /api/*
Key: Header(X-API-Key)
Limit: 100 requests / 60 seconds
Action: Return 429 Too Many Requests

# Login protection: 5 attempts per minute per IP
Path: /auth/login
Key: Source IP
Limit: 5 requests / 60 seconds
Action: Return 429 with Retry-After header

# Global page limit: 60 pages per minute per IP
Path: /*
Key: Source IP
Limit: 60 requests / 60 seconds
Action: Challenge (CAPTCHA)

Response Headers

Communicate rate limits to API consumers via standard headers:

Figure 2: Secure Request Flow — How requests pass through security layers

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1719100800
Retry-After: 30 (only on 429 responses)

CDN Rate Limiting Features

Cloudflare — Rate Limiting Rules (configurable per zone). Includes counting expressions and mitigation actions.
CloudFront + AWS WAF — Rate-based rules with configurable thresholds per IP.
Fastly — Rate limiting via VCL or Compute@Edge with edge state.
Akamai — Client Reputation + rate controls in Kona Site Defender.

Edge vs Origin Rate Limiting

Edge rate limiting (CDN) protects your origin from ever receiving excessive traffic. Origin rate limiting (application) handles business logic limits (API quota per customer). Both should exist: edge for infrastructure protection, origin for business rules. The CDN handles the heavy lifting; origin handles the nuance.

Common Mistakes

Rate limiting by IP only (CGNAT affects many legitimate users)
Too-low limits (blocking power users or API integrations)
Not returning Retry-After headers (clients can't back off intelligently)
Forgetting to exclude monitoring probes and health checks