We are currently in the mid-phase of a planned migration from a mature Zscaler ZIA (Internet Access) deployment to Palo Alto Networks Prisma Access, specifically the SASE offering. The primary motivators were a desire for a consolidated security stack and perceived architectural advantages in a global, hub-and-spoke hybrid environment.
Our baseline performance metrics from Zscaler were well-established. For our primary EU region, typical HTTP/HTTPS request latency to common SaaS destinations (e.g., O365, Salesforce) was consistently between 85-120ms from user endpoint to service, as measured by detailed end-user monitoring. Since transitioning a pilot user group (approximately 500 users) to Prisma Access, we are observing intermittent but severe latency spikes, pushing the 95th percentile latency above 450ms for the same destinations. The spikes are not correlated with overall network congestion or time of day in a predictable pattern.
Our initial troubleshooting has focused on the obvious variables:
* **Service Locations & Egress Paths:** We have verified the assigned Prisma Access locations are optimal for our user subnets. Traceroutes show egress is occurring from the expected POPs (London, Frankfurt).
* **Security Policy Complexity:** We started with a mirrored, simplified policy set from our Zscaler configuration. The spike behavior persists even with a near-permit-all policy for the pilot group.
* **App-ID & SSL Decryption:** We have staged the rollout of SSL decryption and are using a limited set of App-IDs initially. The spikes occur on both decrypted and non-decrypted traffic.
The most peculiar data point is from packet capture analysis conducted during a spike event. We see a significant increase in TCP handshake time (SYN to SYN-ACK) and, in some cases, multiple retransmissions at that stage, once the traffic has entered the Prisma cloud. This suggests the latency is being introduced within the Prisma infrastructure itself, post-POP ingress, possibly at the shared inspection layer or in the routing to the egress point.
I am seeking corroborating evidence or migration post-mortems from others who have undertaken a similar transition. Specifically:
* Have you documented comparable latency regression, particularly in the 95th percentile or tail latency metrics, when moving from a mature proxy-based CASB/SWG to a full tunnel SASE model?
* Did you identify a specific architectural or configuration culprit? Potential areas I am considering include:
* Internal hair-pinning within the Prisma cloud if the optimal egress POP for a destination differs from the user's ingress POP.
* Resource contention in multi-tenant inspection engines under specific, non-peak loads.
* Differences in TCP stack tuning or buffer management between the platforms.
* What monitoring strategies proved most effective in isolating the component responsible? Our current tools show "internet latency" from the POP, but we lack granular visibility into intra-cloud hops.
Our next step is to engage Palo Alto TAC with this data, but I find peer-reviewed experience often uncovers nuances that vendor support may initially overlook. Any reproducible benchmarks or detailed packet-level analysis from similar migrations would be invaluable.
Trust but verify.
Interesting. We're also considering moving to a consolidated SASE platform from a more patchwork setup, though not from Zscaler.
You mentioned verifying service locations. Did your team do any specific testing with the latency spike patterns, maybe correlating them with specific SaaS provider IP ranges or certificate handshake stages? I'm wondering if the inspection profiles themselves could be a factor, even with optimal egress points.
>Since transitioning a pilot user group to Prisma Access, we are observing intermittent but severe latency spikes, pushing the 95th percentile latency above 450ms.
This hits close to home. I saw something almost identical during our own PoC last year, though we were coming from a different proxy vendor. Our 95th percentile spikes were a dead ringer for what you're describing.
The real head-scratcher for us wasn't the service location or egress. It turned out to be the interplay between the specific inspection profile we'd cloned from our old setup and certain SaaS application behaviors, particularly around TLS session resumption. Prisma was doing a full handshake far more often than our previous stack for the same traffic patterns, adding those unpredictable chunks of latency. Have you compared TLS connection patterns, not just overall packet flow, between the two platforms for a spiking destination? It was a real "aha" moment for our team.
Try everything, keep what works.