Having evaluated Appgate SDP for a potential zero-trust network access (ZTNA) implementation, I've hit a significant and opaque roadblock during the pricing and licensing phase. The core licensing metric revolves around the number of "networks" one is permitted to define within the system. However, the vendor's definition of a "network" appears highly elastic and, from an infrastructure architecture standpoint, somewhat arbitrary.
In a conventional sense, a network segment could be defined by a CIDR block (e.g., `10.10.0.0/16`). Appgate's administration console allows for the creation of network objects, which are then used in policies to grant access. The critical question is: how are these aggregated or counted for licensing purposes?
My specific concerns are as follows:
* Does a single host entry (`192.168.1.10/32`) consume one entire network license?
* If I define a broader CIDR (`172.16.0.0/12`), does that also count as just one "network," effectively making it more cost-efficient to use large, coarse blocks?
* What about overlapping ranges or the use of DNS names as network identifiers? Are these counted separately?
* Most importantly, is the count based on the number of discrete *objects* in the admin GUI, or is there a behind-the-scenes calculation of unique routed domains?
This ambiguity presents a serious planning challenge. To illustrate, consider two potential approaches to defining access to a set of five application servers:
**Approach A (Five Objects):**
```
Name: app-server-1, Network: 10.0.1.10/32
Name: app-server-2, Network: 10.0.1.11/32
Name: app-server-3, Network: 10.0.1.12/32
Name: app-server-4, Network: 10.0.1.13/32
Name: app-server-5, Network: 10.0.1.14/32
```
**Approach B (One Object):**
```
Name: app-server-cluster, Network: 10.0.1.0/28
```
If each object consumes a licensed "network," then Approach A is five times more expensive than Approach B, despite providing access to the same set of endpoints. This incentivizes poor security practices through over-provisioning access via overly broad network ranges, which is antithetical to the principle of least privilege that ZTNA promotes.
I am seeking clarity from this community based on your procurement and operational experiences. How did your sales engineer or contract ultimately define the unit of "network"? Were you able to negotiate based on unique CIDR blocks, or was it purely a count of configured entities in the system? Any insights into the metering methodology would be invaluable for accurate total cost of ownership (TCO) modeling and architectural design.
Data over dogma
Ah, the classic "per-unit" licensing fog. I've seen this movie before with other vendors. Your instinct about large CIDR blocks being more efficient is probably correct, that's exactly how these models are designed to pressure you.
They'll almost certainly count each defined network object in the admin console, regardless of whether it's a /32 or a /12. A host entry is a "network" to them. The overlap and DNS name questions are where it gets truly arbitrary, and that's the point. The ambiguity isn't a bug, it's a negotiation feature for the sales team. You'll likely only get a clear answer after the procurement dance, when they provide the final quote with a specific limit.
My advice? Force them to define it, in writing, as part of the technical evaluation. Ask for the exact SQL query or API call their system uses to count this metric. If they won't show you, walk away. You're not buying a mystery box, you're buying infrastructure.
monoliths are not evil