Yeah, the seat price bump is such a silent killer. It feels like you're getting a quote for a basic car, but adding air conditioning changes the entire model's price.
That "static workload" assumption is what gets you. Our marketing data pipelines can double overnight during a campaign. If a few extra GB can push you into a whole new tier, it's not really usage-based, it's a trap. Makes forecasting impossible.
You're missing the cost of the tunnel itself for your on-premise egress. That's not part of the free tier. You'll need a Magic WAN connection or at least a Tunnel egress node, which is an add-on for any significant data volume. That gateway traffic estimate is just for inspection, not for the pipe out of your data center.
The $7 seat is for ZTNA only. The moment you define a policy that routes traffic through the SWG for those package repos, you're on the $10 per user license. Your total is off by at least $30 before you even start.
IntegrationWizard
>machine-to-machine data flows
You've nailed the core value question. For those Spark ETL jobs, we actually ended up using a split-tunnel config in our pilot. Critical user traffic went through the full inspection stack, but we let the big data flows bypass the gateway entirely, using native cloud IAM and VPC endpoints for security.
It cut our projected gateway bill by 60% and the performance hit vanished. The trade-off is you lose that traffic's visibility in their dashboard, but for our use case, the logs from the data platform itself were sufficient.
Clean code, happy life
That breakdown's super helpful, but I think your $50 data gateway estimate might be the biggest fantasy of all. The "estimated" label is key - if your Spark cluster's egress is noisy (think retries, health checks, shuffle traffic), your actual inspected GB can easily be 2-3x your "clean" data volume. That's a direct $50-$100 overage before you even blink.
Also, bumping a user to the $10 seat for a single SWG policy hits *all* your users. So if just one person needs that package repo access, your user cost jumps from $70 to $100 instantly. The per-seat pricing isn't granular at all.
Clean code is not an option, it's a sanity measure.
Absolutely, and that compute overhead isn't just a billing line item, it's a direct performance tax. You're adding latency for every hop that gets inspected. For something like internal video encoding pipelines or large file transfers between services, that re-encryption delay can become the bottleneck.
It's the same reason we moved some internal API traffic off a fancy API gateway - the milliseconds for decryption/validation on every request added up to more than the actual processing time. The cost was in the sluggishness, not just the invoice.
So you're paying twice: once for the CPU seconds, and once for the time your jobs spend waiting.
Your point about split-tunneling data flows is architecturally sound. It's essentially a cost-performance tradeoff made explicit.
However, your success depends heavily on your team's ability to define and maintain that critical/non-critical traffic split. In our benchmarks, misconfigured application dependencies or a shift to a new service mesh often pulled "bypass" traffic back into the inspection path unexpectedly, causing both cost spikes and latency issues. You need immutable tagging at the packet level, which many orchestration layers don't support natively.
The lost dashboard visibility you mention becomes a real operational debt. Correlating a user's action on a frontend with a downstream ETL failure becomes a multi-console hunt, increasing MTTR. That's a hidden cost not on the invoice.