Premium Azure Files Sizing for FSLogix: Capacity, IOPS and Throughput

By David, 2026-11-09, updated 2026-11-09

Size a Premium (SSD) Azure Files share for FSLogix on three numbers: capacity for every named user's profile, IOPS for the users signed in at your busiest moment, and throughput. Microsoft's FSLogix guidance is about 10 IOPS per user in steady state and 50 per user during sign-in and sign-out, and its AVD sizing guidance plans 30 GB of profile storage per user. On the provisioned v2 billing model, which Microsoft recommends for new shares, you set storage, IOPS and throughput separately; on provisioned v1, IOPS and throughput come from capacity.

The short version: provision capacity for named users × 30 GB (or your measured average plus 30% headroom), check that the share's IOPS cover 50 × the users who sign in together at peak, and use provisioned v2 so you can raise IOPS without buying capacity you don't need. Keep the storage account in the same region as the session hosts, watch free space, and split very large estates across several shares.

Microsoft figures reflect Microsoft Learn as of November 2026, with links at the end. We don't quote Azure Files prices, which vary by region and redundancy: price your configuration on the Azure Files pricing page.

This post expands the storage step of our Azure Virtual Desktop sizing guide, which also compares Azure Files with Azure NetApp Files.

Premium or standard Azure Files for FSLogix?

Microsoft recommends Azure Files for FSLogix profile containers for most customers, and picks the tier by workload (Storage options for FSLogix profile containers):

Most Microsoft 365 users are medium or heavy by Microsoft's definitions (see AVD users per vCPU), so most production pools land on Premium. Standard shares are billed on usage and transactions, and a pay-as-you-go standard storage account defaults to 20,000 IOPS for everything in it, which a large sign-in storm can hit.

Step 1: Capacity

Plan per named user, not per concurrent user. Every user's profile container exists whether or not they're signed in.

• The planning figure is 30 GB per user. Microsoft's AVD sizing guidance gives 30 GB as the minimum profile storage for every workload type, and FSLogix's SizeInMBs setting defaults to 30,000 MB, the maximum each container can grow to.
• Containers are dynamic. A new VHDX starts small and grows as the profile fills, so actual use is usually well below the maximum. Once you've run for a few weeks, size from the measured total plus about 30% headroom instead of the theoretical maximum.
• SizeInMBs only goes up. You can raise it at any time and existing containers grow at next sign-in, but lowering it doesn't shrink existing containers. Set it deliberately.
• Add the extras. Separate Office (ODFC) containers, snapshots and growth all need room. On provisioned v2, snapshots are free as long as they fit in the share's unused provisioned space.

The cost of getting capacity wrong isn't symmetrical. Too much costs money every month on a provisioned share. Too little fails sign-ins when the share fills, and FSLogix doesn't degrade gracefully: users get temporary profiles or can't sign in. Our FSLogix troubleshooting guide covers what that looks like.

Step 2: IOPS

Microsoft's FSLogix storage guidance gives a per-user example:

Steady state scales with concurrent users. The sign-in figure scales with the users who sign in at the same time: if your whole pool signs in between 8:50 and 9:05, plan as if every concurrent user hits the share at once. That figure, not steady state, decides whether a share is big enough.

Step 3: How Premium Azure Files gives you IOPS and throughput

Azure Files has three billing models. Microsoft recommends provisioned v2 for all new deployments (Understand Azure Files billing).

Provisioned v2 (recommended)

You provision storage, IOPS and throughput separately and pay for what you provision. If you don't override them, Azure recommends IOPS and throughput from the storage you provision. For SSD (Premium) shares:

You can provision up to 5 × the recommended IOPS and throughput for a given capacity, and you can lower a provisioned quantity only 24 hours after you last raised it.

Provisioned v1 (existing shares)

IOPS and throughput are fixed by capacity: baseline IOPS are 3,000 + 1 per GiB, bursting to 3 × provisioned GiB (at least 10,000), and throughput is 100 MiB/s + 0.1 per GiB. The minimum share is 100 GiB. The only way to get more IOPS is to buy more capacity, which is the main reason to choose v2 for a new FSLogix share.

Step 4: Put the numbers together

Here's what Azure recommends for Premium provisioned v2 at 30 GB per named user, against Microsoft's FSLogix IOPS figures, assuming 85% of named users are signed in at peak and all of them sign in together:

What the table tells you:

