NetScaler bandwidth based licensing decoded comes down to one idea that the datasheets bury: you are paying for throughput, and throughput is the easiest thing in the estate to over buy. NetScaler, the application delivery and load balancing product now owned by Cloud Software Group, can be licensed in several ways, and the bandwidth model prices capacity by the megabit or gigabit per second rather than by instance or CPU. That sounds simple, but the tier structure, the bursting rules, and the choice between fixed and pooled capacity create a set of traps that quietly inflate cost. As of 2026, with renewal increases of 50% to 200% widely reported across the Citrix range, an over sized bandwidth tier is an overpayment that compounds at every renewal. This guide decodes how the model works and where buyers lose money.
What NetScaler bandwidth based licensing means
NetScaler bandwidth based licensing decoded starts with the unit of measure. Instead of counting instances or CPU cores, the model licenses a throughput ceiling, expressed in megabits or gigabits per second. You buy a capacity tier, and each licensed appliance or virtual instance may pass traffic up to that limit. Exceed it and traffic is shaped or dropped depending on configuration, which is why buyers instinctively size high. That instinct is exactly where the cost problem begins, because throughput is bought against fear of the peak rather than knowledge of the typical.
The bandwidth model is one of several. NetScaler is also offered on a per vCPU basis and through pooled capacity, and the three behave very differently on cost. Our companion guide to NetScaler vCPU licensing covers the instance based alternative, and the choice between them is not academic. Picking the wrong model for your traffic profile can cost more than any discount you negotiate on the model you picked.
How throughput tiers drive cost
The defining feature of bandwidth licensing is that price moves in steps, not a smooth line. Capacity is sold in tiers, and the jump from one tier to the next can be a large increment in both throughput and price. The danger is buying just above a tier boundary. An estate that needs slightly more than a tier allows is pushed into the next band and pays for a block of capacity it will never use. Sizing to the rare peak rather than the typical load locks that premium in for the life of the contract, and because the tier carries forward at renewal, the overpayment renews with it.
Controlling tier cost is a measurement problem before it is a negotiation problem. A buyer who knows real throughput, the typical load and the genuine peaks, can size to the tier that actually fits rather than the tier that feels safe. Where traffic genuinely spikes, the question becomes whether the spike justifies a permanent higher tier or whether bursting and pooling handle it more cheaply. Without measured data, every one of those decisions defaults to the expensive answer.
Bandwidth price moves in steps, not a line. Buying just above a tier boundary, or sizing to a rare peak, locks in a premium that renews every cycle.
Bursting and the peak problem
Most NetScaler traffic is not flat. It has quiet periods and busy periods, and the gap between average and peak is often large. Buyers who size their bandwidth tier to the absolute peak pay for that peak capacity continuously, even though they use it for a small fraction of the time. The question worth asking is what actually happens at the peak and how often it occurs. If peaks are rare and brief, a lower base tier combined with a strategy for handling occasional spikes is usually far cheaper than a permanently higher tier sized to a moment that happens twice a year.
This is where the architecture of the estate matters. A single instance carrying all the traffic has to be sized to its own peak. An estate where capacity can be shared across instances does not, because one instance's peak rarely coincides with another's. That observation is the entire argument for pooled capacity, and it is why the fixed bandwidth tier, simple as it looks, is frequently the most expensive way to license a distributed NetScaler deployment.
Bandwidth versus pooled capacity
Pooled capacity changes the economics by letting total licensed bandwidth be shared across the estate rather than provisioned in full at every instance. Under a fixed bandwidth tier, ten instances each need enough capacity for their own peak, and most of that capacity sits idle most of the time. Under pooling, the estate draws from a shared pool, so total licensed bandwidth tracks total demand rather than the sum of individual peaks. For any estate with multiple instances and uneven demand, pooling usually wins, often by a wide margin. Our NetScaler pooled capacity licensing guide works through how the pool is sized and managed.
The model is not universally cheaper. A single site with steady, predictable throughput may be perfectly well served by a fixed tier, and pooling adds management overhead that only pays off at scale. The point is that the choice should be made by modelling both options against measured traffic across the whole estate, not by accepting whichever model the previous purchase happened to use. Carrying a model forward unexamined is how an estate ends up paying fixed tier prices for traffic that pooling would cover for less.
Where buyers overpay, and how to stop
The overpayments cluster in three places. Sizing to peak instead of typical throughput buys capacity that sits idle. Provisioning full capacity at every instance instead of pooling multiplies that idle capacity across the estate. And carrying tiers forward at renewal without remeasuring traffic renews every prior over sizing decision automatically. As of 2026, with Cloud Software Group repricing renewals aggressively, that last one is the most expensive, because the vendor applies the increase to an inflated baseline the buyer never needed to be on.
The defence is unglamorous and effective: remeasure throughput before every renewal, model fixed against pooled options on real data, and size to the tier that fits typical load with deliberate, justified headroom. A NetScaler renewal handled this way often comes down rather than up, even in a repricing environment. The full picture of NetScaler licensing sits in our NetScaler licensing pillar, and the renewal mechanics specific to the current owner appear in our guide to NetScaler renewal negotiation under Cloud Software Group. Decoding the licensing is the first step. Acting on the measurement is what saves the money.
Frequently asked questions
What is NetScaler bandwidth based licensing?
NetScaler bandwidth based licensing prices the product on throughput, measured in megabits or gigabits per second, rather than on the number of instances or CPUs. You license a capacity tier, and the appliance or virtual instance is allowed to pass traffic up to that limit. As of 2026 this model sits alongside vCPU based and pooled capacity options, and the right choice depends on how predictable and how distributed your traffic is across the estate.
How do NetScaler bandwidth tiers affect cost?
NetScaler bandwidth tiers affect cost because price steps up at defined throughput bands rather than rising smoothly. Buying just above a tier boundary can cost far more than the extra capacity is worth, and sizing to peak rather than typical throughput locks in that premium permanently. Buyers control cost by sizing to real measured throughput, leaving headroom only where traffic genuinely needs it, and checking whether a pooled model would serve variable demand more cheaply than a fixed tier.
Is bandwidth or pooled capacity licensing cheaper for NetScaler?
Whether bandwidth or pooled capacity licensing is cheaper depends on how your traffic is distributed. A single site with steady, predictable throughput is often well served by a fixed bandwidth tier. An estate with many instances and uneven or shifting demand usually pays less under pooled capacity, because pooling lets total licensed bandwidth be shared rather than over provisioned at every instance. The only reliable way to decide is to model both against measured traffic across the whole estate.
Where do buyers overpay on NetScaler bandwidth licensing?
Buyers overpay on NetScaler bandwidth licensing by sizing to peak instead of typical throughput, by provisioning full capacity at every instance instead of pooling, and by carrying tiers forward at renewal without remeasuring actual traffic. As of 2026, with Cloud Software Group repricing renewals aggressively, carrying an over sized tier into a renewal compounds the overpayment. Remeasuring throughput before each renewal is the simplest way to stop paying for capacity you do not use.
For related guidance, see our coverage of NetScaler vCPU licensing, the NetScaler pooled capacity licensing guide, and the NetScaler licensing pillar.