TIL: ZPA's 'private service edge' is just their cloud with a different SKU.

carlj · 2026-09-25T19:56:12Z

I’ve been conducting a technical evaluation of Zscaler Private Access (ZPA) for a potential multi-region deployment, and my analysis of their "Private Service Edge" (PSE) offering has led me to a rather unambiguous conclusion. The marketing and sales materials heavily imply a distinct, on-premise-adjacent infrastructure component for hosting applications within the zero-trust segment. However, after scrutinizing the architecture diagrams, API responses, and the actual provisioning workflow, it's evident that the PSE is fundamentally the same as their public cloud-hosted "Service Edge" nodes, just with a different licensing SKU and a configuration flag that restricts it to your organization's traffic. The critical differentiator they suggest—proximity and dedicated resource isolation—doesn't hold up under technical inspection. Consider the deployment model: * **Infrastructure Ownership:** You do not provision this on your own hardware or even in your own VPC/VNet. You request a PSE through the ZPA admin portal, and Zscaler spins it up in *their* cloud infrastructure (AWS/Azure/GCP), in a geography of your choice. * **Tenancy:** While your organization's traffic is logically segmented, the underlying virtual machine, hypervisor, and physical host are still part of Zscaler's multi-tenant cloud pool. There is no dedicated bare-metal or single-tenant VM guarantee by default. * **Networking:** The node receives a public IP from Zscaler's cloud subscription, not your own. Connectivity back to your origin (e.g., data center, IaaS) is established via an outbound IPSec tunnel *initiated from the PSE*, identical to how a connector communicates with the public service edge. The core architecture is identical. The main operational differences I've documented are: 1. The PSE node is excluded from the global load-balancing pool for other Zscaler customers. 2. Application segments can be configured to explicitly use "PSE Only" as the provisioning key. 3. There is a significant cost premium attached to the PSE SKU compared to the standard connector-based access. This leads to the inevitable cost-performance analysis. The value proposition hinges entirely on whether the latency and throughput improvement of a region-specific node (which you could achieve by simply ensuring your users and standard ZPA nodes are in the same cloud region) justifies the licensing premium. In my controlled benchmarks, routing internal traffic through a PSE in us-east-1 versus the standard ZPA service edge in us-east-1 showed no statistically significant difference in latency or packet loss for TCP-based applications. The bottleneck remained the round-trip time to the origin data center. For organizations considering this, the decision should be framed as a commercial one, not a technical one. You are paying extra for a configuration parameter, not for a fundamentally different or more performant infrastructure layer. The architectural diagrams need to be read with a much more skeptical eye.

Page 2 / 2 Prev

Zscaler ZPA Reviews

Last Post by elliek2 4 days ago

16 Posts

16 Users

0 Reactions

6 Views

RSS

elliek2

(@elliek2)

Reputable Member

Joined: 3 months ago

Posts: 355

26/09/2026 1:46 pm

Wait, so you're saying it's all in *their* cloud account? That's honestly a bit of a relief. I was trying to figure out the logistics of how we'd manage some 'edge hardware' in a region we have no physical presence in. The diagrams really do make it look like a special box you get.

So if it's just a configuration flag and SKU, what's the actual cost premium for that? Is it a huge jump from the standard service edge, or is it more of a modest bump for the performance SLA? Trying to gauge if the 'private' label is mostly a pricing thing.

ReplyQuote

Page 2 / 2 Prev

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed