ZPA Architecture Deep Dive — Why It Replaces VPN

Why this lesson matters — the brand-new mental model

The first 8 lessons of this batch lived in one world: egress. A user opens Chrome, hits the internet, ZIA intercepts that outbound request and applies policy. ZIA's whole job is forward-proxying — outbound web traffic, decrypted, inspected, allowed or blocked. Everything you've learned so far is filtered through that lens.

From this lesson onward, flip that mental model 180 degrees. ZPA isn't about a user reaching the internet — it's about a user reaching your internal application that lives in your data centre, your AWS VPC, your Azure subscription, your colo. The traffic direction is inverted. The protocol is different. The threats are different. The architecture is wildly different.

And here's the punchline: ZPA does this without ever giving the user a network. A VPN drops the user onto a flat subnet inside your perimeter — the user can now ping every machine, port-scan every service, and laterally move if the laptop gets compromised. ZPA gives the user exactly one app, brokered through a cloud the user never sees, with the app itself sitting behind zero open inbound ports. That's the Zero Trust pitch in three sentences — and from a CISO's perspective, it's the whole reason ZPA exists.

ZPA vs VPN — the mental flip

Most engineers approach ZPA with a "it's a cloud VPN" instinct. Stop that. The two technologies share zero architectural DNA. Here's the side-by-side you should be able to recite cold in any interview:

If a Lesson-9 student remembers nothing else, remember this: VPN = network. ZPA = applications. Once that one substitution clicks, every other ZPA design decision in this batch becomes obvious.

The four ZPA components — what each one is, where it lives, what ports it opens

ZPA has exactly four moving parts. Every diagram, every troubleshooting flow, every interview question maps back to these four. Memorise them:

1. Z-App (Zscaler Client Connector for ZPA)

The agent on the user's laptop, desktop, phone, or tablet. Same binary as the ZIA Client Connector — one install, both ZIA and ZPA "service profiles" available. When ZPA is enabled in the user's profile, the agent loads a list of application segments (FQDNs and IP ranges of internal apps) the user is entitled to. It intercepts DNS queries that match those segments, returns a synthetic IP from 100.64.0.0/16 (the default ZPA synthetic-IP range — configurable; RFC 6598 CGNAT space is the broader /10, Zscaler uses a slice — guaranteed not to clash with any RFC1918 the user is on), and opens a TLS tunnel to the nearest healthy Service Edge. Supported on Windows, macOS, Linux, iOS, Android, ChromeOS. Z-App listens on no ports — purely outbound TCP/443 (Z-Tunnel 2.0 over QUIC/443 in modern builds, fallback DTLS/HTTPS). TCP/9000 is the App Connector ↔ ZEN control channel, NOT Z-App. Don't conflate the two — it's the #1 ZPA architecture interview trap.

2. ZPA Cloud (the broker / policy engine)

The Zscaler-operated control plane. This is where your tenant lives — your application segments, your access policy, your user/group bindings, your IdP integration (SAML/SCIM with Okta, Entra ID, Ping, Google). Every connection from a Z-App and from an App Connector terminates here, gets authenticated, gets policy-checked, then gets stitched to the other side. ZPA Cloud doesn't run inside your data centre or your cloud — it runs in Zscaler's. You administer it via https://admin.private.zscaler.com (or the cloud variant your tenant is on).

3. App Connector

A lightweight Linux VM (RHEL/CentOS/Ubuntu) that you deploy next to your internal apps — one VM in each "place" you have apps. In AWS, that's one App Connector per VPC (or per region, depending on routing). In your data centre, one in each DC. Minimum spec: 2 vCPU, 4 GB RAM, 16 GB disk — sized for ~1 Gbps throughput; scale horizontally for more. It opens zero inbound ports. It registers to ZPA Cloud over outbound TCP/443 + TCP/9000 to Zen IP ranges, then sits and waits for ZPA Cloud to push it work. When a user's session needs to reach the app this connector serves, the connector dials the app over the local network and stitches the bytes into the tunnel.

4. Service Edge

The regional broker — the actual TCP termination point for the double tunnel. By default these run inside Zscaler's data centres (called Public Service Edges, hosted across ~150+ Zscaler data centres worldwide, anycast-routed). The ZIA Service Edge fleet and ZPA Public Service Edge fleet are architecturally separate broker pools, even though they share PoPs. For regulated industries that can't have user traffic touching Zscaler infrastructure, the same broker software runs as a Private Service Edge inside your DC or cloud — Zscaler manages the code, you provide the compute. Microtenants are a logical isolation overlay on the Public cloud for MSPs and B2B portals serving multiple customer organisations from one ZPA tenant.

The whole architecture on one page

The famous "double inside-out" tunnel

This is the architectural idea that makes ZPA different from every VPN that came before it. Here's the mechanism in plain English:

