2026-08-21·8 min read·field notes

ZPA App Connector sizing: there is no users-per-connector number

The question always arrives the same way. Somebody has a user count and a list of sites — 5,000 people, three data centers, two cloud regions — and they want a connector count back. It is a completely fair question to ask, and Zscaler does not answer it.

Not "it's buried in a PDF somewhere." I went looking for the official ratio and it does not exist. Zscaler sizes App Connectors by throughput and by CPU/memory utilization, and never once by how many people are behind them. So every sizing calculator and consultancy blog post that hands you "one connector per N users" invented that number. It might even be a reasonable guess. It is not a vendor figure, and nobody says so out loud.

Here is everything Zscaler does publish, where each number lives, and what to do when all you have is a headcount.

the number that isn't there

Absence is easy to assert and annoying to prove, so here is exactly where I looked. Every one of these is a page you would expect a users-per-connector figure to live on:

• App Connector Deployment Prerequisites — specs, throughput, utilization guidance. No user or session counts.
• About App Connectors — what they are and where they sit. No capacity numbers at all.
• The App Connector management hub — configuration, no numeric capacity guidance.
• Managing Deployed App Connectors — this one has a procedure literally called verifying sizing, which turns out to check that the VM has at least 4 GB of RAM and the right core count. It is a floor check on the box, not a capacity model.
• ZPA Leading Practices Guide — sizes in Mbps. Not in users.

And three dead ends, so you don't repeat them. All three of Zscaler's public ZPA reference-architecture PDFs — the user-to-app segmentation one, the Private Service Edge one, the AppProtection one — contain zero sizing numbers; they are architecture documents, not capacity-planning documents. There is no public Zscaler App Connector sizing calculator. And there is no standalone sizing guide PDF; the prerequisites page plus the Leading Practices Guide is the whole of it.

The consistent shape across all of it: capacity is throughput (Mbps) and utilization (CPU/RAM percentage). Never "N users per connector," never "N connectors per site."

what zscaler does publish

Start with the box. The prerequisites page gives a baseline of 4 GB RAM, 64 GB thin-provisioned disk and one NIC, on 2 CPU cores for a physical machine without hyperthreading or 4 cores for a VM with it. Two quality bars come with it that people skip: a minimum CPU benchmark score of 2640 on the PassMark CPU Mark scale, and AES-NI enabled on the processor. A connector is a TLS box; if you hand it a CPU without AES acceleration, the core count stops meaning what you think it means.

Then the throughput figures, all from the same page:

The baseline line is worded "each App Connector supports up to 500 Mbps of throughput," and the Leading Practices Guide says the same thing with a detail that matters for your arithmetic: "a single App Connector can handle up to 500 Mbps (total inbound and outbound) throughput." That is not 500 down and 500 up. Add both directions before you divide.

The AppProtection row is the one that surprises people — turning on inspection can drop a connector to "100 to 200 Mbps depending on App Connector sizing," which is a quarter to a half of baseline while also asking for double the CPU. One caveat on reading those numbers precisely: the traffic mix Zscaler states on that page (85% GET, 15% POST, 32 KB payloads) is attached to the AppProtection recommendations specifically, not offered as the assumption behind the 500 Mbps baseline. They add that smaller payloads may need fewer resources and yield higher throughput. So these are shaped-traffic numbers, not a guarantee for your file server. ZDX has a smaller version of the same effect: with it enabled, Zscaler recommends connectors have 8 GB of RAM and 4 CPU cores.

The other published number is the scale-out trigger: keep App Connectors "less than 40% for peak memory utilization and peak CPU utilization," and add connectors if you exceed it. Worth knowing that this line sits inside the AppProtection guidance on that page. Zscaler does not restate it as a universal ceiling for deployments without inspection, so treat 40% as a documented number with a stated context rather than a global rule.

double encryption, exactly

Double encryption costs you capacity, and unusually for this topic, Zscaler shows its work. The mechanism first: "the traffic counts double against the App Connector's capacity, versus standard Private Access traffic" — 100 Mbps of double-encrypted traffic spends the same budget as 200 Mbps of normal traffic.

The part I like is that they publish the in-between cases too. It is not a cliff at 100%, and it is not left to you to guess whether the curve is linear. It's a table, and it's linear:

Note the unit on the left column: percentage of applications, not percentage of bytes. If your one double-encrypted app is also the one moving all the traffic, the table is being kind to you.

