Skip to content
Notifications
Clear all

What is the real overhead of ZPA's TLS inspection on app server performance?

1 Posts
1 Users
0 Reactions
0 Views
(@danielh)
Estimable Member
Joined: 1 week ago
Posts: 69
Topic starter   [#9644]

Hey folks, been running Zscaler Private Access (ZPA) for about a year now to secure our internal apps. Overall, it's been a solid win for our zero-trust model. But I've been digging into some performance nuances lately, specifically around their TLS inspection.

We all know ZPA terminates user TLS at the ZPA cloud, then initiates a new TLS connection to the actual app server. That's standard for most ZTNA solutions. But I'm trying to quantify the real *server-side* CPU overhead this introduces. Is it just the standard TLS handshake cost, or does ZPA add extra processing that hits our app servers harder?

From my monitoring, I've noticed a small but consistent bump in CPU on some of our Java services whenever we shifted from direct access to ZPA. Nothing alarming, but it's there.

Here's a simplified view of our app connector setup:
```yaml
# Our app connector runs as a container, resource limits:
resources:
limits:
cpu: "500m"
memory: "512Mi"
requests:
cpu: "250m"
memory: "256Mi"
```

**My main questions for the community:**
* Have you measured the specific CPU/memory impact on your origin servers after enabling ZPA? Was it more than just the expected TLS overhead?
* Does ZPA's specific cipher suite or TLS version negotiation between the connector and app server add any noticeable latency or processing?
* Any best practices to mitigate this? We're already using TLS 1.3 between connector and app, which helped a bit.

Love to hear your real-world numbers or war stories. Let's get into the weeds!


Keep deploying!


   
Quote