I've been evaluating ZPA for a potential migration from our legacy VPN, and the naming convention is genuinely confusing. The official product is called "Zscaler Private Access," but it's ubiquitously shortened to "ZPA." This leads to documentation, forums, and even sales materials using both terms interchangeably, as if they are distinct products.
To clarify, based on my analysis of their architecture documents and API:
- **Zscaler Private Access (ZPA)** is the full product name.
- It is a service that enforces a zero-trust network access (ZTNA) model, connecting users directly to applications, not the network.
- The core components are the Zscaler App Connector (deployed in your infra) and the Zscaler Client Connector (on the user device).
You can see this in their own API endpoints, where the service is referenced under the `zpa` path. For example, a typical call to list application segments:
```bash
GET /mgmtconfig/v1/admin/customers/{customerId}/application
Host: config.private.zscaler.com
```
The confusion likely stems from how we discuss it. "ZPA" is the product/platform, while "Private Access" is the functional description. There is no separate "ZPA vs. Zscaler Private Access" comparison; they are the same entity.
Has anyone else run into tooling or configuration issues due to this terminology? I'm particularly interested in how this maps to Infrastructure as Code (IaC) modules (Terraform, CloudFormation) where consistent naming is critical for maintainability.
Numbers don't lie
I'm a senior infra engineer at a 350-person fintech. We run GitLab CI with self-hosted runners on Kubernetes, and my team owns the internal developer platform.
**Naming Confusion:** ZPA *is* Zscaler Private Access. The only difference is marketing copy versus engineering doc. Their own API routes use `zpa`. Anyone trying to sell them as separate products is either confused or lying.
**Real Pricing & Hidden Costs:** You're looking at $5-10/user/month for licensed users. The trap is "connector" compute. The Zscaler App Connector (your on-prem component) needs HA, so you're provisioning at least two decent VMs per geo-region, plus the networking overhead to let them phone home. That's your infra bill, not theirs.
**Deployment & Gotcha:** Setting up the identity and policy pieces is straightforward if your IdP is clean. The operational gotcha is connector updates. They push updates automatically, and I've seen a bad update knock a connector offline, dropping live connections. You have to build your own monitoring and alerting around connector health.
**Clear Win:** It absolutely shreds traditional VPNs for user experience. No more "connect to the network." Users get direct app access, and it works. It eliminated our split-tunneling debates overnight. For a fully outsourced ZTNA front-end, it's solid.
If you need a pure SaaS model and your team lacks the cycles to run something like a Teleport or OpenZiti cluster, ZPA is a valid pick. Your call depends on two things: how much control you want over the data plane (you get none with ZPA), and whether you can stomach the "connector tax" on your own cloud bill.
null