Azure Front Door WAF vs. Azure Application Gateway - performance overhead numbers?

Those whispers about 5-15ms for AGW are misleading. That's for a bare health check with zero active rules. The second you turn on a production ruleset, the latency floor jumps and the variance explodes. I've seen the P99 delta hit 35-50ms under load with OWASP core plus bot protection.

For your AKS pipeline, AFD's overhead is more predictable but always includes that global network hop. AGW's latency is a wildcard that scales poorly with rule complexity during traffic surges. Pick your poison: predictable higher baseline, or unpredictable regional spikes.

You're right to focus on milliseconds for a real-time pipeline, but the baseline numbers are less important than the variance under load. Your mention of "whispers of 5-15ms for AGW" is the synthetic best-case; that's with no rules active.

In my recent benchmarks against an AKS backend, the median latency add for AGW v2 with OWASP 3.1 Default was 9ms. However, the P99 jumped to 22ms, and that's without bot protection. The variance is what kills predictability for dashboards. For AFD, the median add was higher at 15ms, but the P99 was only 18ms - the edge network hop is consistent.

So your trade-off is clear: AGW offers lower median latency but higher unpredictability during surges, especially with complex rulesets. AFD gives you a more predictable, albeit higher, baseline penalty. For your third-party streams, I'd prioritize the tighter distribution.

Really appreciate you sharing these specific numbers, they're exactly the kind of data I wish Microsoft would publish. Your point about the tighter distribution with AFD versus AGW's unpredictable spikes is spot on, especially for anything needing predictable latency.

One extra wrinkle I've seen, which builds on your benchmark, is how these services handle a sudden shift in request profile. With AGW, a traffic surge of requests with more query parameters or a spike in POST body sizes can cause the P99 to balloon beyond just the increase from rule count, adding another layer of unpredictability. The edge processing with AFD seems to insulate it from that specific backend-bound effect.

So for real-time streams, that consistency is gold, even with the higher baseline. Have you noticed any change in the variance when toggling on the managed bot protection tier? I've heard whispers that it can introduce its own little spikes in AGW.

Exactly! This is the architecture question that needs answering first. I've seen teams get hypnotized by the latency debates and deploy a global service for a purely regional API.

But there's a sneaky case where AFD makes sense even for one region: when you're using its managed TLS certificate and want that termination point as close to your global development teams as possible. It's not about latency then, it's about simplifying certificate management across a distributed workforce.

That said, if your users and backend are all in East US, paying for AFD's global network is hard to justify. You're just adding a single, consistent hop that's always 15ms away.

You're right to search for concrete numbers, and you've put your finger on the exact gap in the docs. Let me add a dimension to your "added milliseconds" point that often gets overlooked: the impact of regional peering.

Those whispers of 5-15ms for AGW assume the gateway is peered directly to your AKS VNet in the same region. If your network topology forces traffic through a hub VNet or across peered VNets, you can easily double that baseline latency before any WAF rules are considered. AFD avoids this because the edge-to-backend connection is abstracted, which ironically makes its latency more predictable, even if it's higher.

For your AKS-hosted endpoints, the throughput ceiling is another undocumented variable. AGW v2 scales with compute units, but you'll hit a soft limit on maximum requests per second per gateway instance under a complex ruleset. I've seen it plateau around 15-20k RPS for POST-heavy traffic with OWASP 3.2. AFD scales differently, and while its global distribution helps, the per-backend pool limit becomes your bottleneck for a single regional backend.

I think those 5-15ms whispers are for the same region, but user356's point about network topology is huge. Even in one region, if your VNet peering isn't perfect, AGW's latency can spike.

So for your single-region scenario, AFD's global footprint does seem less relevant, but it might still win on predictability if your internal network isn't ideal. Have you mapped out your actual VNet routing?

Your focus on TLS termination overhead is valid, but it's often dwarfed by the rule evaluation engine's behavior under load. The CPU impact for SSL handshakes is negligible on both platforms when you're using their managed TLS certificates; the bottleneck becomes rule matching, especially with larger POST bodies.

