ZPA Connectors — Deploying App, Branch & Cloud Connectors in Production

Why this lesson matters — connectors are where ZPA becomes real

Lesson 9 left you with a clean architecture: four components, double inside-out tunnel, dark apps, no inbound ports. That diagram is honest, but it hides the fact that one of those four components — the App Connector — is literally a Linux VM you have to build, harden, register, monitor, patch, scale, and pair into HA groups, in every place an internal app lives. The architecture diagram does not run itself.

This is the lesson where ZPA stops being slideware and becomes a deployment plan. The choices you make here — where you place connectors, how many you run per failure domain, what size you give them, which group they join, what your egress firewall allows them to talk to — directly determine three things students will be measured on in interviews and in their first 90 days on the job:

• User experience. A user in Mumbai brokered to a connector in Virginia adds 220 ms RTT to every Jira page load. Wrong region = bad-user-experience ticket, every day, forever.
• HA posture. One connector per region is a single point of failure. The day it patches, reboots, or its hypervisor host has a bad day, every user in that region loses every app served by it. CISOs and ops leads will both hate you for that.
• Cost. Over-provisioning eight 8-vCPU connectors per region "to be safe" turns a small ZPA deployment into a six-figure cloud bill. Right-sizing matters.

The cousins — Branch Connector and Cloud Connector — solve adjacent problems (office user egress to ZIA, and cloud-workload egress to ZIA respectively). Most people new to ZPA confuse them. We will fix that explicitly, because in production you will be asked to recommend one over the other on day one.

The three connector flavours — when to use which

Zscaler ships three connector products. They look similar (lightweight Linux VM, outbound-only, registers to Zscaler Cloud), but they serve completely different traffic patterns. Get this table cold before week one — recruiters love asking it.

Plainer rule of thumb:

• User trying to reach a private app? App Connector.
• Office full of users trying to reach the internet (and you want ZIA in front)? Branch Connector.
• Cloud workloads trying to reach the internet (and you want ZIA in front, without per-VM agents)? Cloud Connector.

One more nuance students miss: Branch Connector does not serve ZPA. If you have a branch office that needs both internet inspection and access to private apps, you deploy Branch Connector at the edge (for ZIA forwarding) and install Z-App on the user devices (for ZPA). Branch Connector and App Connector are not substitutes for each other.

The whole picture on one page

App Connector — VMware / AWS / Azure deployment walkthrough

You will deploy more App Connectors than the other two flavours combined, because every place a private app lives needs one. Three deployment surfaces dominate: VMware in the DC, AWS in a VPC, Azure in a VNet. The prereqs are nearly identical; the install mechanics differ slightly.

Prereqs that bite in pilot

• Supported base OS: RHEL 8 / 9, CentOS Stream, Oracle Linux 8 / 9, Ubuntu 20.04 / 22.04 LTS. Amazon Linux 2 is supported on AWS specifically. Don't pick something exotic — the Zscaler-shipped package only knows about these.
• VM spec: 2 vCPU / 4 GB RAM / 16 GB disk is the official minimum and a fair starting point for ≤1 Gbps and a few hundred concurrent TCP sessions. Voice or heavy RDP loads should jump straight to 4 vCPU / 8 GB.
• Outbound network: TCP/443 and TCP/9000 to Zscaler's Zen IP ranges. The TCP/9000 control channel is the one people forget; without it the connector registers but cannot accept brokered streams. Pull the JSON CIDR feed from config.zscaler.com and allow-list it on your egress firewall before you boot the VM.
• NTP: the enrollment cert is time-sensitive. If the VM's clock drifts by more than a few minutes, registration silent-fails with a misleading "auth error" in the log. Run chrony or ntpd on the VM and verify chronyc tracking is in sync before enrolling.
• SELinux / AppArmor: the connector ships with a tested SELinux profile. If your hardening playbook strips it or sets enforcing without the Zscaler context, outbound TCP/9000 can be silently blocked. setenforce 0 during the very first boot to confirm it's not the culprit, then re-enable with the shipped policy.
• Provisioning key: generated in Administration → App Connectors → Provisioning Keys → Add. The key is one-time-use, bound to a Connector Group, and expires (default 14 days). Don't generate it a month before deployment — it will be dead when you finally need it.

