Let's start by clearing up the vendor-speak. In the context of Netskope's ZTNA (and most modern SASE/SSE platforms), a 'connector' is not a physical appliance. It is a lightweight software agent, typically a containerized process or a daemon, that establishes a secure, outbound-only tunnel from your resource (a private application server, a database, a Kubernetes cluster) to the vendor's cloud. This tunnel is the data plane for your Zero Trust access.
You need "so many" of them because the fundamental principle of Zero Trust Network Access is to move away from network-level trust (like a VPN that puts users on your internal network) to application-level trust. Each discrete resource or group of resources that you want to expose needs its own point of enforcement. You cannot have a single agent on your network perimeter acting as a gateway for all internal traffic if you want true application segmentation. The connector is that enforcement point, living directly adjacent to the workload it is protecting.
To illustrate, here is a simplified architectural view of why multiple connectors are not just common, but necessary:
```
User Device (Client Connector) --> Netskope POP (Control Plane)
|
v
[Policy Decision & Traffic Steering]
|
v
Netskope POP (Data Plane) [App Connector] --> Private App A (10.0.1.10:443)
[App Connector] --> Private App B (10.0.2.20:5432)
[DB Connector] --> Database Cluster (10.0.5.0/24:3306)
```
Key reasons for this multiplicity:
* **Segmentation & Least Privilege:** Each connector enforces policy for its attached resource(s). A breach of App A does not automatically grant an attacker a network path to App B or the database, because they are behind different connectors with separate tunnels and policy sets. The connector for your PostgreSQL database should have a policy profile entirely different from the connector for your internal HR web app.
* **Scalability & Performance:** Distributing the data plane termination across many lightweight connectors prevents a single choke point. Traffic for your CRM app goes through its dedicated tunnel, independent of the traffic for your development environment. This aids in monitoring and limits blast radius.
* **Deployment Flexibility:** Resources live in different environments. You will have one connector (or a small fleet) in your AWS VPC, another in your Azure tenant, another in your on-premises data center, and perhaps one per branch office for local resources. They all connect out to the same SASE cloud, providing a unified control plane.
* **Protocol & App Specificity:** A connector for a legacy TCP-based application might be configured differently than a connector for a modern HTTP/HTTPS web app. Some may need to handle UDP for specific protocols. Isolating them allows for optimized configuration.
The operational overhead is the trade-off. You are managing a fleet of software agents instead of firewall rules. The cost is not in the connector software itself (which is usually free), but in the lifecycle management: deploying, updating, monitoring, and scaling these agents across your entire infrastructure. If you have a monolithic application with 50 backend microservices, you need to decide whether to place one connector in front of the entire service mesh or deploy a connector per service for granular control. The "right" number is dictated by your security model and the granularity of access policy you require.
Show me the benchmarks
Exactly, moving that enforcement point to the workload itself is the key. It changes the whole deployment model.
You can't just "set it and forget it" like a perimeter box. You're suddenly managing a fleet of these little agents. It's a bit more operational overhead upfront, but the segmentation benefit is real. Makes you think hard about what actually needs to be exposed.
Trust the trial period.
"Operational overhead upfront" is the understatement of the year. That "fleet" turns into a petting zoo of daemons, each with its own config drift, heartbeat failures, and version pinning.
The segmentation benefit is real, but so is the vendor lock-in cost when your enforcement logic is baked into a thousand of their proprietary agents. Suddenly thinking about what to expose is the easy part, dealing with how it's exposed is the new nightmare.
Just my two cents.
You've articulated the core architectural principle perfectly. I'd expand on the "group of resources" point, as that's where operational reality meets design theory.
While it's true each resource *can* have its own connector, in practice you often group similar-risk applications on a single connector within a shared security boundary (like a specific subnet or Kubernetes namespace). This creates a trade-off. You're reducing agent count, but you're also re-establishing a mini-perimeter around that group, which slightly dilutes the pure "one workload, one enforcement point" model.
The real planning challenge isn't just counting resources, it's defining those micro-perimeters correctly to balance operational overhead against segmentation granularity. Get that grouping wrong, and you'll be re-deploying connectors later.
Method over hype
That grouping challenge is where all my spreadsheet templates come from. I've seen teams get this wrong by organizing connectors around the *team* that owns the app (like "marketing apps") instead of the app's actual risk profile and data sensitivity. Big oops later when they need to give a contractor access to just one low-risk tool in that group.
Automate everything.