their own worked example

The prerequisites page ends the sizing discussion with an actual example, and it is the closest thing to a ratio Zscaler will give you. For a 1 Gbps aggregate requirement: 2 to 3 App Connectors if your applications are not using double encryption, but 4 to 6 App Connectors if they are.

Check it against the tables above. 1 Gbps at 500 Mbps each is two connectors to carry the load; at 250 Mbps each it is four. The bottom of each range is the raw capacity math, and this time Zscaler says the rest out loud instead of leaving it to inference. The same page introduces the example by saying the guidance exists "to make sure that you have enough App Connectors to support the connection and room for failover (N+1)." Capacity gets you the bottom of the range. Redundancy, in their own words, is why you don't build there.

Also notice the input to that example. It is a bandwidth number, not a user count, a site count, or a number of app segments.

so what do you do with a user count?

You convert it, and you own the conversion. There is no way around this and no honest way to hide it: turning "5,000 users" into a connector count requires a per-user bandwidth assumption, that assumption is yours, and Zscaler has not blessed a value for it. The failure mode in the wild is somebody quietly picking a number, two rounds of forwarding later it has become "the Zscaler guidance," and now it's in a design document with nobody's name on it.

Better inputs, in the order I'd trust them:

• Measure what the apps already do. Those flows are reaching users through something today — a VPN concentrator, a firewall, a load balancer. Take peak aggregate throughput at that chokepoint, both directions, and that is your Mbps input.
• Size on peak concurrency, not headcount. 5,000 licensed users is not 5,000 simultaneous sessions, and the gap between those two numbers is where the whole estimate lives.
• Split it per location before you divide. Aggregate throughput across five sites doesn't size any of the five — see below, connector groups are location-bound.
• Write the assumption where the reviewer will see it. "sized at N Mbps peak per concurrent user — my estimate, not vendor guidance" is a defensible line in a design doc. A bare connector count is not.

This is also why I'm building a ZPA sizing calculator instead of pointing you at one. It takes throughput, double-encryption and AppProtection usage, and site count. It shows the help.zscaler.com line behind every number it uses. And it will not give you a users-per-connector figure, because there isn't one to give. It's built and in review, not live yet — subscribe below and you'll hear when it ships.

more small connectors, not fewer big ones

There is a line on the prerequisites page that explains why the ratio you want doesn't exist:

That is a blast-radius argument, not a capacity argument. The question Zscaler is answering is not "how much can one connector hold" but "how much do you lose when one dies." A users-per-connector ratio would push you the other way — pack users in until the number says stop. Sizing that starts from failure impact can't produce a headcount constant, which is presumably why they never wrote one down.

"how many" is also "where"

A connector count with no placement attached is not an answer, and placement has one hard constraint. From the Leading Practices Guide: "connectors in a connector group must share the same geographic location (latitude and longitude). This ensures that path selection works as intended," and "to ensure users are connected to a location-appropriate app, place all connectors at a location in the same connector group." That is stated as a correctness requirement, not a preference — Private Access selects the closest App Connector based on user location and connector-to-app latency, so a group that spans two continents is feeding the selector nonsense. The practical rule: one group per site, region or VPC, then size each group on its own.

The AWS deployment guide is the most concrete "how many, where" statement I found anywhere in the docs: "for each VPC, there should be a pair of App Connectors deployed for resilience and scalability," spread across Availability Zones. Two per VPC, in different AZs. That is a floor, not a capacity answer, and it's a useful one.

One more reason the +1 in N+1 isn't optional. Software updates run one connector at a time inside a 4-hour window: when one finishes, another eligible member of the group is chosen, and while a connector is updating "any new application access is redirected to the other software components in the group." So a group is deliberately running a connector short on a routine schedule, not just when something breaks. My inference rather than a stated rule, but it follows: if losing one member during a planned update pushes the survivors past that 40% utilization line, the group was sized for a world where nothing is ever patched.

Last negative finding, and a useful one. Zscaler publishes a minimum group size and no maximum: two healthy connectors is the floor, N+1 is the shape, and nothing in the docs caps how many connectors you can put in one group.

Which leaves a short version you can use in a meeting: sizing is a bandwidth question first, then a question of which features are eating that bandwidth. If someone hands you a connector count with no bandwidth number behind it, ask where the bandwidth number went.