Install script — AWS (Amazon Linux 2)

This is the path you'll use most often in modern deployments. Spin up an EC2 instance (t3.medium or larger, in a private subnet, with a NAT Gateway for outbound), then bake the connector in via cloud-init userdata:

# 1. Download the App Connector RPM from the ZPA Admin Portal:
#    Administration → App Connectors → Download → Linux (RHEL/CentOS)
#    OR use the published cloud image (AMI / Azure VHD / GCP image)

# 2. Install the RPM on a 2vCPU/4GB minimum RHEL 8/9 or CentOS 8 host
sudo yum localinstall -y zpa-connector-VERSION.x86_64.rpm

# 3. Drop the provision key (copied from the same Admin Portal page)
sudo bash -c 'echo "YOUR_PROVISION_KEY" > /opt/zscaler/var/provision_key'
sudo chown zscaler:zscaler /opt/zscaler/var/provision_key
sudo chmod 600 /opt/zscaler/var/provision_key

# 4. Enable + start the service. Registration happens automatically on first start.
sudo systemctl enable --now zpa-connector

# 5. Verify
sudo journalctl -u zpa-connector -f
# Look for "Successfully enrolled" and "Connected to broker"

Within roughly 30 seconds the connector appears in the ZPA admin portal as Healthy, attached to whichever Connector Group the provision key was bound to. Repeat the whole exercise on a second EC2 in a different availability zone — same Connector Group — to satisfy N+1 HA from day one.

VMware (DC) and Azure (VNet) — the differences

• VMware: Zscaler ships a signed OVA from the admin portal. Deploy via vCenter, set static IP via the VMware console (or DHCP if your DC tolerates it), paste the provisioning key into the first-boot wizard. Otherwise the post-install steps are identical to the YUM flow.
• Azure: Use the official Azure Marketplace image (search "Zscaler App Connector"). Deploy into a VNet subnet that has outbound NAT (Azure Firewall, NAT Gateway, or a UDR to a network virtual appliance). Provisioning key goes in via the cloud-init custom data field. Make sure the NSG does not have an inbound rule on TCP/9000 — that port is outbound-only from the connector and there is no inbound listener.

App Connector auto-update

App Connectors auto-update from the cloud by default — Zscaler pushes new versions on its own cadence, no admin action. For change-controlled environments (banking, healthcare): pin a version under Administration → App Connectors → Group → Version Pinning. Without pinning, a connector might silently upgrade on a Tuesday afternoon — keep this in your change calendar.

Connector log paths

Log paths: /var/log/zpa/connector.log (active), journalctl -u zpa-connector -f (systemd stream). Set LOG_LEVEL=DEBUG in /etc/zpa-connector/config only for active troubleshooting — debug logs are massive.

Capacity sizing — concurrent users per connector by app type

The single biggest day-one sizing mistake is treating "concurrent users" as a single number. ZPA throughput depends massively on the protocol mix. A connector that comfortably brokers 1,500 Jira (HTTP) users will buckle at 200 RDP users. Use this as your starting calculator:

Two rules to take into every sizing conversation:

1. Always N+1 per group. If your math says one connector handles the load, deploy two. If two handle it, deploy three. The +1 covers patching, hypervisor failure, and unexpected load spikes without a user-visible outage. A "perfectly sized" single connector is a deployment that will fail its first patching window.
2. Scale horizontally, never vertically. The connector is single-process and gets diminishing returns past 8 vCPU. Five 4-vCPU connectors will out-throughput two 16-vCPU connectors and survive an AZ failure that the bigger pair cannot.

HA — Connector Groups and how ZPA Cloud picks a connector