1. Z-App side — the agent on the user's laptop dials TCP/443 outbound to the nearest healthy Service Edge. The Service Edge sees a new TLS session, validates the cert (issued by ZPA during user enrollment), authenticates the user against the bound IdP, and pulls down the user's policy bundle. The Z-App's tunnel is now "up" — but it's just sitting there, holding the TLS session open, waiting for the user to actually click something.
2. App Connector side — at the same time (continuously, since the connector booted), the App Connector dials TCP/443 outbound to the nearest healthy Service Edge. Same TLS auth, same enrollment cert. The connector tells the Service Edge "I can serve these apps: jira-internal.acme.com, confluence-acme.com, 10.40.0.0/16:1433". The connector's tunnel is now "up" too — also just sitting there.
3. User clicks the app — say the user clicks a Jira link. The Z-App's DNS interceptor catches the lookup for jira-internal.acme.com, returns a synthetic CGNAT IP, and the browser opens a TCP connection to that IP. The Z-App tunnels the SYN to ZPA Cloud.
4. ZPA Cloud brokers — ZPA Cloud sees the inbound stream on the Z-App's side, looks up the user's access policy for this app segment, allow-list checks, posture-checks, and if allowed, finds a healthy App Connector that has advertised this app. It pushes a message down the connector's already-up tunnel saying "stream from user X coming, please dial jira-internal.acme.com:443 on your local network".
5. App Connector dials the app — the connector does a normal local TCP connect to the Jira server (which is sitting in the same VPC or DC, completely unaware of ZPA's existence). The Jira server sees a connection from the connector's IP — just like any other internal user.
6. Bytes flow — ZPA Cloud sews the user's stream and the connector's stream together. Bytes flow bidirectionally. Both legs are TLS-encrypted. Neither end ever knows the other's real IP.

Z-Tunnel 1.0 vs Z-Tunnel 2.0

Any deployment after 2022 should be on Z-Tunnel 2.0. Performance interview questions about ZPA latency almost always hinge on this.

Why the app is "dark" to the internet

This is the security implication that sells ZPA to CISOs. Walk through what a port-scan from the public internet sees against your private Jira after ZPA migration:

• jira-internal.acme.com has no public DNS A record. It only resolves inside Z-App (synthetic IP) for entitled users. nslookup from the open internet returns NXDOMAIN.
• If the attacker somehow gets the internal IP, that IP has no NAT/DNAT to the public internet. There's no firewall rule allowing inbound. The packet drops at the edge.
• The App Connector itself has no listening ports — nmap -sS shows zero open ports. Even a directly-targeted scan against the connector IP returns nothing.
• ZPA Cloud is multi-tenant — even if the attacker discovers your tenant ID and your Service Edge IP, they can't get past TLS without a valid enrolled client certificate. Three layers of trust, separately verifiable: (1) enrollment certificate (provisioned at user enrollment, persists across IdP sessions); (2) IdP-issued SAML assertion (per session); (3) optional Z-App device-posture signals (per session, refreshed every 60-90 sec).

That's "dark application" — it doesn't show up in Shodan, doesn't get hit by automated CVE scanners, doesn't make it into mass-exploitation campaigns. The only way in is through ZPA, which means through the policy engine, which means with proper auth + posture + entitlement. The 2024-style "perimeter VPN concentrator zero-day → ransomware in 6 hours" attack chain has nothing to grab onto.

Public vs Private vs Microtenant Service Edge — when to use which

Public Service Edge — the default

Hosted across ~150+ Zscaler data centres worldwide (ZIA and ZPA fleets are separate broker pools, even though they share PoPs), anycast-routed so Z-App and App Connector both reach the nearest healthy one automatically. Zero compute cost to the customer, Zscaler handles all capacity planning. 95% of deployments only ever use Public Service Edges. Pick this unless you have a specific reason not to.

Private Service Edge — for strict data-residency or regulated industries

Same broker software, but the VM runs in your data centre or cloud account. Use cases: defence contractors who can't have user-to-app traffic touching commercial cloud infrastructure, financial institutions in jurisdictions where regulator says "all session control must stay in-country", healthcare orgs with HIPAA constraints on data flow. The control plane (your tenant config, your policy) still lives in ZPA Cloud — only the data path stays in your premises. Sizing: same as App Connector but multiply by expected concurrent session count. HA: pair them up, ZPA Cloud round-robins.

Microtenant — for MSPs and B2B portals

A Microtenant is a logical sub-tenant inside your main ZPA tenant. Use case: you're an MSP serving 30 customer organisations, each with their own users and their own apps, but you don't want to spin up 30 separate ZPA tenants (cost + admin overhead). Microtenants let one ZPA tenant carve into 30 isolated configuration scopes — each customer sees only their users, their apps, their admins. Same Public Service Edges, just policy-isolated. Also useful for B2B portals where you let partner companies' employees reach a slice of your apps.

App Connector deeper — the operational details L2/L3 engineers must know

The App Connector is the part you'll actually touch most often. Operationally, here's what matters:

What it is technically

A 64-bit Linux VM image. Zscaler ships it as an OVA (VMware), AMI (AWS Marketplace), VHD (Azure Marketplace), and as a YUM/APT package for RHEL/CentOS/Ubuntu if you want to bring your own VM. Minimum spec: 2 vCPU, 4 GB RAM, 16 GB disk. Sized for roughly 1 Gbps and a few hundred concurrent sessions per connector. Scale horizontally — never vertically — past that.

How it registers

You generate a provisioning key in the ZPA admin portal (Administration → App Connectors → Provisioning Keys → Add). The key is one-time-use, bound to a Connector Group (logical grouping per location/cloud/DC), and has an expiry. You paste the key into the connector VM's bootstrap (cloud-init userdata or interactive prompt on first SSH). The connector dials out to ZPA Cloud, presents the key, gets back a per-connector certificate, and from then on uses the cert for all subsequent registrations.

The HA model

Connectors live in Connector Groups. A group is the unit of HA — when ZPA Cloud needs to dial an app served by this group, it picks any healthy connector in the group (round-robin with health weighting). Always deploy ≥2 connectors per group in each region. One connector per region is a SPOF — if that VM patches, reboots, or the underlying hypervisor host fails, every app served by that group goes dark for the user. Two connectors with overlapping segment advertisements = zero-touch failover.

Outbound TLS to Zen — the only ports it opens

The connector needs outbound TCP/443 and TCP/9000 to Zscaler's Zen IP ranges. The CIDR list is published at config.zscaler.com/<cloud>.net/cenr/json — updates monthly + ad-hoc. Subscribe to the trust portal feed for change notifications and set up a cron to pull the JSON and update your egress firewall. It does not need any inbound rule. It does not need outbound to the open internet — only to the Zen ranges. If your egress firewall is strict, allow-list those ranges; don't punch a hole for "all outbound 443".

Real-world scenario — Acme decommissions Pulse VPN, gives 200 contractors per-app access

Acme just acquired a smaller company. The acquired entity has its own Jira and Confluence (call them jira-acq.internal and confluence-acq.internal), hosted in the acquired entity's AWS account, which is now being absorbed into Acme's master payer account. The acquired company also has 200 contractors who need ongoing access to only these two apps — nothing else. They should not be able to see Acme corporate file shares, Acme HR systems, Acme build infrastructure, or anything else.

The VPN-era approach: stand up VPN accounts for the 200 contractors on Acme's Pulse concentrator, drop them onto a "restricted" VLAN, write firewall ACLs from that VLAN allowing TCP/443 to the two specific Jira/Confluence IPs and denying everything else, hope nobody fat-fingers the ACL, hope nobody bypasses the ACL by routing trickery, document the ACL in the change-management system, schedule a quarterly ACL review. Realistic timeline: 6–10 weeks involving the network team, the security team, the access-management team, and a change advisory board.

The ZPA approach:

1. Deploy two App Connectors in the acquired entity's AWS VPC (one per AZ for HA). 30 minutes including AWS Marketplace install and provisioning key paste.
2. Create two app segments: jira-acq.internal:443 + confluence-acq.internal:443. Attach both to the new Connector Group. 5 minutes.
3. Create an IdP group in Acme's Entra ID called acme-acquired-contractors. Sync via SCIM to ZPA (automatic, runs every 40 min). 10 minutes.
4. Write one access policy: "Group acme-acquired-contractors → allow → app segments {jira-acq, confluence-acq}". 5 minutes.
5. Enrol the 200 contractors via Z-App OnePass (email-based one-click enrollment). Day 1: 50 users enrolled themselves. Week 1: all 200.
6. Run "Trace a User" against 3–5 contractors as a smoke test. All pass.
7. Decommission the contractor VPN accounts. Day 2.

Total elapsed time: 1 week, mostly waiting for contractors to click the enrollment email. Total infra surface added to Acme's perimeter: zero. The acquired entity's Jira and Confluence get no public IPs, no firewall rule changes, no NAT entries. The contractors can reach exactly two apps and nothing else — not because of an ACL that has to be maintained, but because that's all their entitlement lets ZPA Cloud broker. If a contractor laptop gets pwned tomorrow, the attacker reaches Jira + Confluence and dies there — no lateral movement possible because there's no network to move in.

This is the Acme story repeated at thousands of orgs going through the same migration. The economics — and the security improvement — are why VPN concentrator vendors are losing the segment one customer at a time.