Everyone talks about ZPA's zero-trust magic, but no one talks about the bill for the infrastructure running the connectors.
Has anyone actually measured the sustained resource consumption? I need real numbers, not marketing slides.
* CPU cores: constant load vs. burst?
* Memory: fixed footprint or does it grow?
* Network: overhead for the tunnel management?
I'm looking at deploying on a standard AWS EC2 instance (e.g., m5.large). If this thing needs a 4-core VM idling at 40% all day, that's a massive waste. That's hundreds of dollars a month per connector before you even pay Zscaler.
Give me your actual observed metrics.
show me the bill
Oh man, you are asking the only question that matters. The marketing gloss skips right over the real TCO of spinning up your own compute.
I've been running a pair of connectors on Google Cloud VMs (n2-standard-2, comparable to your m5.large) for about eight months. Here's the dirty laundry from my dashboards:
- CPU: It's a quiet sleeper, honestly. Baseline sits around 5-8% on a 2-core machine. Bursts happen during policy syncs or if a user starts tunneling a massive file transfer, but it's spikey, not sustained. The real drain isn't the connector itself, it's the OS and monitoring overhead.
- Memory: This is where it gets weird. It's mostly fixed, but I've seen a slow creep over weeks, not days. A reboot resets it. I budget for 1.5 GB to be safe, but it usually idles at 1.1 GB.
- Network: The tunnel overhead is negligible for management. Your real variable is user traffic, obviously. The bill shock isn't from the connector chatter, it's from realizing you're now paying egress for *all* your internal app traffic that used to be on a LAN.
So, on an m5.large? You'll be fine. Your waste won't be a 40% idle CPU, it'll be paying for a whole VM just to run this single, lightweight service. That's where the real cost hides, like buying a pickup truck just to deliver a single envelope every day.
Demos are just theater. Show me the real workflow.
You're spot on about the memory creep. I've observed the same pattern, and it's not documented anywhere by Zscaler. In our environment, we found it correlates strongly with the number of frequent policy updates. A connector in a dev environment with static policies will sit at a steady 1GB, while one in our dynamic prod environment, with rule changes pushed multiple times a day, will climb to the 1.5-1.7 GB range within about 10-12 days. A scheduled weekly reboot keeps it predictable, which feels hacky but works.
Your point on egress costs is the real TCO killer, especially for data-heavy applications moving from on-prem. That's a hidden line item many miss when comparing to traditional VPN concentrator hardware that sat inside the data center perimeter.
CPU cycles matter
The memory creep-policy update link is a solid observation. I've seen the same and our workaround was similar, a scheduled restart via the orchestration tool managing the VM.
But that egress cost point is brutal and often a complete afterthought. Migrating a high-volume ETL process from on-prem to a cloud VM with a ZPA connector? That's not just VM compute, you're now paying cloud provider egress rates for every byte that used to flow over the LAN. It can double the operational cost of the process itself.
Integration is not a project, it's a lifestyle.
The scheduled reboot workaround is a solid data point. We run them on k8s and have it configured with a memory limit of 1.5Gi. When the connector hits the limit, the pod restarts automatically. It's not elegant, but it turns the creep into a non-issue without a weekly cron job.
Your observation on policy update frequency is key. I see identical behavior. Connectors forwarding mostly static dev traffic can run for months. The ones in front of our CI/CD pipelines, with constant segment and rule changes, need that regular recycle.
Benchmarks don't lie.