• At 30 GB per user, capacity buys plenty of steady-state IOPS. One IOPS per GiB is 30 IOPS per user, three times Microsoft's steady-state figure.
• Sign-in storms are covered by bursting, not baseline, as pools grow. From a few hundred users up, the worst-case storm exceeds the recommended baseline. The burst limit (3 × provisioned IOPS) covers it while burst credits last, and a share that idles overnight starts the day with credits. If your monitoring shows the share throttling at 9 a.m., raise provisioned IOPS: on v2 you can do that without adding capacity.
• Measured capacity changes the picture. If your profiles average 12 GB and you provision 3,120 GiB for 200 users (12 GB × 1.3), the recommended IOPS drop to 6,120, below the 8,500 sign-in peak. Bursting still covers it on most days, but this is where provisioning IOPS above the recommendation is worth its cost.
• Very large estates need more than one share. A storage account holds at most 102,400 IOPS on Premium, shared by every share in it. For thousands of users, split profiles across several shares in several storage accounts, for example one per host pool, so one storm can't starve another pool.

Step 5: Placement, identity and monitoring

• Same region as the session hosts. Every sign-in and every profile read crosses the network, so keep the storage account in the region where the hosts run. See where Azure regions are located.
• Use a private endpoint so profile traffic stays on your virtual network.
• Pick the identity source and platform first. Entra ID-joined hosts need Microsoft Entra Kerberos on the storage account; see FSLogix on Entra ID-joined session hosts. If you're still choosing between Azure Files, Azure NetApp Files and Cloud Cache, see choosing FSLogix storage.
• Check your Kerberos encryption. Microsoft warns that the April 2026 Windows Server update changes the default Kerberos encryption type from RC4 to AES-SHA1, and FSLogix shares that haven't been upgraded to AES-SHA1 can have access problems after it.
• Watch capacity and throttling. In Azure Monitor, the share's capacity metric shows used space, and the Transactions metric, split by response type, shows requests throttled for exceeding the share's IOPS. Throttling at sign-in time is the signal to provision more IOPS. Slow sign-ins with healthy storage metrics point elsewhere: why AVD logons are slow covers the other causes.

Atlas AVD watches the capacity side for you. The FSLogix Capacity Monitor checks every profile share your host pools use every 15 minutes, alerts at 85% full and again at 95% by default, and keeps a month of history so Atlas Advisor can recommend a new size before a share runs out. Optional auto-expand grows an Azure Files share's quota by a set percentage (10% by default) when it crosses the trigger threshold. It's off by default, and Azure NetApp Files and other SMB shares get the warnings but aren't expanded automatically.

A worked example: 200 users

The sizing guide's example pool has 200 named users (finance and operations, Outlook, Teams, Excel and a browser) with 170 concurrent at peak.

1. Tier. Medium to heavy users: Premium Azure Files, provisioned v2, zone-redundant if the region supports it.
2. Capacity. 200 × 30 GB = 6,000 GiB to start. Re-measure after a month and adjust.
3. IOPS. Azure recommends 3,000 + 6,000 = 9,000 IOPS. Steady state needs about 1,700 and a full sign-in storm about 8,500, so the recommendation covers both before bursting.
4. Throughput. Azure recommends 100 + 600 = 700 MiB/s, plenty for 170 profiles.
5. Placement. One storage account in the same region as the hosts, with a private endpoint and AES Kerberos.
6. Cost. Price 6,000 GiB, 9,000 IOPS and 700 MiB/s on the Azure Files pricing page for your region, then add compute from the AVD cost calculator for the full monthly estimate.

FAQ

How big should an Azure Files share for FSLogix be?

Plan 30 GB per named user to start: Microsoft's AVD sizing guidance uses it as the per-user minimum, and FSLogix containers default to a 30,000 MB maximum. After a few weeks, size from the measured total plus about 30% headroom.

How many IOPS does FSLogix need per user?

Microsoft's FSLogix guidance gives about 10 IOPS per user in steady state and 50 per user during sign-in and sign-out. Plan the sign-in figure for every user who signs in at the same time.

Do I need Premium Azure Files for FSLogix?

For medium, heavy and power workloads, Microsoft recommends Premium. Standard can work for light workloads under 200 users, or above that if you split users across several standard shares.

What is the difference between provisioned v1 and v2 in Azure Files?

On provisioned v1, IOPS and throughput are fixed by how much storage you provision. On provisioned v2, you provision storage, IOPS and throughput separately, so you can raise IOPS for sign-in storms without buying unused capacity. Microsoft recommends v2 for new deployments.

How many users can one Azure Files share hold for FSLogix?

There's no fixed user limit. The limits are capacity (up to 256 TiB per Premium v2 share) and performance (up to 102,400 IOPS per share and per storage account). For thousands of users, split profiles across several shares and storage accounts so sign-in storms don't compete.

Should FSLogix storage be in the same region as the session hosts?

Yes. A profile share in another region adds its network latency to every sign-in and every profile read, so keep the storage account in the same region as the hosts that mount it.

Last updated 9 November 2026. Microsoft details are drawn from Microsoft Learn as of November 2026: Storage options for FSLogix profile containers in Azure Virtual Desktop, FSLogix container storage options, FSLogix configuration settings reference, Understand Azure Files billing, Azure Files scalability and performance targets and Session host virtual machine sizing guidelines. Check Azure Files pricing for your region and redundancy.