Something quietly important happened to Azure Files, and I want to spend some real time on it. The way we have been sizing file shares for Azure Virtual Desktop needs to be revisited.
The change is a new storage account classification called Standard Provisioned v2. Microsoft calls the billing model provisioned v2, and on the HDD media tier it replaces the old pay-as-you-go guesswork with something we can actually plan around. Nerdio Manager for Enterprise 8.1 now supports creating these accounts, which is what prompted this post, but the Nerdio part is genuinely the small part. As usual, we just make it easy for you to work with the new feature. The concept itself of this new storage option is the part worth your time here.
Who this is for: anyone sizing Azure Files for FSLogix profile containers, App Attach packages, or general-purpose shares. If you have ever provisioned a premium share at 1 TiB purely to buy IOPS you did not need the capacity for, this one is for you.
What this covers: what provisioned v2 is, how the three provisioning dials work, the guardrail rule that surprises people, how bursting behaves, what it means for FSLogix sizing, and where to set it in Nerdio Manager.
What this does not cover: pricing in dollars. Rates vary by region and change over time, and stale numbers in a blog post help nobody. I link Microsoft’s pricing page at the end so you are always reading current figures.
Let’s build this up from the models themselves.
Three Billing Models, and Why the Third One Exists
Azure Files supports three billing models. Understanding what each one optimizes for makes the rest of this straightforward.
| Model | Media tier | How you pay | What you control |
|---|---|---|---|
| Pay-as-you-go | HDD only | Used storage + per-transaction charges | Access tier only (transaction optimized, hot, cool) |
| Provisioned v1 | SSD only | Provisioned storage; IOPS and throughput are computed from it | Storage size — performance follows in a fixed ratio |
| Provisioned v2 | SSD and HDD | Provisioned storage, IOPS, and throughput, billed independently | All three, separately |
Pay-as-you-go sounds appealing until you try to forecast it. The storage half is easy — you know roughly how much data you have. The transaction half is the problem, because transactions are generated by application behavior, not by your intentions. A single user opening a file can become many SMB transactions. Multiply that by an unpredictable user population and you get a bill you cannot model in advance, which makes budgeting genuinely difficult.
Provisioned v1 solved predictability by tying performance to capacity in a fixed ratio. That works, but it forces a compromise many of us know well: you provision storage you do not need in order to reach the IOPS you do need. Capacity becomes a proxy for performance, and you pay for the proxy.
Provisioned v2 separates the dials. You provision storage, IOPS, and throughput as three independent quantities, and you pay for what you provisioned regardless of what you use. Microsoft’s own guidance is now direct about it: use the provisioned v2 model for new Azure Files deployments.
That independence is the entire point of this post.
What “Standard Provisioned v2” Actually Means
The naming trips people up, so let’s be precise. There are two separate concepts stacked on top of each other.
Media tier is the hardware: SSD (what we used to call premium) or HDD (what we used to call standard).
Billing model is how you pay: pay-as-you-go, provisioned v1, or provisioned v2.
“Standard Provisioned v2” is the combination of the HDD media tier with the provisioned v2 billing model. In Azure Resource Manager terms, that means a storage account with:
- Kind:
FileStorage - SKU:
StandardV2_LRS,StandardV2_ZRS,StandardV2_GRS, orStandardV2_GZRS
The SSD equivalents are PremiumV2_LRS and PremiumV2_ZRS.
Two details in that SKU list deserve attention, because they are easy to miss.
First, HDD provisioned v2 supports geo-redundancy. SSD provisioned v2 does not. Look again: StandardV2 offers LRS, ZRS, GRS, and GZRS. PremiumV2 offers only LRS and ZRS. If a cross-region redundancy requirement has been keeping you off the premium tier, the HDD provisioned v2 tier is worth a serious look.
Second, HDD provisioned v2 is SMB only. NFS is not available on the HDD media tier under any billing model. For NFS you are on SSD.
NOTE: Provisioned v2 is generally available in all Azure public cloud regions and all Azure US Government cloud regions. That said, not every region supports every combination of media tier and redundancy — so confirm your specific region and redundancy pairing before you design around it.
The Three Dials
Here is the mental model I would hold on to. In provisioned v2, a file share has three independent settings, each with its own unit, its own minimum, and its own maximum.
| Dial | Unit | HDD minimum | HDD maximum |
|---|---|---|---|
| Storage | 1 GiB | 32 GiB | 256 TiB (262,144 GiB) |
| IOPS | 1 IO/sec | 500 IOPS | 50,000 IOPS |
| Throughput | 1 MiB/sec | 60 MiB/sec | 5,120 MiB/sec |
A few things follow from this table that I think are genuinely useful.
That 32 GiB minimum is remarkable. A premium provisioned v1 share starts at 100 GiB. If you have small shares — an App Attach package repository, a departmental share, a test share — provisioned v2 lets you provision honestly small.
The provisioning unit is 1 GiB, 1 IOPS, 1 MiB/sec. Not tiers, not t-shirt sizes. You set the number.
And you can change these values without downtime. Scaling up or down takes effect within a few minutes. There is one rule to remember: you can only decrease a quantity after 24 hours have elapsed since your last increase of that quantity. Plan your test-and-tune cycles around that 24-hour window, or you will find yourself waiting.
The recommendation formulas
When you create a provisioned v2 share, Azure suggests IOPS and throughput based on the storage you provisioned. These are the HDD formulas:
IOPS = MIN( MAX( 1000 + CEILING(0.2 × ProvisionedStorageGiB), 500 ), 50000 )
Throughput = MIN( MAX( 60 + CEILING(0.02 × ProvisionedStorageGiB), 60 ), 5120 )
For contrast, the SSD formulas are considerably more generous on the IOPS side:
IOPS = MIN( MAX( 3000 + CEILING(1 × ProvisionedStorageGiB), 3000 ), 102400 )
Throughput = MIN( MAX( 100 + CEILING(0.1 × ProvisionedStorageGiB), 100 ), 10340 )
These are recommendations built from typical customer usage at that capacity on that tier — not requirements. You can override them in either direction. But how far you can override them upward is the part that catches people out, and it has a name.
Guardrails: The 5× Rule
This is the concept I would most want you to walk away with, because it is where the “three independent dials” story picks up an important qualifier.
Provisioning guardrails keep IOPS and throughput roughly proportional to provisioned storage. Each dimension is capped at 5× its recommended value for the storage you provisioned. IOPS and throughput are evaluated independently against their own formulas. You can always reduce a dial down to the tier minimum; it is the ceiling that is constrained.
Work through it on the HDD tier with a 1,024 GiB share:
- Recommended IOPS = 1000 + CEILING(0.2 × 1024) = 1000 + 205 = 1,205 IOPS
- Guardrail ceiling = 5 × 1,205 = 6,025 IOPS
So a 1 TiB HDD provisioned v2 share can be pushed to just over 6,000 IOPS, and no further. Want more? You raise provisioned storage, which raises the recommendation, which raises the ceiling.
Microsoft publishes the resulting ceilings, and they are worth internalizing:
| Provisioned storage | HDD max IOPS | HDD max throughput (MiB/sec) |
|---|---|---|
| 32 GiB | 5,035 | 305 |
| 256 GiB | 5,260 | 330 |
| 1,024 GiB | 6,025 | 405 |
| 4,096 GiB | 9,100 | 710 |
| 16,384 GiB | 21,385 | 1,940 |
| 32,768 GiB | 37,770 | 3,580 |
| 65,536 GiB | 50,000 | 5,120 |
So the dials are independent, but not unboundedly independent. Think of it as three dials inside a frame, where the size of the frame is set by provisioned storage. That is a more honest picture than “provision whatever you like,” and it is the picture you need in order to size correctly.
HINT: If you inherited shares provisioned before guardrails existed and they sit above 5×, they keep working. When you change any provisioned quantity on such a share, the ratio can stay the same or come down, but it cannot go up. Once it reaches 5× or below, the normal rule applies from then on.
Bursting, and What Credits Really Buy You
Credit-based IOPS bursting gives you headroom above your provisioned IOPS, on a best-effort basis, for as long as you have credits. On the HDD tier:
Burst IOPS limit = MIN( MAX( 3 × ProvisionedIOPS, 5000 ), 50000 )
Burst IOPS credits = ( BurstLimit − ProvisionedIOPS ) × 3600
The behavior is simple and worth stating plainly. Credits accrue whenever the share runs below its provisioned IOPS. When the share exceeds provisioned IOPS and credits are available, it bursts — up to the burst limit — and each IO above the provisioned rate spends one credit. When credits run out, the share drops back to its provisioned IOPS. A brand-new share starts with a full credit bucket, which is a nice touch during a migration.
One subtlety that matters during an incident: credits do not accrue while the server is throttling you. If you are already underwater, you are not quietly refilling the tank.
Some worked HDD examples:
| Provisioned IOPS | Burst limit | Burst credits |
|---|---|---|
| 500 | 5,000 | 16,200,000 |
| 1,000 | 5,000 | 14,400,000 |
| 5,000 | 15,000 | 36,000,000 |
| 25,000 | 50,000 | 90,000,000 |
| 50,000 | 50,000 | 0 |
Notice the last row. Provision the HDD maximum and there is no burst headroom left, because the burst ceiling and the tier ceiling are the same number.
Here is how I would frame bursting for a design review. Bursting is insurance against the spike you did not predict. It is not a substitute for provisioning to your known peaks. If your IO pattern is established — and FSLogix login storms are about as established as patterns get — provision for the peak and let credits cover the genuine surprises.
What You Are Billed For
Provisioned v2 bills against five meters, and the system emits consumption hourly:
- Provisioned Storage, in GiB
- Provisioned IOPS, in IO/sec
- Provisioned Throughput MiBPS, in MiB/sec
- Overflow Snapshot Usage, in GiB
- Soft-Deleted Usage, in GiB
The first three are simply your three dials. The last two deserve a moment each, because they are where an unexpected line item tends to come from.
Snapshots are differential, both from the live share and from each other. Under provisioned v2, if the total differential size of all your snapshots fits inside the unused portion of your provisioned storage, snapshot storage costs you nothing extra. Only the excess is billed:
Overflow = MAX( (LiveShareUsedGiB + SnapshotDifferentialUsedGiB) − ProvisionedStorageGiB, 0 )
That formula is quietly generous, and it argues for leaving deliberate headroom in provisioned storage rather than running the share tight. Headroom you provisioned is headroom your snapshots can live in for free.
Soft delete behaves sensibly. During the retention period, a deleted share is billed on its used capacity, not its provisioned capacity. Its provisioned storage, IOPS, and throughput still count against the storage account’s limits until it is purged — so the resources are reserved for a clean restore — but you are not billed for them.
The Storage Account Trap
If you take one planning lesson from this post, make it this one.
Classic file shares created in the same storage account share that account’s limits. On the HDD tier:
| Attribute | HDD limit per storage account |
|---|---|
| Maximum provisioned storage | 4 PiB (4,194,304 GiB) |
| Maximum provisioned IOPS | 50,000 IOPS |
| Maximum provisioned throughput | 5,120 MiB/sec |
| Maximum number of classic file shares | 50 |
Look at the IOPS row against the per-share maximum from earlier. They are the same number: 50,000. Which means a single share can consume the entire account’s IOPS budget.
Pack several busy FSLogix shares into one storage account and you can hit the account IOPS ceiling while every individual share still looks like it has room. Worse, these limits are enforced at provision time — so the failure mode is not a slow share, it is an existing share that cannot grow until you migrate it to a different storage account. That is a painful discovery to make during a capacity crunch.
Microsoft’s guidance is to plan enough headroom in each storage account to keep your share-to-account mapping viable for three to five years. I would go further and add a second reason to spread shares across accounts: billing granularity. The lowest granularity Azure exposes for billing is the resource, so two shares in one storage account cannot be cleanly charged back to two different departments. If cost attribution matters to you, let it shape your account layout from the beginning.
NOTE: There is a newer model that sidesteps all of this. The
Microsoft.FileSharesresource provider makes a file share a top-level Azure resource with its own performance, networking, and billing — no storage account required, and a much higher per-subscription limit. It went generally available in 2026, but at the time of writing it supports NFS 4.1 on SSD only. Not an FSLogix answer today. Worth watching.
Sizing an FSLogix Share: A Worked Example
Now let’s make all of this concrete, because this is where the theory pays off.
Microsoft publishes FSLogix IOPS guidance per user, and it is refreshingly simple:
| Resource | Requirement per user |
|---|---|
| Steady state IOPS | 10 |
| Sign in / sign out IOPS | 50 |
Take 500 concurrent users with an average profile of about 5 GiB.
Capacity: 500 × 5 GiB = 2,500 GiB. Add headroom for growth and for snapshots to live in — let’s provision 3,000 GiB.
Steady state IOPS: 500 × 10 = 5,000 IOPS.
Login storm IOPS: 500 × 50 = 25,000 IOPS, if every user signed in at the same instant. In practice sign-ins stagger across a morning window, so treat this as the theoretical ceiling rather than a target.
Now check that against the HDD guardrail at 3,000 GiB provisioned storage:
- Recommended IOPS = 1000 + CEILING(0.2 × 3000) = 1000 + 600 = 1,600 IOPS
- Guardrail ceiling = 5 × 1,600 = 8,000 IOPS
So we can provision up to 8,000 IOPS on that share. Our 5,000 steady-state requirement fits comfortably. Provision 5,000 IOPS and bursting gives us MIN(MAX(3 × 5,000, 5,000), 50,000) = 15,000 IOPS of burst ceiling with 36 million credits — which is real protection through a staggered morning ramp.
But notice what we cannot do. To provision the full 25,000 IOPS on the HDD tier, we would need the recommendation to reach 5,000, which means:
1000 + 0.2 × GiB ≥ 5000 → GiB ≥ 20,000
Twenty TiB of provisioned storage to unlock 25,000 IOPS — for 2.5 TiB of actual profile data. That is exactly the “buy capacity to buy performance” compromise provisioned v2 was meant to escape, and on the HDD tier it has not entirely gone away. It has only loosened, by a factor of five.
Run the same numbers on SSD provisioned v2 at 3,000 GiB:
- Recommended IOPS = 3000 + 3000 = 6,000 IOPS
- Guardrail ceiling = 5 × 6,000 = 30,000 IOPS
The SSD tier absorbs the full theoretical login storm at the same capacity.
So what is the honest recommendation? It depends on the shape of your workload, and I mean that genuinely rather than as a hedge:
- HDD provisioned v2 fits capacity-heavy, moderate-IOPS shares — large profile estates with staggered sign-ins, App Attach repositories, departmental and archival shares, and anywhere a geo-redundancy requirement rules out the premium tier.
- SSD provisioned v2 still fits latency-sensitive, spike-heavy shares — dense multi-session pools, shift-change environments where hundreds of people sign in within minutes, and anything where a throttled profile load becomes a support ticket.
One more ceiling to keep in view, independent of billing model. Azure Files allows 10,000 open root directory handles per share, which effectively caps a share at roughly 10,000 active FSLogix users. Long before you reach that, the storage account IOPS limit will have made the decision for you — but it is a real boundary and worth knowing.
Migration: There Is No In-Place Conversion
I want to be direct about this, because it is the most common surprise.
You cannot convert an existing pay-as-you-go storage account to Standard Provisioned v2. The classification is a property of the account — kind FileStorage, SKU StandardV2_* — set at creation. Moving to provisioned v2 means creating a new storage account and copying your data.
Microsoft documents two paths depending on your setup: a share-to-share file migration if you are running Azure Files on its own, and a different share-to-share procedure if Azure File Sync is in the picture. Both are linked at the end.
For FSLogix specifically, that means a maintenance window and a plan for profile cutover, not a checkbox. The good news is that a brand-new provisioned v2 share starts with a full burst credit bucket — so the copy itself has headroom to work with.
Setting This Up in Nerdio Manager for Enterprise 8.1
Here is the short section I promised, and it is short because Nerdio Manager makes it short.
Version 8.1 added support for creating Azure Files v2 storage accounts — which had been an active customer feature request in the Nerdio community forums for some time. The workflow lives where it always has:
- Navigate to Cloud Desktops > Storage > Azure Files.
- Select Add Azure Files.
- Set the Performance and Replication values for the account you want, then the File Share Name and Provisioned Capacity (GiB).
- Work through the Storage account configuration section — Share-level permissions, Join to AD or Entra ID, and Enable SMB Multichannel.
- In File share configuration, set your Permissions (SMB Share Contributors), and select FSLogix to grant Authenticated Users Modify permission on the share root so profile folders can be created. For an App Attach share, choose App Attach instead.
- Optionally Apply tags, then select OK.
Nerdio Manager handles the parts that are genuinely tedious by hand — the AD or Entra ID join, the temporary VM it needs to do that join, AES-256 encryption, the RBAC role assignments, and the NTFS file-level permissions if you ask it to.
While you are in 8.1, the new Azure Files > User Profiles tab is the companion feature worth turning to. It lists every FSLogix profile with its assigned user, file name, file share, last logon time, size, quota, usage, and health — including users who have profiles scattered across multiple shares. Sizing a share is much easier when you can see what the profiles are actually doing.
The one caveat, and why it makes sense
Nerdio’s release notes are clear that auto-scale support for Azure Files v2 is coming in a future release. Creation is supported in 8.1; auto-scale is not yet.
I think the reason is worth understanding rather than just noting, and this next part is my read rather than a Nerdio statement.
Nerdio Manager’s Azure Files auto-scale has always been a premium-tier feature, and its own documentation explains why: auto-scale is unavailable for standard storage “because both capacity cost and performance are not controlled by the size of the share.” Under provisioned v1, growing the share was how you bought IOPS, so a single lever moved both capacity and performance. Auto-scale watched share latency and pulled that one lever.
Provisioned v2 breaks that one-to-one relationship on purpose. Storage, IOPS, and throughput are now three separate dials — which is the whole benefit, and also precisely why the old single-lever logic does not transfer. Auto-scaling provisioned v2 properly means scaling three quantities independently, respecting the 5× guardrail on two of them, and honoring the 24-hour decrease rule on each. That is a new engine, not a configuration change.
So in the meantime, size provisioned v2 shares deliberately and revisit them on a schedule. Given that the User Profiles tab now shows you real profile sizes and usage, you have better inputs for that review than you have ever had.
What I Would Do Monday Morning
If I were sitting down with a fresh Azure Files design today, this is the order I would work in.
- Count concurrent users and multiply. Ten IOPS each for steady state, fifty for sign-in. That gives you your two numbers.
- Size capacity from real profile data, not from a guess. If you are on 8.1, the User Profiles tab has the numbers.
- Check the guardrail before committing. Run the recommendation formula on your intended capacity, multiply by five, and confirm your IOPS requirement fits underneath. If it does not, you are either provisioning more storage or moving to SSD — better to learn that now than after the migration.
- Leave headroom in provisioned storage so differential snapshots have somewhere free to live.
- Spread shares across storage accounts with three to five years of growth in mind, and with billing attribution in mind too.
- Then build it in Nerdio Manager, and let it handle the domain join and permissions.
The thread running through all of it is that provisioned v2 asks you to state your intentions. Pay-as-you-go let you avoid the question and sent you a bill that reflected your avoidance. Provisioned v1 let you answer with a single number and quietly overcharged you for the translation. Provisioned v2 wants three answers, and gives you predictable pricing in return.
That is a better trade than it first appears. Naming your requirements out loud is how capacity planning was always supposed to work — and it is remarkable how much clearer an environment becomes once someone finally writes the numbers down.
Sources and further reading
- Understand Azure Files billing — the authoritative reference for all three billing models, the formulas, and the guardrails
- Azure Files scalability and performance targets
- What’s new in Azure Files
- Azure Files pricing — always check current rates here
- FSLogix container storage options — the source of the per-user IOPS guidance
- Migrate files from one SMB Azure file share to another
- Nerdio Manager: Create and manage configured Azure Files shares
- Nerdio Manager for Enterprise release notes
If you have moved an FSLogix estate onto Standard Provisioned v2, I would genuinely like to know what IOPS number you landed on and how close the recommendation came to your real requirement. That is the kind of field data the documentation cannot give us.