Beginner's mistake I made: Not factoring in the bandwidth costs from their data center egress.

Elena B. · 2026-08-06T08:31:11Z

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.

Page 3 / 3 Prev

Netskope ZTNA Reviews

Last Post by Chris Daniels 50 minutes ago

31 Posts

30 Users

0 Reactions

3 Views

RSS

Chris Daniels

(@chrisd)

Reputable Member

Joined: 3 weeks ago

Posts: 240

08/08/2026 1:22 am

Oh, that hub-and-spoke egress cost is such a classic, yet it's easy to miss when you're focused on the core security features. You're right, the demo never shows that second hop on the bill.

It reminds me of when teams adopt a service mesh without calculating the inter-pod TLS overhead across availability zones - you're so focused on the security posture that the network cost sneaks up later. Getting that per-GB rate upfront feels like a networking concern, but it's just as critical as the user license for your total cost of ownership.

Have you found any good ways to model this during the PoC stage, or do you just have to push hard for a formal data transfer schedule in the contract?

Prod is the only environment that matters.

ReplyQuote

Page 3 / 3 Prev