A Connector Group is the unit of HA in ZPA. Group connectors by failure domain — usually one group per AWS AZ, one per Azure availability zone, one per DC row, one per branch DC building. Not by application. An app segment gets attached to one or more Connector Groups; when a user request arrives, ZPA Cloud picks any healthy connector from any attached group, weighted by latency and load.

Geometry that works in production:

• Per region (e.g. Mumbai DC): two App Connectors, in two separate VMware clusters or two AZs, both in the same Connector Group "mumbai-dc". App segments served only by Mumbai apps are attached to this group only. Users in India naturally route to Mumbai connectors (lowest RTT).
• Multi-region apps: if the same app exists in two regions (active-active), create the same segment in both region groups. ZPA Cloud will pick the closer one for each user.
• Cross-region failover: Connector Groups can have a priority order. Set Mumbai as primary, Singapore as secondary. If both Mumbai connectors die, users gracefully shift to Singapore at the cost of a one-time latency hit — far better than a hard outage.

How a connector actually boots and joins the pool

Branch Connector — when to put it at the office edge

Branch Connector is built for one specific shape of customer pain: a small office, no full-featured firewall, users on guest-grade Wi-Fi, and the business wants their internet traffic inspected by ZIA without buying SD-WAN. Branch Connector ships as a hardware appliance OR as a VM (KVM / Hyper-V / ESXi). The smallest hardware SKU competes with SD-WAN CPE pricing — not "NUC in a closet" cheap. Plan for ~$1.5k–$5k per branch hardware + tenant license. All office user traffic is forwarded — via a lightweight TLS tunnel — to the nearest ZIA Public Service Edge, where full URL filtering, SSL inspection, malware scan, DLP, and sandbox kick in just as if every user were running Z-App.

Use Branch Connector when:

• The office has no firewall capable of GRE or IPSec tunnels to ZIA — i.e. nothing better than a consumer-grade router. Branch Connector replaces the missing firewall edge.
• You're doing a tactical / event deployment — pop-up event office, temporary site for a 3-month project, M&A acquisition where you don't yet own the network. Stand up a Branch Connector VM in an hour; instant ZIA coverage.
• You have a guest Wi-Fi only branch — kiosks, shop floors, lobbies — where you don't want to install Z-App on user devices (you don't manage them) but you do want internet hygiene at the SSID.

Do not use Branch Connector when:

• The branch already has a Palo Alto / Fortigate / Meraki / Cisco firewall capable of IPSec. Just configure a GRE or IPSec tunnel to ZIA — fewer moving parts.
• You need to give office users access to private apps. Branch Connector does not serve ZPA. For that, install Z-App on user devices, even at branches running Branch Connector.

Cloud Connector — when to anchor cloud-workload egress

Cloud workloads — EC2 instances, GKE pods, Azure VMs, container hosts — egress to the internet for package downloads, API calls, telemetry, and SaaS APIs. Without intervention this egress goes through your VPC's NAT Gateway directly to the internet, completely unfiltered. You don't see what's leaving, you don't apply DLP, you don't catch a compromised container talking to a C2 server.

The naive fix is "install Z-App on every workload". This is awful: containers are ephemeral, autoscaling groups bake new images, the agent install becomes a per-AMI baking concern, and a runtime crash takes a workload offline. Cloud Connector is the answer: a small VM (or a pair, for HA) that you deploy inside the VPC and point your workload subnet route tables at. All outbound traffic from those subnets is captured by Cloud Connector, tunnelled to ZIA Public Service Edges, inspected, and only then released to the internet. The workloads themselves are unmodified.

Use Cloud Connector when:

• You have ephemeral workloads (containers, autoscaling EC2, serverless behind a VPC) where per-instance agent management is not feasible.
• You want to anchor source IP for SaaS allow-listing — many SaaS vendors only allow your tenant's API key from specific source IPs. Cloud Connector gives you a stable egress IP regardless of how many workloads are behind it.
• You need full URL filtering + DLP + sandbox on outbound HTTPS from cloud workloads, without inflating each container image.
• You have a dev VPC with 200 ephemeral workloads doing npm install from arbitrary registries; you want every POST they make inspected before it leaves.

