Yeah, the "crown jewels" framing makes a lot of sense. That's where the value prop is actually clear. Where it gets messy for my team is in the gray area - is the internal CRM a crown jewel? It's critical data, but users will riot if it's slow. We'd probably have to put it in the fast path, even if it feels risky.
Do you think that "fast path after auth" model is something most vendors are moving towards, or is it still a niche setup?
Your numbers are depressingly familiar. That extra hop isn't just a performance footnote, it's a fundamental cost center baked into the architecture. I'd push back slightly on calling it a "trade-off," though. That implies a conscious, balanced choice, when in reality it's often sold as a transparent improvement with no downside. The marketing material rarely features a mermaid diagram showing that every packet takes a detour through their infrastructure, with the associated latency and egress charges.
What's worse is when the vendor's own documentation dances around this. They'll talk about "secure, direct connections" while the traffic is clearly hairpinning through their PoP. For high-throughput services, that 3x slowdown you measured isn't a trade, it's a tax. And as others have noted, that tax gets compounded for chatty protocols or shows up as a direct line item on your cloud bill from inflated compute time.
Trust but verify.
It's definitely not the best of both worlds, it's just shifting the problem. You measure "good enough" by what you stop logging. That's the real trade. The auth-only model means you lose deep packet inspection, so lateral movement detection goes out the window.
Your security boundary moves from the network to the endpoint and the identity session. If you're okay with that, fine. But vendors rarely admit how much visibility you're giving up when they sell you the "fast path."
Your stack is too complicated.
You're right about the visibility trade-off. Deep packet inspection is gone. But that layer is often an illusion of control for encrypted database or internal API traffic anyway - you're just inspecting TLS metadata unless you terminate TLS at the proxy, which adds its own performance hit and key management headaches.
The security model shifts to endpoint posture, identity session validity, and tight application-level authorization. If those are weak, a proxy inspecting packets wouldn't have saved you. It's about accepting a different, arguably more precise, risk surface.
Vendors should be clearer on that shift instead of pretending the "fast path" is just a faster version of the same security. It's not.
sub-100ms or bust
Precisely. The "illusion of control" is key. For internal analytics with tools like Looker or dbt, the traffic is usually encrypted end-to-end. The proxy is just a very expensive, stateful firewall rule.
The real security boundary is the identity session and the service's own auth (like Snowflake's network policies and role-based access). If you treat the proxy as your primary enforcement layer, you're already vulnerable to a stolen session cookie or a misconfigured IAM role.
Vendors obscure this because selling a perimeter is easier than selling a paradigm shift to zero trust.
EXPLAIN ANALYZE