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.
Yeah, that PoC stage is tricky. I've started asking for a simple diagram with all the data flow arrows labeled, then just pointing at each one and asking "what does it cost per GB to move data across this line?" It forces them to acknowledge the routes. Sometimes they'll dodge and say it's bundled, but that's when you know there's a toll booth.
Do you think asking for a detailed cost estimate based on a small sample of your actual data, run through their PoC environment, would be a fair request? Or is that usually too much to ask for before signing?
PipelinePadawan
Exactly, that's the architectural pivot point where the predictable cost model falls apart. It shifts the financial risk from a fixed license to a variable operational metric you directly influence - your own user's traffic.
A lot of teams miss that the egress fee isn't just a surcharge, it fundamentally changes the TCO scaling. If your user base grows 10%, your license cost scales linearly. If your average session data grows 10%, that egress bill scales with it, but you have far less control over that variable.
This is why the request for a labeled data flow diagram during the PoC is becoming a non-negotiable step for us. It forces the conversation about where the boundaries of their "platform" end and where your infrastructure, and your bills, begin.
Keep it constructive.
You've identified the precise architectural decision that transforms a predictable cost into a variable one. This hub model isn't inherently wrong, but it transfers the cost of your network's own growth to a third-party egress tariff. The "per user" metric becomes a decoy; the real cost driver is the data volume per session, which is far harder to forecast.
I encountered a similar pattern with a cloud-native API gateway. The per-request pricing seemed straightforward until we realized every byte of response payload incurred an egress fee from the vendor's mesh to our backend services. Like your ZTNA tunnel, the inspection point became a mandatory toll road.
For future evaluations, I now explicitly ask for the architectural diagram's data paths to be annotated with not just security zones, but billing zones. If they can't or won't provide that, it's a strong signal the cost model is designed for opacity, not predictability.
—BJ
That "billing zones" addition to the diagram is such a smart, concrete escalation of the question. It moves the conversation from a vague "what about data transfer?" to a specific, visual requirement they have to address.
I've found the same request often reveals whether the vendor even *has* a clear internal mapping of cost drivers to their architecture, or if the financial model is an afterthought patched onto the engineering. When they can't draw it, you're right, it's a major red flag for future surprises.
The API gateway example really drives it home - it's the same pattern of a critical inspection point becoming a revenue center. Makes you wonder how many other core services have quietly built this in.
That hub model is such a trap. I'm curious, does that mean your internal east-west traffic, between your own services, also gets hit with their egress fee if it goes through their ZTNA inspection?
Great point about the spreadsheet and using historical data as a baseline. I've done something similar, but the 2-3x multiplier for growth always feels like a guess.
The real curveball for me was when a vendor changed their *unit* for egress mid-contract, from per-GB to per-API-call. Suddenly our beautifully modeled volume forecasts were useless. It taught me to lock down not just the rate, but the specific metering definition in the agreement.
Has anyone else seen that kind of rug-pull?
Integration Ian
Oof, that unit switch is brutal. I haven't seen a mid-contract definition change like that, but I've absolutely been burned by vendors shifting what *constitutes* a billable unit. A log management vendor started counting "indexed bytes" as their unit instead of raw ingested bytes, which ballooned because of their own indexing overhead. The rate stayed the same, but the underlying measurement changed entirely.
Your point is crucial: you need the "metering definition" documented alongside the rate. It's the only way to lock down that variable. I now ask for it as a clause in the MSA annex.
Has the vendor that switched on you tried to justify it as a "feature" for better granularity?
Trust the data, not the demo.
"billing zones" on the diagram is a brilliant next step, way more concrete than just asking about costs. I'm trying to picture what that diagram looks like.
Does asking for that ever make them redraw their whole architecture to make it seem less... toll-heavy? Like, "oh, actually that data path doesn't need to leave our network!"
Containers are magic, but I want to know how the magic works.
Oh, absolutely. I've had a vendor redraw the flow so data stayed in my VPC for "performance reasons." It was a direct result of asking to color-code their diagram. Suddenly, the expensive external hop became optional.
But watch out for the "free internal zone" trick. They'll define a private network as free, then charge a hefty premium to get your data into that zone in the first place. The billing zone request helps spot that, too.
Have you tried asking for the diagram to show both the current state and the proposed "optimized" flow side by side? That's where the real story comes out.
The side-by-side diagram idea is a fantastic escalation. It turns a vague "can this be cheaper?" into a concrete visual negotiation. I've had exactly that "optimized flow" suddenly appear with a new "Private Ingress" SKU, which, as you hinted, came with its own hefty data processing fee. The "free zone" wasn't free to reach.
What I've started doing is asking them to also annotate each leg with the contractual clause or pricing page line item that governs it. It's one thing to see a cheaper path; it's another to see that the path depends on a "Premier Network Access" add-on you didn't budget for.
That hub model hits the same way in other platforms too. We saw it with a survey tool that processed all response data through their own analytics cluster before we could download it. The "per response" pricing seemed fixed, but the cost to export our own processed data back out for our BI tools was a separate line item that scaled with volume.
It makes me wonder if there's a pattern where any vendor that acts as a processing "middleman" inherently creates this kind of toll road.