Real-world scenario — migrating off F5 APM across four DCs

Customer: a mid-size manufacturer running F5 APM as their VPN concentrator for engineering, sales, and contractor remote access. Four data centres: Mumbai, Singapore, Frankfurt, Virginia — each running its own Jira, Confluence, Bitbucket, SAP module, and internal toolchain. ~12,000 employees, ~3,000 concurrent VPN users on a typical weekday. F5 APM is two years from end-of-support; the customer wants ZPA before it dies.

Your job: design and deliver the connector layout, then a phased cutover that does not cause a production outage.

Step 1 — Connector layout (the design that survives the runbook)

• Per DC: two App Connectors, deployed in two separate VMware clusters (different racks, different power feeds, different ToR switches). Both connectors join the same Connector Group named after the DC — e.g. cg-mumbai, cg-singapore, cg-frankfurt, cg-virginia. That gives you N+1 per region from day one.
• Sizing: Jira / Confluence / Bitbucket dominate the protocol mix (HTTP), with a smaller RDP workload for finance teams. From the sizing table, 2 vCPU / 4 GB per connector handles ~250–500 concurrent HTTP sessions; with ~750 expected per DC at peak, scale to 4 vCPU / 8 GB and deploy at least two per DC, or run 3 × 2-vCPU connectors in the group. The horizontal route (3 × small) gives better blast-radius isolation than one big VM — and survives a single-node patch reboot without user-visible impact.
• Cross-region failover: set group priorities so each region's primary is itself, with the geographically nearest region as secondary — Mumbai primary / Singapore secondary, Frankfurt primary / Virginia secondary. If both Mumbai connectors die, users transparently shift to Singapore at the cost of ~60 ms RTT — far better than a hard outage.
• App segments: one segment per app per region (not per /16). jira-mumbai.acme.com, jira-singapore.acme.com, etc. Each segment attaches to its region's Connector Group only (plus the secondary as failover).

Step 2 — Cutover plan that avoids drama

1. Deploy + register connectors in all four DCs. Verify all eight show Healthy. Run the canary segment test from a script for 24 hours; expect zero failures.
2. Pilot group of 50 users across all four regions, mixed roles. Push the Z-App with ZPA profile enabled to these users only; leave F5 APM available as fallback. Run for 7 days. Watch the connector health graphs, the ZPA Trace User reports, and the user-feedback channel.
3. Expand to 500 users per region — broader role mix, including a few notoriously fussy engineering tools. Another 7 days. Tune segment definitions for any app that surfaces as misconfigured.
4. Cutover wave 1 — engineering org (3,000 users). Flip Z-App ZPA profile via Intune for the whole engineering AD group on a Friday afternoon. Monitor through the weekend. F5 APM still up but no longer the default route.
5. Wave 2 + 3 — sales then back-office orgs over the next two weeks.
6. Decommission F5 APM after 30 days of stable ZPA-only operation, with a 7-day "switchback window" where APM stays cold-spare in case of catastrophic ZPA regression.

What goes wrong if you skip the regional grouping

This is the war story junior engineers learn the hard way. Imagine you skip Step 1's regional grouping and instead create a single global Connector Group with all eight connectors. ZPA Cloud's broker is latency-aware but not infinitely smart; some Mumbai users will get brokered to Virginia connectors when Virginia is momentarily less loaded than Mumbai. The user's Jira-Mumbai request travels Mumbai user → Mumbai Service Edge → ZPA Cloud → Virginia App Connector → back across the Internet to Mumbai DC's Jira server → all the way back. Round-trip time goes from ~30 ms to ~430 ms. Every Jira page load adds half a second. Users complain. Tickets pile up. You eventually re-architect with regional groups — which is what you should have done on day one.

Lesson: Connector Groups are not just an HA boundary, they're a routing boundary. Use them to express "this connector should serve this region's users" as well as "this connector should serve this region's apps". Both meanings are correct simultaneously.