Azure Files at scale: 100 TiB shares, Premium IOPS formulas, burst credits, per-file limits, and metadata IOPS ceilings most capacity planning misses entirely.
How Azure Files Handles Large-Scale Enterprise Data
"How big can a share get" and "how fast can a share go" are two genuinely different questions with two genuinely different sets of limits — and a third question, "how fast can one file go," has its own separate ceiling entirely, one that stays fixed no matter how large or well-provisioned the share around it is.
"How does Azure Files handle large-scale data" is really three separate technical questions bundled into one — how big a single share can grow, how much sustained IOPS and throughput that share can actually deliver, and how a single file inside it performs regardless of how generously the share around it is provisioned. Each of these has its own specific, documented ceiling, its own scaling formula, and its own set of easy-to-miss details that only surface once a deployment is genuinely operating at enterprise scale rather than a modest test share. This guide works through the actual mechanics precisely — current capacity limits, the real math behind Premium's provisioned performance model, how burst credits work, and a metadata-specific IOPS ceiling that a lot of capacity planning overlooks entirely.
Worth stating precisely before any capacity planning, since conflating these two dimensions leads to real, avoidable performance surprises.
| Dimension | What it governs |
|---|---|
| Share-level | Total capacity, aggregate IOPS, and aggregate throughput for the share as a whole — scales with provisioned size on Premium |
| File-level | Maximum size, IOPS, and throughput for any single file — fixed at 1 TiB, 1,000 IOPS, 60 MiB/s regardless of share provisioning |
Both present as the same symptom from an application's perspective — degraded throughput or elevated latency — but the correct response differs entirely depending on which ceiling is actually being hit. If it's the share-level limit, increasing provisioned capacity is the fix. If it's the file-level limit, no amount of additional share provisioning helps at all — the workload needs to be redesigned to spread activity across more files, since a single file's ceiling is fixed and non-negotiable.
Worth stating precisely, since older content commonly describes "large file shares" as a feature you need to explicitly opt into — that's no longer the default state for current accounts.
| Account type | Current status |
|---|---|
| Current pay-as-you-go accounts | 100 TiB per share by default — no opt-in required |
| Legacy accounts predating this change | May still be capped at 5 TiB unless large file share support is explicitly enabled |
| Redundancy trade-off for legacy accounts enabling it | Permanently locks the account to LRS or ZRS only — geo-redundant options (GRS, GZRS) are no longer available once enabled |
For a legacy storage account that still requires explicitly enabling large file share support, this change cannot be reversed once made, and it permanently removes access to geo-redundant storage options for that account. For workloads where cross-region data durability genuinely matters, plan an explicit cross-region replication strategy — Azure File Sync, AzCopy-based replication, or Azure Backup — before enabling this setting, not after discovering the geo-redundancy option is already gone.
Restating Figure 2's mechanic with the specific numbers behind it.
| Property | Detail |
|---|---|
| Burst multiplier | Up to 3x baseline IOPS, best effort, while accrued credit remains |
| Standard burst duration | Up to 60 minutes for shares up to 50 TiB |
| Extended burst duration | Shares larger than 50 TiB can sustain burst activity beyond 60 minutes |
| Starting credit balance | Full burst credit from the moment a share is created — not something that has to be earned over time first |
A workload with a genuinely bursty access pattern — nightly batch processing, month-end financial close, a deployment or build pipeline that spikes activity briefly — can be provisioned for its steady-state baseline need rather than its absolute peak, relying on burst credit to absorb the short-duration spikes, which is meaningfully more cost-efficient than provisioning permanently for peak capacity that sits unused the rest of the time. Understanding this mechanic precisely is worth factoring directly into capacity planning rather than defaulting to peak-based provisioning out of caution.
Metadata operations — opening a file, opening a folder, and other file-handle manipulations — have their own separate IOPS ceiling, distinct from general data-read/write IOPS, worth knowing about explicitly since it's easy to plan around only the general IOPS number.
| Property | Detail |
|---|---|
| Metadata IOPS cap | Up to 35,000 IOPS for SMB shares on SSD, achieved specifically through the metadata caching feature |
| Applies regardless of provisioned IOPS | The maximum metadata IOPS limit applies regardless of how much general IOPS a share has provisioned — it's a genuinely separate ceiling, not a subset of the general number |
| Workloads most likely to hit this ceiling first | Anything with a very high ratio of file opens/closes to actual data read/write — large numbers of small files, workloads that enumerate directories frequently |
A workload heavy on small-file operations — a build system checking out thousands of source files, a workload processing many small documents, or a directory structure being enumerated repeatedly — can hit the metadata IOPS ceiling well before it comes anywhere near its provisioned general data IOPS limit, since these are genuinely separate resource pools being consumed by different kinds of operations. If a workload's performance seems constrained despite apparently ample provisioned IOPS remaining, checking metadata IOPS utilization specifically, and confirming metadata caching is enabled, is a worthwhile diagnostic step before assuming the general IOPS provisioning simply needs to increase further.
Confirm the current storage account's large file share status
Run the CLI check from Section 2 — don't assume based on account age alone.
Characterize the actual workload access pattern: steady-state, bursty, or metadata-heavy
This determines whether to provision for peak, rely on burst credit, or pay specific attention to metadata IOPS from Section 5.
Decide between consolidating into fewer large shares vs multiple smaller ones
Default to consolidation for Premium performance per Section 3, unless a genuine access control or isolation requirement justifies separation.
Check whether any workload concentrates heavy activity on a small number of very large or very active files
If so, confirm against the per-file limits from Section 1 — this may require redesigning file structure rather than simply provisioning more share capacity.
For metadata-heavy workloads, confirm metadata caching is enabled and monitor metadata IOPS specifically
Don't assume general IOPS headroom automatically covers metadata operation capacity.
For Standard tier, evaluate whether co-locating high-activity shares with other resources in the same account creates isolation risk
Per Section 6 — separate into dedicated storage accounts if workload isolation genuinely matters.
Plan provisioning changes with the 24-hour decrease constraint in mind
Avoid designing around rapid up-and-down provisioning oscillation within the same day, per Section 3.
Validate actual sustained performance against the documented formula before committing to a final provisioned size
Load test at the planned scale to confirm real-world IOPS and throughput match the documented baseline figures for that provisioned capacity.
| Anti-pattern | Why it feels right | Why it isn't |
|---|---|---|
| Assuming a large, well-provisioned share means any single file can also perform at that level | "The share can do 100,000 IOPS, should apply everywhere" | Per-file limits (1,000 IOPS, 60 MiB/s) are fixed regardless of share-level provisioning — a workload concentrated on one file hits this ceiling independently |
| Splitting data across many smaller Premium shares for "better distribution" | "Smaller units should be easier to manage and scale" | A single larger share consistently outperforms multiple smaller ones totaling the same capacity — consolidate unless access control genuinely requires separation |
| Provisioning permanently for peak load instead of relying on burst credit | "Better to have guaranteed headroom always available" | Burst credit exists specifically for short, predictable peaks — provisioning for steady-state and relying on burst for spikes is meaningfully more cost-efficient |
| Assuming ample general IOPS headroom means metadata-heavy operations won't be constrained | "IOPS is IOPS" | Metadata IOPS is a genuinely separate ceiling (up to 35,000) from general data IOPS — a small-file-heavy workload can be metadata-bound independently |
| Co-locating a high-activity Standard-tier share with unrelated resources in the same storage account | "Fewer accounts to manage" | Standard tier pools IOPS/throughput at the account level — one busy share can throttle everything else sharing that account |
| Enabling large file share support on a legacy account without planning a replication strategy first | "Just flip the setting, deal with redundancy later" | The change permanently removes geo-redundant options — plan cross-region replication before enabling, not after |
Key Takeaways
Frequently Asked Questions
Related FAVORZENITH Articles
- Azure Files Deep Dive: Lessons from a 15TB Production Migration
- Understanding Azure File Shares for Enterprise Workloads
- Design the Best Azure Shared File System for Multiple VMs: Azure Files, Azure NetApp Files, and Storage Options
- Azure Files vs Azure NetApp Files: Which One Should You Choose?