Hi everyone. I’ve been following the discussions here for a while and finally have something to share from my own experience.
My team switched from a traditional MPLS setup to Zscaler Internet Access about a year ago. I wanted to share our total cost breakdown over 12 months, focusing on our small dev and ops group. The biggest savings for us weren't just in the bandwidth fees, but in the reduced hardware and simpler configs. We went from managing multiple on-prem appliances to mostly cloud policies. The flexibility for our hybrid team has been great.
I’m still pretty new to all this, so I’d love to hear if this matches what others have seen. Especially around monitoring the new setup – any tips on basic dashboards or alerts would be appreciated. Thanks in advance for your insights
Senior infra lead, chemical manufacturing. We run a mix of on-prem industrial control and global offices. I manage both Zscaler ZIA for internet egress and a legacy MPLS core for our plant network.
- **True TCO:** Your "cloud" savings ignore the hair-on-fire support costs. Our Zscaler bills started around $8/user/month for the basic secure web gateway, then ballooned to $12+ when we added the private access module for contractors. That's before the $3k/month for the GRE tunnels from our bigger sites to their DCs, because Zscaler doesn't own the last mile. Our MPLS tail circuits were a fixed cost. Predictable, at least.
- **Deployment effort:** "Simple config" is marketing. The Zscaler cloud portal is straightforward until you hit a PAC file proxy bypass for some ancient SCADA data historian. Took us two weeks of packet captures and support tickets to realize their service doesn't handle non-TCP traffic. MPLS was a router config. Complex once, then it just works.
- **Performance profile:** Zscaler holds up fine for HTTP/S. Latency to their nearest pop added 8-12ms for us. It's the burst throughput that'll get you. Our MPLS could soak a 10Gbps data transfer between sites at line rate. Zscaler chokes on sustained, non-web traffic above about 500 Mbps per tunnel unless you buy into their premium bandwidth pools, which triples the cost.
- **Visibility and breakage:** Their admin portal gives you pretty dashboards about web threats. It tells you nothing when an intermediate carrier has a routing flap and drops your GRE tunnel for 45 seconds. We had to build our own mesh of icmp monitors between site firewalls to see the actual path. With MPLS, the carrier owns the whole path and you get a single SLA to scream about.
I'd stick with MPLS for any environment with heavy east-west traffic, predictable major-site locations, or latency-sensitive industrial protocols. For a purely cloud-first, web-app-focused team like yours? Zscaler works. Tell us your peak inter-site bandwidth and what non-HTTP(S) apps you run.
-- old school
You're absolutely right about the hidden tunnel costs. That's where they get you. The initial PoC never includes the dedicated circuits for the regional hubs, and suddenly you're backhauling traffic 500 miles before it hits a Zscaler POP.
Your SCADA example is a classic operational technology blind spot. Most cloud-first security vendors have no concept of industrial protocols or non-TCP flows. A router ACL on an MPLS circuit might be ugly, but it's deterministic. The moment you need a packet capture in a cloud service, you're at the mercy of someone else's logging retention policy.
The predictability argument is the real one. A fixed MPLS cost is a line item. A Zscaler cost is a baseline plus the variable of your own internet circuits, which you now have to manage for performance anyway. You traded one WAN bill for an internet bill plus a SaaS bill plus increased internal operational overhead.
Trust but verify – and audit
You're highlighting a crucial distinction between predictable capex and variable opex. That internet circuit performance variable is what we see trip up a lot of teams during their first major cloud vendor outage or ISP issue. Your traffic isn't just on a corporate backbone anymore, it's subject to the public internet's inconsistencies, and troubleshooting that mix is a new skill set.
The logging point is also a real operational handcuff. When an issue is time-sensitive, waiting for a vendor to pull logs from their system versus having full packet-level access on your own network changes the entire support dynamic.
—HR
Your experience with savings from reduced hardware overhead matches what I've seen in smaller, cloud-native environments. The cost structure flips when your team is already distributed and your applications are SaaS-first.
For monitoring, I'd suggest starting with two dashboards: one for user experience and one for policy efficacy. Track latency to the nearest Zscaler POP from your primary employee locations. For alerts, set thresholds for tunnel health status and a sudden drop in authenticated user counts, which often points to an IdP sync issue before users start complaining.
What's your method for attributing the "simpler config" cost savings? That's often a soft cost that's hard to quantify in a TCO model.
"Simpler configs" is an interesting metric to pin savings on. What happens to that simplicity the first time you need a traffic policy that Zscaler's cloud doesn't handle? You're back to managing a local box anyway, or spending hours with support.
Your experience tracks for a small, cloud-first group. Try scaling that policy management across a few dozen distinct business units with their own legacy exceptions. The operational headache you outsourced comes back as a different, often more opaque, administrative tax.
For monitoring, user109's suggestion on tunnel health is a start. But remember, you're now monitoring both your internet circuits *and* Zscaler's proxy status. That's two potential points of failure instead of one. So much for simplicity.
cg
The fixed cost of MPLS versus the variable opex of a cloud service is the core financial decision. You're right to call it out.
The hidden circuit costs are real. Beyond just the GRE tunnel fees, you're now managing ISP performance and troubleshooting asymmetrical routing on the public internet. That's a new operational burden the simplified portal doesn't advertise.
Your point about non-TCP traffic for SCADA is the killer. Cloud vendors are built for HTTP/S. Anything outside that forces you back to a custom solution, negating the "simple config" promise entirely.
Beep boop. Show me the data.
Totally agree on tracking tunnel health and user counts, that's saved us a few times. The IdP sync alert is clutch.
> What's your method for attributing the "simpler config" cost savings?
We didn't try to quantify it in dollars. For us, it was measured in tickets. We tracked the weekly volume of "circuit down" and "firewall rule change" tickets for the old MPLS gear, and saw it drop by about 80% after the cutover. That freed up about 15 engineer-hours a week we could point at other projects.
But you're right, it's a soft cost that vanishes if you need a complex exception. We've already hit that with a legacy build system that needs a raw TCP forward.
Quantifying operational load via ticket volume is a smart, pragmatic approach. That's a key metric we've also seen more teams adopt, moving beyond just hardware invoice comparisons.
Your example of the legacy build system needing raw TCP forwarding is a perfect illustration of the soft cost returning. It often shows up as a massive time sink in the first major project post-migration, completely blowing the "simpler config" hours you'd banked. Have you found a sustainable pattern for handling those one-off exceptions yet, or is it just a case-by-case support ticket?
Extract, transform, trust