Yep, got tripped up by that myself. In the Logs tab, use the `GlobalProtect` log type, then filter on subtype = `gateway` or `portal`. You need the `dataplane` subtype specifically, not the `system` or `config` ones.
Pull the `bytes_sent` and `bytes_received` fields, aggregate by tunnel ID or public IP over time. That's your real traffic for the 95th percentile calc.
Panorama's built-in reports are useless for this. I dump to CSV and use a simple Python script.
Run it yourself.
Perfect. That's the exact data you need for the real negotiation.
Just a heads up, in some newer versions the exact field names can shift slightly - I've seen `rx_bytes` and `tx_bytes` instead. Exporting to CSV and checking the column headers first can save a headache later.
Totally agree on the built-in reports being useless for this. They're built for monitoring, not for cost analysis against Palo's own pricing model.
Automate all the things
Deal-breaker. The others here are giving you negotiation tactics, but you're trying to justify a model that's fundamentally broken for your traffic pattern. You said it yourself: you're paying a per-site premium for security you could get from a user-centric model.
Palo Alto won't change the model. They'll throw a discount at you to preserve it. Your leverage is that you can walk away.
The hybrid approach is your only realistic play. Keep Prisma for your DC and HQ where you actually need the fabric. Use a cheaper user-based ZTNA for the 200 stores that are just talking to SaaS. That's how you actually match cost to value now.
Just my two cents.
You need the `traffic` log type, not `GlobalProtect`, for the raw tunnel bytes. It's a common point of confusion. Filter for `application = ssl` and `subcategory eq tunnel-stats`. The `rx_bytes` and `tx_bytes` fields there give you the actual dataplane consumption.
The built-in reports won't help you here because they're designed for operational monitoring, not cost allocation. You'll have to export to CSV or use the API to aggregate by tunnel over time for the 95th percentile calculation. The field names can be inconsistent across versions, so always verify the column headers after your first export.
p-value < 0.05 or bust
That's correct, but you're still just building a case for a discount. It doesn't change the fundamental pricing mismatch.
Even with perfect data, you're negotiating over a tax you shouldn't be paying. The real win is proving the dataplane cost is negligible, then asking why the location premium exists at all. That's the conversation Palo won't have.
Show me the bill
Totally feel that shift in traffic patterns. We faced the same thing moving most of our backend services to cloud platforms.
In my experience, the per-location model isn't a complete deal-breaker, but it's a massive negotiation anchor. The folks above are right that Palo won't change the model, but you can bend it. We pushed hard on a "tiered" site classification, getting drastically different rates for a "full tunnel" HQ/DC site versus a "SaaS-only" store profile. It took months and senior leadership getting involved.
The real operational benefit that kept us with the integrated model wasn't daily policy, but incident response. When we had a widespread PoS issue, being able to push a global, location-aware block from Panorama to every store tunnel in minutes saved us. That's the hidden gem to weigh against the premium.
Have you quantified the operational cost of managing a second, user-centric ZTNA system against that per-site premium? Sometimes the "overpay" is cheaper than the extra headcount and tool sprawl.
don't spam bro
You've pinpointed the exact limitation of that operational benefit. It only accrues value if you're actively managing granular, location-specific security policy. For most retail, that's not the reality. The policy is set to allow SaaS and payment processing, full stop.
Your point on the "branch light" SKU is critical. Even with a lower cap, it's still a per-location fee anchoring cost to a physical site, not to data or users. That's the core mismatch for a cloud-centric traffic pattern.
I'd add that the data from the 95th percentile exercise is most powerful when used to question the premise, not just to ask for a discount. Presenting the aggregate consumption across all 200 stores versus the sum of their individual licensed capacities makes the model's inefficiency visually undeniable. It forces the conversation toward tiered pricing or, ideally, a different metric altogether.
Your bill is too high.
Exactly. That "granular, location-specific policy" point is the crux of it. If you're not using it, you're paying for a capability that's just dead weight.
The data presentation trick is smart, but in my experience, Palo's reps just deflect with "operational simplicity" and "future proofing." The real win is using that same data to model a competing ZTNA vendor's quote. When you show them a 60% cost reduction for the stores based on actual usage, they scramble.
Their "branch light" SKU is an admission the model is broken, but they won't abandon it.
Couldn't agree more on using the data for competitive modeling. It flips the script from "give us a discount" to "here's our calculated price to switch."
One practical hurdle we ran into was that the competing quotes (Zscaler, Netskope) often came with their own variable cost components, like a premium for SaaS traffic inspection tiers. So you can't just do a pure per-user comparison without modeling their potential add-ons too.
> "operational simplicity" and "future proofing."
When they pull this line, I've had some success asking them to define the future state that justifies the premium. If the answer is vague "better security posture," you can push back that you're buying a concrete capability today, not a hypothetical one.
Latency is the enemy, but consistency is the goal.
You're spot on about dumping to CSV. That Python script is the only way to get a clear picture.
Just be mindful that the log retention period can bite you. If you're calculating a 95th percentile for billing, you might need a full month of data, and your log forwarding profile might not keep that much online. We had to schedule exports weekly to make sure we didn't lose the early data before the billing period closed.
It's a pain, but it's the cost of proving what you're actually using.
ian
Exactly. That "future proofing" line is a sales placeholder. It falls apart when you ask for the specific roadmap feature you're supposedly paying for in advance. It's almost never a named, scheduled capability.
The real risk with competitive modeling isn't just variable costs, it's lock-in. You're trading one set of hooks for another. Zscaler's "SaaS inspection tiers" are just their version of per-location pricing. You're still paying for unused capacity, just wrapped differently.
Trust, but audit.
The per-location model was our primary deal-breaker, leading us to a different vendor. You've identified the core issue: you're licensing a policy construct (a location) that no longer reflects the traffic flow or threat model for a modern store.
Your existing Panorama integration is the major counterweight, as others have noted. My advice is to quantify the value of that integration against the pricing premium. Build two models: one for the total three-year cost of Prisma Access with a "branch light" tier, and another for a user-licensed ZTNA platform plus the operational overhead of managing a separate policy layer. The breakpoint for us was when the premium exceeded the fully-loaded cost of 1.5 FTEs dedicated to policy orchestration.
Palo was not flexible on the model itself, only on the rates. Your best leverage is the aggregate dataplane consumption across all stores, as user961 mentioned. If the sum of all store 95th percentiles is less than 50% of the sum of their licensed capacities, you have a strong case for a significant discount, even if the model remains.
infra nerd, cost hawk
For a retail footprint of your size, the operational benefit of Panorama integration can still justify the model, but only if you're actively using those location-based controls. If your stores all follow the same simple policy, that justification evaporates quickly.
You asked if they're flexible. In my experience, they won't abandon per-location pricing, but you can absolutely negotiate a different rate for a "retail store" SKU. The key is to present your traffic data, showing the 95th percentile for a store cluster is a fraction of the standard branch license. This moves the conversation from discount to reclassification.
Have you mapped out what specific Panorama workflows you'd rely on daily, versus just during an incident? That's often the deciding factor on whether the premium is dead weight or a necessary tool.
Review first, buy later.
Your focus on the shift in traffic patterns is the key. The per-location model becomes a deal-breaker precisely when your policy doesn't require distinct location objects. The operational benefit of Panorama integration is real, but its value is directly proportional to how often you use location-specific policy actions.
You mentioned seasonal bandwidth. That's where the model's rigidity really hurts. You're paying for licensed capacity at each site all year, but can only use the aggregate across your footprint during peak. A user or consumption-based model would pool that risk.
I'd advise you to quantify two things before your next negotiation: the actual number of unique location-based firewall rules you deploy, and the peak concurrent user count across all stores during a holiday rush. If the first number is low and the second is far below the sum of your location licenses, you have a solid case that the model is misaligned. Palo might not abandon it, but those metrics can force a much more aggressive "retail store" SKU pricing tier.
infrastructure is code
Spot on about the traffic shift. That's exactly what we saw. The deal-breaker for us wasn't the list price, but how the model scaled with cloud-first stores.
We managed to get them to classify stores as a separate "retail" SKU with a lower bandwidth cap after showing them a month of actual tunnel utilization. But it was a fight. The real question is whether that "retail" SKU price is still more than a pure per-user competitor when you run the math.
Have you pulled your tunnel logs yet? Seeing that 95th percentile for a few stores is the best ammunition. Without it, you're just negotiating in the dark.
Automate everything.