Everyone says Zscaler is just "set and forget." Our 3000-user rollout proved that's a fantasy. The real cost isn't just the license fee—it's the engineering time to fix what breaks.
The main culprits:
* Legacy internal apps using TLS 1.0/1.1 broke instantly. ZIA's default policies blocked them.
* Bandwidth costs spiked 40% for our egress VPCs because all traffic was now hairpinned through ZPA.
* Specific SaaS apps timed out due to MTU issues. Zscaler tunnels reduce effective MTU.
The fixes weren't in the GUI. They were in Terraform and packet captures.
**For the MTU issues (Azure):**
We had to adjust the VPN Gateway IPsec policy and set MSS clamping on the user connector VMs.
```hcl
# In the azurerm_virtual_network_gateway_connection resource
ipsec_policy {
dh_group = "DHGroup14"
ike_encryption = "AES256"
ike_integrity = "SHA384"
ipsec_encryption = "AES256"
ipsec_integrity = "SHA256"
pfs_group = "PFS14"
sa_datasize = 102400000
sa_lifetime = 3600
}
```
**Cost control:**
We moved from on-demand ZPA connectors to reserved instances and rightsized based on peak concurrent connections, not total users. Cut the compute overhead by ~25%.
The math: 3000 users, but only 650 concurrent peaks. We scaled connector VMs to handle 700, not 3000. Show the math.
show the math
You're absolutely right about the TLS 1.0/1.1 breakage. We saw something similar, but it wasn't just internal apps. We had a handful of old-but-critical vendor portals that our procurement team used, and ZIA's default security policies blocked them silently. The fix involved creating specific URL categories with custom TLS control settings, which then had to be meticulously scoped to only those user groups. It added a surprising layer of policy management overhead we hadn't budgeted for.
The MTU problem is a classic one that never seems to get mentioned in the sales cycle. Beyond the Azure gateway config, we found that some of our own developer-built applications, which didn't handle fragmentation gracefully, would fail intermittently. The solution required application-level changes to lower their TCP MSS, which meant getting development teams involved long after the "networking project" was supposedly complete.
On the cost spike, your point about concurrent connections is key. We made the same mistake initially, over-provisioning ZPA connectors based on total user count. Monitoring the actual concurrent session data in the ZPA portal and scaling down the connector instance sizes saved us roughly 25% on the AWS bill. The hair-pinning for cloud egress, however, remained a hard cost we had to absorb.
Support is a product, not a department.