Best WAF for a Python/Django app with frequent DDoS?

Alright, so I'm deep in the planning stages for a major migration. We're moving a legacy monolithic Python/Django app from a colo setup to a cloud-native architecture (think GKE). The app handles a lot of user-generated content and has a real-time bidding component, which historically has made it a tasty target for low-and-slow DDoS and SQLi probes. Our current on-prem WAF box is a beast to manage and doesn't scale elastically.

Cloudflare is the obvious first look for its bundled DDoS and WAF, but I'm **very** curious about the gotchas when you have a dynamic, session-heavy Django app. My primary concerns aren't just raw packet filtering; they're about application logic, data quality, and ensuring the migration doesn't introduce weird session or geo-blocking issues.

Here’s my current evaluation matrix and some specific questions for those who've been in the trenches:

**Key Requirements & Worries:**
* **Zero Trust / Session Integrity:** Django uses its own session middleware. How does Cloudflare's WAF (especially managed rules) handle things like CSRF tokens (`csrfmiddlewaretoken`) or session cookies without breaking the app? Do I need a lot of exclusions from the outset?
* **API Protection:** We have a `/api/v1/` namespace. The OWASP Core Rule Set is great, but it's notorious for false positives on legitimate API calls, especially with non-standard payloads (like our bidding data). How fine-grained can the rule tuning get? Can I apply different rule sets to `/admin/`, `/api/`, and the main app?
* **DDoS "Smart" Rate Limiting:** The docs talk about "rate limiting rules." For a Django app, what's the best key to use? I'm thinking `cf.unique_visitor_id` or maybe a custom header from our auth. Has anyone implemented a tiered approach (stricter for unauthenticated, more lenient for logged-in users)?
* **Origin IP & Logging:** The loss of real client IPs is a classic issue. We use `django-ipware` currently. The Cloudflare `CF-Connecting-IP` header seems straightforward, but I've heard horror stories about misconfigured `X-Forwarded-For` chains in complex deployments. Any Django middleware snippet you swear by?

**My tentative Cloudflare config plan looks like this:**

1. **Phase 1 (Pre-Cutover):** Deploy in "simulation" mode for all managed rulesets. Let it bake for a week, scour the logs.
2. **Phase 2:** Build a **dedicated ruleset for our API**, likely disabling rules like `942200` (SQL Injection) in strict blocking mode initially, due to past false positives with our JSON schemas.
3. **Phase 3:** Implement custom rate limiting. Something like:
```python
# Example of logic we'd mirror in CF rate limiting rule
if request.path.startswith('/api/v1/bid/'):
# Very strict, per-IP rate limiting
rate_limit_key = cf.unique_visitor_id
requests_per_minute = 30
elif request.user.is_authenticated:
# Looser for authenticated users
rate_limit_key = cf.unique_visitor_id
requests_per_minute = 120
```
4. **Phase 4 (Rollback Strategy):** This is critical. We'll keep the old WAF box in "monitor only" mode, and have a DNS failover ready (TTL pre-set low) to switch traffic back if something deep in the app layer breaks.

**The Big Question:** For those running Django (or similar frameworks like Flask) under heavy, targeted traffic: Is Cloudflare's WAF + DDoS combo "smart" enough out-of-the-box, or did you find yourself writing a mountain of custom rules and exceptions that negated the managed benefit? Did the performance hit from routing all traffic through their network introduce any latency issues for your dynamic content?

Also, any insights on data migration for WAF logs? We need to pipe them into our existing SIEM (Splunk). The Logpush to S3 seems okay, but parsing those JSON logs for our specific attack patterns is another layer of work.

Really appreciate any war stories or config snippets you can share. The devil is always in the details with these migrations.