Skip to content
Notifications
Clear all

Guide: Estimating bandwidth needs before you buy ZPA licenses.

2 Posts
2 Users
0 Reactions
1 Views
(@devops_journeyman)
Trusted Member
Joined: 3 months ago
Posts: 61
Topic starter   [#16740]

I've seen a few teams get caught out by underestimating their ZPA bandwidth requirements, leading to performance surprises after deployment. Since ZPA licenses are typically tiered by bandwidth, getting this estimate right upfront can save a lot of budget and headache. Here's a methodical, data-driven approach I've used, pulling from network and application logs.

**Step 1: Identify Your Target Applications & Users**
First, list every application you plan to route through ZPA. Don't just think "ERP system"—break it down:
* Core application traffic (e.g., TCP 443 to app.server.com)
* Any large file transfer processes (e.g., nightly database exports to S3)
* Any associated desktop client traffic (often overlooked)

Then, identify the user groups that need access to each. This forms your matrix for measurement.

**Step 2: Gather Baseline Traffic Data**
You need a week's worth of traffic data, ideally from a proxy, firewall, or netflow logs. The goal is to isolate traffic that *would* go through ZPA. For a rough estimate, you can use a script to filter and sum traffic.

Example: Querying a hypothetical firewall log (conceptual):
```bash
# Pseudo-logic for a CLI tool or script
# Filter logs for: Destination = your app's private IPs/CIDR, Port = relevant ports, Time = business hours
# Sum the total 'bytes transmitted' for the period.

$ analyze_logs --dest 10.10.0.0/24 --port 443,8443 --time 0900-1700 --output total_bytes
> Estimated weekly traffic: 215 GB
```

**Step 3: Apply a ZPA Overhead Multiplier**
ZPA adds encryption and tunneling overhead. Pure TCP/UDP app traffic (like SSH or database) sees about a 5-10% increase. However, if you're tunneling web traffic (HTTP/S), which is already encrypted, the overhead is often negligible. A safe, conservative estimate is to add **15%** to your raw total from Step 2.

**Step 4: Calculate Peak Concurrent Bandwidth**
Licensing is about sustained capacity, not just total data. You must find your peak *throughput*.
1. From your logs, find the busiest 1-hour period.
2. Take the total bytes transferred in that hour.
3. Convert to Megabits per second (Mbps): `(Total_Bytes_in_Hour * 8) / (1024 * 1024)`
4. Apply your overhead multiplier to this peak rate.

**Example Calculation:**
* Busiest hour traffic: 45 GB
* Peak rate: `(45 * 8) / 1024` ≈ **350 Mbps**
* With overhead (15%): ≈ **400 Mbps**

This suggests you should look at licenses that can sustain at least a 400 Mbps peak. Always add a 20-30% growth buffer on top of this final number. This data-driven estimate will put you in a much stronger position when discussing licenses with your Zscaler rep.



   
Quote
(@alexm82)
Estimable Member
Joined: 1 week ago
Posts: 71
 

That's a really helpful starting point. When you say to pull a week's worth of data, what if you don't have good historical logs for a specific app? Like a new SaaS app you're just bringing in.

Is it better to make a rough guess, or would you recommend doing a small pilot with a limited user group just to measure for a week before committing to the full license sizing?



   
ReplyQuote