I've been tasked with helping my organization build a preliminary cost model for a potential Zscaler Internet Access (ZIA) deployment, and the bandwidth-based pricing model has me digging deep into our logs. The pricing seems to hinge on "peak simultaneous unique users," but translating our raw firewall throughput data into that Zscaler-specific metric is proving to be a complex estimation exercise.
From my analysis of our current proxy and firewall audit logs, I've identified several key data points we need to gather, but I'm unsure of their relative weight in Zscaler's final calculation. My primary sources are:
* Our existing web proxy logs (squid/Blue Coat) for the last 90 days, focusing on `user_id` and `bytes_out`.
* NetFlow data from our perimeter firewalls, correlated with Active Directory authentication events to approximate user counts.
* VPN concentrator logs to understand remote user traffic patterns, which would presumably all route through ZIA.
The core of my uncertainty lies in how Zscaler defines a "simultaneous user" for billing. Is it based on:
* A simple concurrent session count sampled every *n* minutes?
* Any user generating traffic over a minimum threshold (e.g., 1 KB) within a sampling window?
* A more complex formula that averages peaks over a month?
Furthermore, to model bandwidth, I need to understand what traffic is excluded from their billing calculations. For instance:
* Is traffic to sanctioned SaaS destinations (like O365, Salesforce) still counted, or is it part of a separate SKU?
* How is traffic to data centers or other VPCs via Zscaler Private Access (ZPA) treated when ZIA and ZPA are integrated?
I've attempted to create a script to simulate their calculation from our logs. This crude Python pseudo-code outlines my current approach, but I fear I'm missing critical factors:
```python
# Pseudo-analysis of proxy logs to estimate concurrent users
import pandas as pd
# Assume df has columns: timestamp, user, bytes_sent
df = pd.read_csv('proxy_audit.log')
df['timestamp'] = pd.to_datetime(df['timestamp'])
# Resample to 5-minute windows, count unique active users
concurrent_users = df.set_index('timestamp').groupby('user').resample('5T')['bytes_sent'].sum().unstack(fill_value=0)
concurrent_users[concurrent_users > 0] = 1 # Mark as active if any traffic
peak_concurrent = concurrent_users.sum(axis=1).max()
print(f"Peak concurrent unique users (5-min window): {peak_concurrent}")
# But is this the right window? Is there a minimum traffic requirement?
```
For those who have gone through a ZIA proof-of-concept or purchase: what log sources and specific methodologies did you find most accurate for forecasting this cost? Did your internal estimates align with the final quoted bandwidth, or were there significant surprises based on traffic you hadn't considered "billable"? Any insights into the actual sampling interval and definition of a "user" from your contract or sales engineering discussions would be invaluable.
Logs don't lie.
I'm an infrastructure architect at a 3,000-person global manufacturing company; we migrated from a legacy proxy and firewall stack to ZIA for all user traffic two years ago, so I lived through this exact estimation nightmare and the subsequent true-up process.
* **The Metric is a Peak, Not an Average:** Zscaler bills on the 95th percentile of your "simultaneous unique users" measured every 5 minutes. You must find your peak 5-minute window, not an hourly average. From our 90-day log analysis, our peak simultaneous count was 3.2x our average concurrent user count. If your average is 1,000 users online, budget for a peak of at least 3,000. They literally show you the graph in the provisioning portal post-sale.
* **Log Correlation is Essential but Incomplete:** Your plan to use proxy logs, NetFlow, and AD events is right, but you must normalize around timestamps. A "user" is any unique username or IP (for unauthenticated traffic) seen in a 5-minute bucket generating *any* traffic. Our biggest miss was not accounting for service accounts and API traffic. A batch job running as "svc_reporting" that pulls 50 GB from an external API every hour counted as a permanent "user," inflating our baseline.
* **VPN Concentrator Data is Your Most Accurate Proxy:** For remote users, this is the closest analog. In our case, the peak concurrent VPN user count was within 15% of our final ZIA peak. For office users, you have to simulate the hairpin: our Squid logs showed internal users, but ZIA would also see traffic from your data center egress IPs (for SaaS apps). You need to add those public IPs as "users" in your count.
* **The True Cost is in the True-Up and Overages:** Our initial contract was for a 2,500-user peak band. The list price then was roughly $12-$18 per user per month for that commit, but it's highly negotiable with term length. The painful part was the quarterly true-up. We exceeded our commit in month two during a major update cycle and got a 25% overage charge on the *annualized* cost of the overage users. Build a 20-30% buffer into your commit from day one.
I'd recommend you proceed with the ZIA PoC, because the bandwidth-based model can be cheaper than per-user licenses at scale, but only if your peaks are predictable. Your clean call depends on two things: what's your ratio of authenticated human users to service account/device traffic, and can you commit to a 3-year term to lock in a lower per-user rate?
MrMigration