The whispers of 5-15ms for AGW represent the best-case scenario you'd see in a synthetic health probe test. For a real-time analytics pipeline with unpredictable payloads, you need to consider the latency profile during request profile shifts. AGW's latency can become highly variable when query string length or POST body size increases suddenly, as its regional instance must process the entire payload against the ruleset. AFD, operating at the edge, tends to exhibit a more consistent, albeit higher, baseline because that initial processing hop is fixed.

Your throughput ceiling concern is also tied to this. AGW v2 scales with compute units, but its maximum request rate per instance can be constrained by complex rule evaluation. AFD's edge-based scaling is more opaque but often handles volumetric surges more predictably, as the load is distributed across its global points of presence before reaching your backend.

Right? That's the exact "aha" moment I had last year. You think it's just geography until you see the compute fight happen.

Your "forced to pick your poison" question nails it, but there's a third, unglamorous option for AKS: just run the WAF *inside* the cluster. I know, it sounds like a step back, but if your latency tolerance is that tight, using an ingress controller with ModSecurity can cut out the network hop *and* the shared compute variance. The trade-off is you're now managing scaling and updates yourself, which is its own kind of predictable headache.

For most, it's still the AFD vs AGW dilemma. The 5ms to 50ms jump you're picturing is exactly the kind of regional spike that'll ruin a dashboard's day. AFD's hop is at least a consistent tax you can budget for.

You're spot on about the third option, and I've gone down that road. Running the WAF inside the cluster with an ingress controller isn't just about managing updates - the real headache is security baseline drift. You get predictable latency, but then every team's deployment can subtly change the WAF config or module version. Suddenly your "consistent" internal WAF has ten different fingerprints.

It's a valid trade-off, but that predictable headache becomes a full-time audit job. I'd only recommend it if you have a centralized platform team that can own the ingress namespace and treat it like a hardened appliance. For everyone else, you're right - it's choosing between AFD's known tax or AGW's unpredictable toll booth.

Totally get the frustration with the docs - they love talking features but skip the real numbers.

Your point about TLS overhead is key. In my tests, the handshake difference between AFD and AGW is basically noise, maybe 1-2ms. The real hit comes from the rule evaluation, especially with larger POST bodies for your data streams. AGW can really stutter there.

If you need a number for planning, budget for 15-20ms as a consistent add with AFD. It's higher than AGW's best case, but you won't get those nasty 50ms spikes when a weird payload hits. For dashboards, predictable slower is better than randomly fast.

You're looking for numbers but there aren't any, at least not ones you can trust. Every deployment's a special snowflake, especially with unpredictable streams.

Those whispers of 5-15ms for AGW are from a happy-path lab test, not a real pipeline getting hammered with weird POST bodies. Budget for triple that on a bad day.

AFD's tax is higher but at least you can plan for it. For a real-time dashboard, I'd take the known 20ms hit over wondering if this spike is the one that breaks the SLA.

Your point about geographic versus concentrated surges is key. The opaque capacity scaling is the main reason I avoid AFD for regional APIs, even with its performance predictability.

AGW's regional ceiling becomes a feature, not a bug, for capacity planning. You can stress test to find the exact request-per-second point where latency degrades on a given SKU and autoscale based on that. With AFD, you're trusting a global system to allocate capacity correctly to your specific backend, which has led to throttling surprises during what felt like modest regional spikes.

For an AKS analytics pipeline, I'd take the measurable, tunable bottleneck over the abstracted one.

You've hit on the exact frustration - the docs describe mechanics, not performance. Those whispers of *5-15ms for AGW* are so dependent on context they're almost meaningless.

Let me give you the unvarnished numbers from a similar AKS ingestion project last quarter. With OWASP 3.2 fully loaded and realistic POST payloads (10-50KB), our sustained latency add was:
- **AGW (v2, regional, peered VNet):** 8-12ms for 95th percentile, but with occasional spikes to 40+ms during payload shape changes.
- **AFD (Premium tier):** A consistent 18-22ms, regardless of traffic pattern.

The TLS handshake difference was negligible, maybe 1ms. The real story is in the rule evaluation consistency under load. For a real-time dashboard, we chose the predictable tax of AFD because budgeting for 22ms was easier than explaining the 40ms spikes.