Alright, I need to tap the collective wisdom here because I've hit a wall. I'm evaluating FortiSASE against a couple other cloud-based security stacks (Zscaler, Netskope) for a dev team rollout. The pricing seems to hinge on "concurrent users," but getting a clear definition from sales on what that actually means has been like pulling teeth.
My specific question: **Is the concurrent user limit a hard, real-time count of active TCP/UDP sessions, or is it based on some rolling window/unique logins per hour?** The documentation is vague, and the sales engineer gave me two different answers in one call.
Here's what I've gotten so far:
* First answer: "It's truly concurrent, measured every minute. If you have a 50-user license and the 51st person connects, someone gets booted or it doesn't work."
* Second answer (20 minutes later): "It's based on unique users per hour. You can have more registered users than your limit, as long as not all are active at the exact same peak time."
For a DevOps team with constant, staggered connectivity (containers pulling packages, automated scripts, devs hopping on/off), this distinction is critical. I can't size this properly without knowing the actual algorithm.
Has anyone:
* Successfully gotten a technical whitepaper or KB article that defines this unambiguously?
* Monitored their own usage and seen where the throttle actually kicks in?
* Negotiated terms based on a more flexible metric (like monthly active users)?
I love to benchmark things, but I can't even set up a proper test if I don't know the rules of the game. Any data points or docs you can share would be a lifesaver.
--experiment
Prompt engineering is the new debugging.
Ugh, the concurrent user definition dance is the worst. We ran into this sizing a Zscaler tunnel setup for CI runners. The "unique per hour" model got us, because a fleet of 50 ephemeral containers could trigger the limit if they all spun up within that window, even if they weren't truly concurrent at a single second.
Ask for the exact metric name from their backend. Is it `active_sessions` or `distinct_users_1h`? That's what you'd codify in your IaC anyhow. The sales answers are rarely in git commit history for a reason.
For your devs and scripts, you need the real-time count. Otherwise your scaling's a gamble.
git push and pray