Best Practices for AWS WAF Rate Limiting with Mixed User Networks (Corporate + Public)

Question

We are new to AWS WAF and trying to design a simple but effective rate-limiting strategy.

Our scenario is a bit tricky:
 
Our users access the application from both:
       * Corporate networks (shared IPs, ASN-based traffic)
       * Public/mobile networks (highly dynamic IPs)

Because of this, applying rate limits purely based on source IP or ASN doesn’t seem reliable. A single IP/ASN could represent many legitimate users, especially in enterprise environments.

Questions:

1. In cases like this, what do industry best practices recommend for rate limiting?
   How do you balance security vs avoiding false positives when users come from shared or global networks?

2. Is applying a global rate limit sufficient in most real-world setups?
   Or is it better to apply more granular limits (e.g., login endpoints, public APIs, sensitive paths)?

3. Are there better approaches (e.g., token-based tracking, headers, session-aware logic, or combining multiple signals) that work well with AWS WAF?

Any additional suggestions to improve our design are more welcome.

Florian Turnwald · Accepted Answer

For mixed networks (Corporate + Public), relying solely on Source IP is no longer a best practice. Instead, use a **multi-layered rate-limiting strategy** using the following AWS WAF features:

### 1. Implement Composite Keys (IP + Header)
To distinguish between users behind a single corporate NAT/Proxy, configure your Rate-based Rules to use **Custom Keys**. 
*   **Recommendation:** Combine `IP` with a unique identifier like a `Session-ID` cookie, `User-Agent`, or an `Authorization` header.
*   **Result:** AWS WAF tracks requests per unique user/browser session rather than per shared IP.
*  -> https://aws.amazon.com/blogs/security/discover-the-benefits-of-aws-waf-advanced-rate-based-rules/

### 2. Path-Specific Granularity
A global limit is rarely sufficient. Apply different thresholds based on the URI:
*   **Public/Static Content:** High threshold (e.g., 2,000 requests / 5 min).
*   **Sensitive Endpoints (Login/API):** Low threshold (e.g., 100 requests / 5 min) using **Scope-down statements**.

### 3. Leverage AWS WAF Intelligent Threat Mitigation
If user identity isn't available via headers:
*   **WAF Tokens:** Use the AWS WAF JavaScript SDK. This issues a unique cryptographic token to each legitimate client. 
*   **Rate Limit by Token:** Set rules based on the `TokenID`. This effectively isolates individual devices, regardless of whether they share a corporate ASN or a mobile carrier IP.
*  -> https://docs.aws.amazon.com/waf/latest/developerguide/waf-tokens.html

### 4. Implementation Best Practice: "Count" Mode
Before enforcing any rule, deploy it in **Count** mode. Monitor your CloudWatch metrics to identify if legitimate corporate traffic spikes exceed your thresholds. Only switch to **Block** once you have verified the "Top 10 IP" report against your known user patterns.

see also:
- https://aws.amazon.com/about-aws/whats-new/2023/05/aws-waf-rate-based-rules-request-headers-composite-keys/
- https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based-aggregation-options.html

Best Practices for AWS WAF Rate Limiting with Mixed User Networks (Corporate + Public)

1. Implement Composite Keys (IP + Header)

2. Path-Specific Granularity

3. Leverage AWS WAF Intelligent Threat Mitigation

4. Implementation Best Practice: "Count" Mode

Add your answer

Relevant content