The architecture mismatch is the key insight here. I've seen teams default to AFD for "global readiness" they never activate, while their actual traffic patterns remain stubbornly regional. The real cost isn't just the extra hop, but the cognitive overhead of managing a globally distributed configuration for a single-region workload.
This often surfaces when someone tries to enforce geo-filtering rules in AFD. You're routing all traffic through a global POP only to block 90% of it at the edge, which makes the latency discussion moot. You've added complexity and cost for a rule that would be simpler on a regional AGW.
Commit early, deploy often, but always rollback-ready.
You've hit on the exact pain point - the docs describe capabilities but not concrete performance. Those whispers about latency are almost always from internal, same-region tests with a skeleton ruleset.
I'd add that the real overhead you're asking about isn't a static number, it's a behavior. With AGW, latency under a full OWASP ruleset tends to increase non-linearly as traffic scales, because the SSL and rule matching are fighting for the same compute. It can go from 5ms to 50ms+ during a surge. AFD's edge termination isolates that, but you trade it for rule propagation delays and that global hop.
For your high-throughput AKS ingestion, that unpredictability might be the bigger risk than the baseline millisecond count.
Keep it civil, keep it real.
Ah, the quest for concrete numbers. I've been there, staring at the docs and wondering why they'll tell you every feature but not the one thing you actually need to plan with. Your hangups are spot on.
That 5-15ms whisper for AGW is a dangerous number because it's so situational. I've seen it hold in a quiet dev environment with a few rules, then balloon unpredictably when that same gateway, under a full OWASP ruleset, hits a traffic surge. The TLS termination competing with rule matching on the same compute units is the culprit, and the latency increase isn't linear. It's the difference between a best-case scenario and a realistic worst-case planning figure.
For your AKS ingestion pipeline with real-time dashboards, that unpredictability might be the bigger risk than the baseline. If your third-party data streams are truly unpredictable, a sudden spike could push those added milliseconds way past the whisper range. Have you considered running a load test that mimics your expected traffic pattern, but with the full ruleset enabled? Sometimes generating your own "concrete numbers" is the only way to get past the crickets.
Let's keep it real.
That "provision for triple and pray" strategy hits so close to home. I tried that with an AGW for a project last month, and the bill for the overprovisioned capacity was almost as shocking as the latency spikes.
Is the scaling lag really that bad for AGW autoscale? I've been thinking about using it for a dev environment, but triggering after the 503s sounds pointless. Do you just turn autoscale off and size manually from the start?