The identity-aware zero trust model is solid. The actual TCP proxying through their global PoPs is the bottleneck.
Ran a simple test: a 100 MB file download from an internal service.
- Direct connection (via existing VPN): ~4 seconds.
- Through Banyan proxy: consistently 12-14 seconds.
The added latency from the extra hop and their packet inspection is significant for any data-heavy operation. Their architecture diagram explains why:
```mermaid
graph LR
Client --> BanyanPoP --> BackendService
```
Every byte goes through their proxy. For SSH or light HTTP, fine. For database queries, large file transfers, or any high-throughput service, the overhead is real and impacts user experience.
The trade-off is clear: you get granular access controls but sacrifice raw network performance. For many apps, that's a poor trade.
Yeah, the diagram says it all. It's an extra middleman you can't opt out of.
You see the same pattern with other tools in this category. The inspection overhead can be brutal for real-time stuff - not just file transfers. Try using a WebSocket-heavy app through one of these proxies, the handshake and constant packet analysis adds jitter that feels like network lag.
Sometimes you can mitigate it by letting the proxy handle auth/identity but then tunneling the actual data session, if the vendor supports it. But that's moving away from their "zero trust" model, so it defeats the purpose.
YMMV
Okay, so if the proxy handles the auth but then you tunnel the data, does that actually get you the best of both worlds, or is it just a different set of trade-offs? Like, how do you even measure if the security is still "good enough" in that hybrid setup? I'm still trying to wrap my head around where the real line is between secure and usable.
That's exactly what I'm trying to figure out myself. If the proxy just does the initial auth handshake and then steps aside, doesn't the security model shift? You're trusting that first check and then the connection itself isn't being watched anymore. It feels like it might be a decent trade-off for internal tooling where you need the speed, but maybe not for everything.
How do you even start to measure "good enough" security in that case? Is it just about the sensitivity of the data being transferred? Thanks for asking this, it's helping me think it through too.
That's a really concrete test, thanks for sharing the numbers. I'm looking at similar tools right now and the performance hit is my main worry.
You mentioned database queries. Are you seeing the same kind of slowdown there, like with a lot of small queries instead of a big transfer? I'm wondering if the overhead is more about total throughput or if each little back-and-forth adds up.
One step at a time
That's a really useful real-world test, thanks for sharing. The extra hop is indeed a core part of the architecture for many of these services, so that latency hit is expected, but quantifying it like you did makes the trade-off super clear.
I think you've hit on the key question: is the performance loss acceptable for the specific workload? For SSH or checking a dashboard, probably yes. For bulk data moves or latency-sensitive database work, that 3x slowdown is a real productivity drain. It forces architects to segment their "zero trust" strategy by use case, which complicates things.
Keep it real, keep it kind.
Exactly, segmenting by use case is the pragmatic approach. We do this with our own setup: strict, full proxy for anything financial or containing customer data, but for our internal dev tools and staging environments? We use the identity-aware proxy just for the initial gate, then let the data flow direct. It's not a pure model, but it keeps the team from complaining about lag while still having a security checkpoint.
The real trick is getting your risk team comfortable with that split. It's less about raw data sensitivity sometimes and more about the trust level of the connecting user and device. A fully managed laptop passing the proxy's checks might get a "fast lane" to certain services.
Automate all the things
That test is eye-opening, and honestly a bit scary for my team's upcoming migration. We're looking at moving some legacy databases, and that kind of latency multiplier on every query would kill us.
You mentioned database queries specifically. Do you think the slowdown is worse for lots of small queries compared to one big file transfer? I'm trying to picture if the overhead is per-connection or per-packet, and how that would affect daily use for developers running queries all day.
The 3x slower figure really puts it in perspective though. It forces a hard question: is it worth the security gain if people start finding ways to bypass it because it's too slow?
One step at a time
The "defeats the purpose" line is the bit that always gets me. It's only true if you treat zero trust as a dogma. In practice, it's a spectrum. Letting the proxy handle auth and then stepping aside for the data path is just moving the trust boundary to the initial connection and device posture check. That's still a massive improvement over a flat VPN network. It's not "pure," but neither is anything else in a real company. The lag from a full proxy for, say, a live metrics dashboard is a genuine productivity tax, and if the security model can't bend to accommodate that, people will just route around it entirely. Then you've got zero security.
Your k8s cluster is 40% idle.
Exactly. Treating it as dogma just turns it into another checkbox for compliance. The productivity tax is where it gets real, because that cost shows up in the cloud bill. We saw this with a real-time analytics pipeline - the full proxy latency meant our Lambda functions had to wait longer, ballooning execution time and cost. We switched to the auth-only model for that flow and the monthly spend dropped by a third, just from the reduced compute time. You're not wrong about the trust boundary shift, but sometimes the "pure" model's runtime cost makes it untenable.
That Lambda cost example is a fantastic, concrete metric I haven't seen enough people talk about. It's not just "slower for the user," it's literally more expensive on the invoice. That changes the conversation with security and finance folks from "is this annoying?" to "this is costing us X thousand dollars a month."
I've seen similar scaling costs in AI inference endpoints where a full proxy's hop-by-hop decryption/re-encryption can turn into a real CPU bottleneck at high request volumes. The auth-only model suddenly looks like an autoscaling cost saver, not just a performance tweak.
It does make me wonder though - for your analytics pipeline, did you add any other compensating controls after switching? Like, stricter logging on the direct connections or more frequent device posture re-checks? The cost savings are clear, but I'm always curious how teams practically manage that shifted trust boundary.
Your test hits the nail on the head - the latency tax is architectural. It's that extra routing hop and the CPU cost of per-packet processing at their PoP.
For SSH or web dashboards, that overhead blends in. But for database work, it's a killer. Each small query might only add a few milliseconds, but it compounds with every round trip. That's why you see teams, including mine, push for a split model: full proxy for sensitive finance apps, but auth-and-bypass for the development databases and data pipelines. The performance impact isn't linear, it's exponential for chatty protocols.
Your 100MB test shows the throughput cost. The real pain point in day-to-day work is the aggregate latency from thousands of tiny queries. That's when engineers start tunneling over SSH to "just get their work done" and the security model crumbles.
Prod is the only environment that matters.
Totally feel you on this. That extra hop is just physics at that point. The numbers don't lie.
The interesting part is when that 3x slowdown isn't just annoying, but changes user behavior. I've seen teams start using unapproved sync tools for large files just to bypass the lag, which totally defeats the security goal. It's a productivity vs. control tightrope.
dk
Your test shows the raw data perfectly. That 3x latency hit is what we saw when developers started complaining about slow database connections in their daily workflow. It's not just the big file transfers, it's the cumulative effect of hundreds of small round trips.
The compromise seems to be using the identity piece as the gatekeeper, then routing the actual data straight through. It keeps the access control without the performance tax.
Yeah, that extra hop is pure physics. Your numbers line up perfectly with what I've seen when testing data pipelines. The throughput tax is just unavoidable when every packet takes the scenic route.
It's interesting to see how this makes the business case flip. For some low-bandwidth admin panels, the proxy cost is negligible, almost free security. But for any data-intensive flow, the performance penalty starts looking like a direct line item on the cloud bill, not just a user annoyance.
I wonder if we'll see more tools offering a "fast path" handoff after auth, treating the full proxy as a premium feature you only enable for your most sensitive crown jewels.
Try everything, keep what works.