Alright, let me add another data point to the collective misery of cloud security procurement. I’ve been knee-deep in ZTNA evaluations for the last year, and like many here, I ran Netskope through its paces. The platform itself? Competent. The sales engineering demo? Polished. The post-sale reality of their consumption model? A masterclass in obfuscated costs.
My specific, and frankly amateur, error was accepting their “per user, per month” quote at face value as a predictable operational expense. Where they got me, and where I failed to do the requisite cynical digging, was on the architecture’s inherent data transfer fees.
Here’s the breakdown they don’t lead with:
* **The ZTNA tunnels terminate in *their* cloud, not yours.** Every byte of traffic from your user to a private app, even if that app is sitting in AWS us-east-1, first routes through the nearest Netskope POP. This is the standard hub-and-spoke model.
* **The egress charge is from *their* data center to *your* infrastructure.** This is the critical leg. Once the traffic is inspected and permitted, it egresses their cloud to your app’s actual location. That data transfer carries a cost, billed by Netskope, separate from your cloud provider’s potential ingress fees.
* **It’s a variable cost on top of your commit.** Your committed “per user” fee gets you the client and the policy engine. The bandwidth consumption, especially for data-heavy internal applications (think large file shares, CAD systems, video repositories), is the meter that keeps running.
In our first full month of a 500-user pilot for a technical team that regularly pulls multi-gigabyte datasets from a colo, we saw a 22% overage on the projected bill purely from this egress. When questioned, our account rep provided the data transfer rates (which are, of course, in the contract annex but not highlighted). The justification was standard “cloud infrastructure costs” language.
The lesson, which I should have known from years of SaaS procurement, is this: **A “per user” quote from a cloud-delivered security vendor is only half the story.** You must model the data paths.
**For any serious evaluation, you need to demand:**
* The specific data transfer rates per GB for egress from their POPs to major cloud regions and the internet.
* Historical or projected data usage patterns from your own environment. What’s the average daily egress per user for your heavy teams?
* A clear understanding of what, if any, traffic is *excluded* from these charges (e.g., traffic to their embedded CASB services might have a different calculus).
Without this, you’re signing up for a variable cost infrastructure bill wearing a per-user subscription disguise. I negotiated a slightly better rate post-facto, but it was a painful reminder to never let vendor pricing models lull you into skipping the fundamental TCO breakdown. The bandwidth is never free.
show me the tco
Ouch, that's a painful lesson. I've seen something similar with data transfer costs when using cloud-hosted ETL tools, where processing happens in the vendor's region. You think you're just paying for compute, but moving the processed data back to your own storage can have a huge surcharge. It's never just the license fee, is it? How do you even model for that kind of variable cost during planning?
rookie
You've absolutely nailed the core issue with the ETL comparison: the cost isn't in the license or the compute, it's in the movement between bounded contexts, which is often treated as a free variable. Modeling it requires a fundamental shift from a static cost model to a data-flow model. I've had to build spreadsheets that treat each pipeline stage as a node with an associated egress tariff, using historical average data volumes as a baseline, then apply a 2-3x multiplier for growth. The real surprise for many teams comes when they realize that 'processed data' is often *larger* than the raw data due to indexing or enrichment, amplifying the transfer fee.
No free lunch in cloud.
Yep, that hub-and-spoke model gets a lot of folks. It's the classic "trusted third party" architecture, and the egress fee is its shadow tax. The worst part is, you often can't even see the per-gigabyte rate until you're deep in the contract annex.
We had a similar issue with a cloud access security broker. The demo focused on threat detection, but the bill was dominated by the cost of sending all that 'secured' traffic back out to our own VPCs. It makes you start reading architecture diagrams looking for hidden toll booths.
Have you found a good way to get these egress rates clarified during the PoC stage? Sales engineers always want to talk features, not line items.
Raise the signal, lower the noise.