FSLogix roaming profiles are stored on Azure Premium File shares. When the shares are provisioned, someone picks a size, usually 2TB, because it feels safe and storage is cheaper than a support incident. That decision gets made once and rarely revisited.
The problem with Premium Azure File shares is that IOPS and throughput scale with provisioned size, not actual usage. A 2TB share costs what a 2TB share costs, regardless of whether it holds 200GB of actual profile data.
What the usage actually looks like
In a recent AVD review covering multiple Premium File shares provisioned at 2TB each, actual storage utilisation was running at 25-30% of provisioned capacity. IOPS utilisation was around 10% of available headroom. Latency metrics were nominal, 2-3ms server latency, under 15ms end-to-end, with no throttling events recorded.
That utilisation profile means the shares could be reduced to 512GB-1TB without any impact on user experience or performance. The IOPS headroom at 1TB is still well above what the workload requires.
The annual saving from right-sizing those shares: £5,000.
Resizing down is quick, with one catch
Reducing a Premium Azure File share is a portal slider, or a single CLI command. The change takes about two minutes and is non-disruptive: you drop the provisioned size and the billing follows immediately. The new size only has to stay above what the share is actually using.
The one catch is the rate limit. Azure lets you change a premium file share's provisioned size only once every 24 hours. So you can't feel your way down in small steps across an afternoon. Pull the real utilisation figures first, decide the target size in one move, and apply it. Wait a day if you want to trim further.
That makes this one of the lower-risk cost changes in Azure: a two-minute resize, no new share, no migration, no GPO change, no cutover. The only discipline it needs is sizing against real data rather than guessing.
One thing to resolve before you resize
In the review that surfaced this finding, Kerberos authentication errors were present in the FSLogix Insights data. These errors, if unresolved, can cause VHD bloat, profiles growing beyond their actual data content because of incomplete write operations. Resizing down while the Kerberos issue is active risks hitting the new capacity ceiling sooner than expected, and you only get one size change every 24 hours to correct it.
The right sequence: resolve the Kerberos authentication configuration first, then size the shares against clean utilisation data.
The broader pattern
FSLogix shares get provisioned generously because the consequences of running out of profile space during a user session are immediate and visible. That caution is reasonable. The issue is that "generous" tends to mean 4-10x actual requirement, and the cost of that headroom is charged monthly regardless of whether it's used.
A 512GB Premium File share delivers enough IOPS for the vast majority of knowledge worker AVD profiles. The 2TB default is a legacy of provisioning norms that predate the cost visibility most Azure estates now have.
AVD storage configuration is part of our standard Azure cost review. If you haven't reviewed your FSLogix share sizing since initial deployment, our free Cost Review includes a full review of your virtual desktop storage estate.