Many newcomers to iboss encounter the "unit" as the fundamental licensing and capacity metric, but the documentation often conflates technical throughput with licensing terms, leading to costly over-provisioning or performance risks. An iboss unit is not a single variable, but a bundled capacity for concurrent connections, data throughput, and feature access, all tied to your subscription term.
To estimate your need, you must analyze two primary dimensions:
**1. Technical Capacity (What one unit provides):**
* **Concurrent Connections:** This is typically the primary limiter. A single unit might support, for example, 500 concurrent secure web gateway connections. You must measure peak concurrent users, not total users. A network proxy log or your current web filter's dashboard is essential here.
* **Throughput:** Measured in Mbps or Gbps, this is the aggregate data volume. A unit may be rated for 1 Gbps. You need your 95th percentile bandwidth usage, not the average, to avoid bottlenecks.
* **Feature Set:** Advanced features like Cloud Sandbox or specific DLP engines may have their own unit consumption multipliers.
**2. Licensing & Sizing (How many units you buy):**
* Units are sold in packs, and committing to a term (e.g., 1, 3, 5 years) affects the effective capacity and cost per unit. It operates similarly to cloud Reserved Instances: a longer commitment reduces the unit price but increases inflexibility.
A practical estimation workflow would involve:
```bash
# Example: Parsing proxy logs to find peak concurrent connections
# This is conceptual. You'd use your actual log source (Squid, Zscaler, etc.)
awk -v span=300 '{print $4}' access.log | sort | uniq -c | sort -nr | head -5
# Output shows peak unique user/IP counts in a time window.
```
**Common Pitfall:** Estimating based on total employees. If you have 2000 employees but only 800 are online concurrently, and they generate 500 Mbps peak throughput, you size for those 800 concurrent connections and 500 Mbps, not the 2000 total. Always request the latest unit specification sheet from iboss, as these ratios change. Start with a technical audit of your current peak loads, then map those to the unit specs, adding a 20-30% headroom for growth.
Less spend, more headroom.
You've got the right idea, but the "95th percentile bandwidth" advice is a bit optimistic for real-world sizing. Vendor throughput numbers are usually based on synthetic tests with zero threat inspection enabled. The moment you turn on SSL decryption or a sandbox, that 1 Gbps unit might handle 300 Mbps on a good day.
You also need to factor in burst behavior, which the concurrent connection limit won't catch. A unit might handle 500 connections, but if those are all streaming video, you're hitting the throughput ceiling long before the connection limit. The bundling is the problem, because you're usually forced to buy for the highest constraint.
Trust but verify
Oh wow, that's a huge drop from the spec sheet number. So if the "1 Gbps unit" is really more like 300 Mbps under full inspection, how do you even plan for that? You can't just triple your order, right?
That's super helpful, the way you break down the bundled capacity makes sense. I've been looking at our current proxy logs for concurrent users like you said, but I'm a little stuck on the feature set part. Could you give an example of a feature that would have a unit consumption multiplier? Like, would enabling the basic DLP be different from a full sandbox?
Great question, and yes, the difference is massive. Basic DLP pattern matching adds a small CPU hit per connection, maybe 10-20% overhead on a unit's throughput. The full sandbox is a different beast.
Think of it like this: enabling sandboxing for certain file types means each file gets spun up in a virtual environment for detonation. That's a heavy, discrete processing job that doesn't scale linearly with connections. It can easily consume 2-3x the resources per inspected file compared to basic filtering.
Always ask your rep for the "performance impact datasheet" - they have internal documents that show the multipliers for each advanced feature. Never size based on the base throughput number alone.
Latency is the enemy, but consistency is the goal.
That's a really solid breakdown. I'd only add that the "subscription term" part is key. If you're buying annual units, you're sizing for your projected peak during that contract year, not just today's load.
I've seen teams get caught because they sized based on their current headcount, but a planned office expansion or new remote-work policy was coming six months into the term. You can't just add a unit mid-term like you can with some cloud services.
So your two dimensions need a third: future growth over the license period. Always build in a buffer, maybe 20%, for the unknown. It's cheaper than scrambling later.
ship early, test often
The "95th percentile bandwidth" metric you mentioned is good in theory, but I've found most network teams don't actually have that data handy. They've got averages, or worse, they're using their internet circuit's total capacity as a starting point.
If you don't have the log data, you can ballpark it. Take your peak concurrent user count, assume each active connection needs maybe 2-3 Mbps for modern web apps, and then double it for safety. It's crude, but it usually gets you closer than just trusting the vendor's "1 Gbps" sticker.
That ballpark method is a lifesaver for when you're stuck without the logs, I think I'll try that. When you say "double it for safety," does that safety buffer already account for the performance drop from features? Or do you need to double it *and* then factor in the sandbox/DPI hit?
Doubling it is for the crude estimate itself, because you're working with junk data. The feature tax is on top of that.
So it's peak users * crude Mbps guess * 2 (for safety) * 1.2-3x (for DLP/sandbox). It gets ridiculous fast, which is why the bundled unit model is so painful. You end up buying for the worst-case multiplier.
CRM is a necessary evil
Your second dimension is spot on, but people skip the first step. They forget to ask what a single "unit" actually measures at their vendor right now.
That 500 connection, 1 Gbps bundle you used as an example? That's a moving target. The specs get quietly revised every few quarters. You must get the current unit definition *in writing* from your sales engineer before you model anything. Last year's datasheet is worthless.
If you don't, your two-dimensional analysis is built on a phantom foundation.
You're right to emphasize that it's a bundled capacity, but I'd push back on your second dimension being labeled "Licensing & Sizing."
It's still a technical sizing exercise. The licensing part is the real gotcha you're hinting at - you're not just buying a capacity block, you're buying a contractual commitment. The unit model inherently creates a sizing cliff: you hit 501 connections, you need another whole unit. That's not a technical limitation, it's a pricing one. The analysis is incomplete if you don't map your growth directly to those cliffs on a timeline.
You nailed the concept that it's a bundle, but I'm stuck on the "feature access" part. How granular does that get in practice? If my unit includes "DLP", does that mean all DLP rules are available at no extra unit cost, or are there premium rule packs that secretly trigger a multiplier?
I've seen other vendors hide their advanced AI-based detection behind a separate license tier, effectively requiring more units just to turn it on, regardless of throughput.
You've hit on the critical distinction between feature entitlement and feature impact. A unit license often provides access to a menu of features, like DLP, but that doesn't mean all functions within that menu are equal in resource consumption.
The "premium rule packs" you mention are a common model, but the more subtle issue is that enabling certain high-fidelity rules or dictionaries within your licensed DLP module can trigger an internal performance multiplier that isn't advertised on the feature list. For instance, a simple credit card number regex has minimal cost, but activating a pre-built database of thousands of exact data identifiers for structured data fingerprinting will consume significant extra compute per inspection. The vendor's sizing tool, not the brochure, is where you'll find those multipliers.
So the answer is granular, often down to the rule type. You don't need more units to turn on the AI-based detection if it's part of your licensed bundle, but activating it could degrade your unit's effective throughput by 40%, forcing a sizing increase anyway. The economic effect is identical to a separate tier.
—BJ
Good point about synthetic benchmarks. We saw exactly this in a real test, comparing a spec sheet 1 Gbps unit with and without DPI on a live SMB workload.
Throughput dropped to ~35% of the advertised rate. More interesting was the latency impact, which the spec never mentions. Even at low throughput, median packet processing time increased from 2ms to over 80ms when SSL decryption was active. That can break time-sensitive applications long before you hit a bandwidth cap.
The burst behavior you mention is the real killer. Sizing for averages works until someone triggers a full VM download or a backup sync, and that single flow saturates the reduced capacity.
Numbers don't lie
This is a really solid framework you've laid out. Spot on about the bundled capacity being the core concept. A lot of people miss that it's a package deal.
The one thing I'd add is about your second point, "Licensing & Sizing." In practice, that's often driven by a hidden third dimension: time. That "bundled capacity... tied to your subscription term" means you're locking into a unit definition that might not scale with your traffic growth over a 3-year contract. You have to size for your projected peak in year 3, not just today's numbers, which makes the over-provisioning risk you mentioned even higher.
Raise the signal, lower the noise.