Azure Files premium storage supports two generations of file shares, each billed — and auto-scaled — differently:
-
Provisioned V1: billed by provisioned share size only, regardless of used capacity. Share sizes range from 100 GiB to 102,400 GiB. IO and network bandwidth limits scale automatically with the provisioned size, but are not separately configurable.
-
Provisioned V2: billed by three independently provisioned values — share size, IOPS, and throughput. Azure supports share sizes up to 262,144 GiB, though the Max quota limit field currently accepts a maximum of 102,400 GiB (a known product limitation expected to be corrected in a future release). Provisioned IOPS ranges from 3,000 to 102,400, and provisioned throughput from 100 to 10,340 MiB/s. Billing rates for all three vary by region and other parameters — see Azure Files Pricing for details.
When enabled, storage auto-scale grows the provisioned values in response to scheduled demand (see Scheduled Quota Increase / Scheduled Performance Increase) or measured storage latency (see Scaling Logic). It also decreases them to reduce costs when the extra performance is no longer needed — but each value can only be decreased 24 hours after its own last increase; there is no cooldown on increases.
Storage auto-scaling with Azure Files can also be used to maintain a specified headroom to avoid running out of space on the share.
Note
Auto-scale is not available for Azure Files pay-as-you-go shares (Standard, non-Provisioned), because those shares are billed on used capacity and transactions rather than on provisioned values — there's nothing for auto-scale to adjust. Auto-scale is available for Provisioned V2 shares on either tier — SSD (Premium) or HDD (Standard) — since both are billed on provisioned size, IOPS, and throughput.
Note
Auto-scale is disabled by default on a newly linked share. There is no conversion between Provisioned V1 and Provisioned V2 — the generation is fixed when the underlying storage account is created, and a share is always one or the other.
You must configure these auto-scale parameters:
-
Provisioned Size (Quota), IOPS and Throughput (the values scaled depend on whether the share is Provisioned V1 or Provisioned V2 — see below)
-
Scheduled Quota Increase (Provisioned V1) or Scheduled Performance Increase (Provisioned V2) (Optional)
-
Scaling Logic
To configure and manage auto-scale for Azure Files premium:
-
Navigate to Cloud Desktops > Storage > Azure Files.
-
Locate the file share you want to manage.
-
From the action menu, select Auto-scale > Configure.
-
Toggle the Auto-scale option to On.
-
Refer to the table that matches your share's generation (Provisioned V1 or Provisioned V2), and enter the Provisioned Size (Quota), IOPS and Throughput settings listed.
Note
If a value is outside its configured range, auto-scale brings it back into range on the next run — but always to the range minimum, in either direction. For example, if you enable auto-scale on a share that's already larger than its configured maximum, auto-scale shrinks it down to the minimum size, not down to the maximum.
UI Element
Type
Description
Quota unit
Drop-down list
Select the unit used for Minimum size and Maximum size: Relative (%), a buffer expressed as a percentage of currently used capacity, or Absolute (GiB), the same buffer expressed as a fixed number of GiB above currently used capacity. Either way, both fields still track used capacity — the unit only changes how the buffer is expressed.
Minimum size
Text field
The smallest size auto-scale will maintain, entered in GiB or % above used capacity. The minimum is 100 GiB, and cannot be set smaller than the share's current used capacity. This value defines the buffer of free space auto-scale always keeps available as used capacity grows.
Maximum size
Text field
The largest size auto-scale will grow the share to, entered in GiB or % above used capacity, up to a ceiling entered in the Less than field. Auto-scale increases the share only up to this maximum, to prevent uncontrolled growth.
Performance
Read-only display
Shows the minimum and maximum performance characteristics that result from the configured size range. These values are calculated by Azure from the provisioned size and cannot be configured directly:
-
IO/S: baseline IOPS, calculated as 3,000 + 1 per provisioned GiB, up to a maximum baseline rate of 100,000 IO/s.
-
Burst IO/S: the greater of 10,000 IO/s or 3× the baseline IO/s rate. Unused baseline IO accumulates as burst credits (up to a limit) that are drawn down when demand exceeds the baseline rate, up to a maximum burst rate of 100,000 IO/s.
-
Egress Rate: allowed network egress per second, calculated as 60 + (share quota × 0.06 MiByte/s).
-
Ingress Rate: allowed network ingress per second, calculated as 40 + (share quota × 0.04 MiByte/s).
Note
Billing rates for provisioned size, IOPS, and throughput vary by region and other parameters. See Azure Files Pricing for details.
UI Element
Type
Description
Quota unit
Drop-down list
Select the unit used for Minimum size and Maximum size: Relative (%), a buffer expressed as a percentage of currently used capacity, or Absolute (GiB), the same buffer expressed as a fixed number of GiB above currently used capacity. Either way, both fields still track used capacity — the unit only changes how the buffer is expressed.
Minimum size
Text field
The smallest size auto-scale will maintain, entered in GiB or % above used capacity. The minimum is 32 GiB, and cannot be set smaller than the share's current used capacity. This value defines the buffer of free space auto-scale always keeps available as used capacity grows.
Auto-scale also never shrinks the share below its size floor — the smallest size whose IOPS/throughput cap can still cover the share's currently provisioned IOPS and throughput. For example, an SSD-tier share with 20,000 IOPS provisioned won't scale in below roughly 1,000 GiB, since that's the size needed to keep the cap at or above 20,000 IOPS. Because HDD's recommended-IOPS formula grows more slowly per GiB than SSD's, the same provisioned IOPS value requires a much larger HDD share to clear the cap.
Maximum size
Text field
The largest size auto-scale will grow the share to, entered in GiB or % above used capacity, up to a ceiling entered in the Less than field. Although Azure supports share sizes up to 262,144 GiB, this field currently accepts a maximum of 102,400 GiB — a known product limitation expected to be corrected in a future release. Auto-scale increases the share only up to this maximum, to prevent uncontrolled growth.
Provisioned IOPS
Text fields (from / to)
The range auto-scale keeps provisioned IOPS within. Azure enforces a guardrail capping provisioned IOPS at 5× the value Microsoft recommends for the share's current size, and never above the tier's absolute maximum. The recommended value, and therefore the cap, differs by media tier:
-
SSD (Premium): recommended IOPS is 3,000 + 1 per provisioned GiB, capped at 5× that value, never above 102,400 IOPS. At 32 GiB the ceiling is 15,160 IOPS, reaching the 102,400 IOPS absolute maximum at around 17,480 GiB.
-
HDD (Standard): recommended IOPS is 1,000 + 0.2 per provisioned GiB, capped at 5× that value, never above 50,000 IOPS. At 32 GiB the ceiling is roughly 5,030 IOPS, reaching the 50,000 IOPS absolute maximum at around 45,000 GiB.
Either way, the cap rises as the share grows (well below the 102,400 GiB the Max quota limit field currently allows). Auto-scale does not grow the share purely to reach a higher IOPS cap; raising the Minimum size is what lifts the cap sooner.
This is a ratchet, not a hard block: a share that was already provisioned above 5× before this guardrail existed keeps running as-is — auto-scale just won't let its IOPS-to-size ratio increase any further.
Provisioned throughput (MiB/s)
Text fields (from / to)
The range auto-scale keeps provisioned throughput within. Azure enforces a guardrail capping provisioned throughput at 5× the value Microsoft recommends for the share's current size, and never above the tier's absolute maximum. The recommended value, and therefore the cap, differs by media tier:
-
SSD (Premium): recommended throughput is 100 + 0.1 MiB/s per provisioned GiB, capped at 5× that value, never above 10,340 MiB/s. At 32 GiB the ceiling is 520 MiB/s, reaching the 10,340 MiB/s absolute maximum at around 19,680 GiB.
-
HDD (Standard): recommended throughput is 60 + 0.02 MiB/s per provisioned GiB, capped at 5× that value, never above 5,120 MiB/s. At 32 GiB the ceiling is roughly 303 MiB/s, reaching the 5,120 MiB/s absolute maximum at around 48,200 GiB.
Either way, the cap rises as the share grows (well below the 102,400 GiB the Max quota limit field currently allows). Auto-scale does not grow the share purely to reach a higher throughput cap; raising the Minimum size is what lifts the cap sooner.
This is a ratchet, not a hard block: a share that was already provisioned above 5× before this guardrail existed keeps running as-is — auto-scale just won't let its throughput-to-size ratio increase any further.
-
-
Optionally, toggle Scheduled Quota Increase (Provisioned V1) or Scheduled Performance Increase (Provisioned V2) to On. This commits to a temporary increase during a recurring window — for example, if you have days with predictable peak demand. While the schedule is active, the scheduled values are held and latency-based scaling rules do not apply to them. Refer to the table that matches your share's generation, and enter the settings listed.
Note
Provisioned size (quota) is increased at the beginning of the scheduled period. Returning it to the normal range afterward is a decrease, so it is still subject to the 24-hour lock — it does not happen simply because the scheduled period ended.
This means the quota can stay elevated well beyond the scheduled day itself: the increase happens at the start of each selected day, and the quota can't scale back down until 24 hours after that increase — the start of the following day. On a recurring Monday–Friday schedule, this can mean the quota never returns to its normal range between consecutive scheduled days, which is worth planning for as a potential cost impact.
UI Element
Type
Description
Days
Drop-down list
Select the range of days the schedule applies to.
Hours
Time range and drop-down list
Select the time zone the schedule applies in. Although this field also displays a start/end time range, the schedule currently applies to the entirety of each selected day, regardless of the times entered here.
Set provisioned size (quota) to
Text field
The quota, above current used capacity, that the share is set to for the duration of the scheduled window.
Note
Provisioned IOPS and throughput are increased at the beginning of the scheduled period. Returning them to their normal ranges afterward is a decrease, so each is still subject to its own 24-hour lock — it does not happen simply because the scheduled period ended. (Size has its own independent 24-hour lock too, but this schedule does not pin size — see Provisioned Size (Quota), IOPS and Throughput.)
This means IOPS and throughput can stay elevated well beyond the scheduled day itself: the increase happens at the start of each selected day, and they can't scale back down until 24 hours after that increase — the start of the following day. On a recurring Monday–Friday schedule, this can mean they never return to their normal ranges between consecutive scheduled days, which is worth planning for as a potential cost impact.
UI Element
Type
Description
Days
Drop-down list
Select the range of days the schedule applies to.
Hours
Time range and drop-down list
Select the time zone the schedule applies in. Although this field also displays a start/end time range, the schedule currently applies to the entirety of each selected day, regardless of the times entered here.
Set provisioned IOPS to
Text field
The provisioned IOPS value the share is held at for the duration of the scheduled window.
Set provisioned throughput (MiB/s) to
Text field
The provisioned throughput value the share is held at for the duration of the scheduled window.
-
These conditions determine when auto-scale increases or decreases the provisioned values: any rule proposing an increase causes an increase, and a decrease is applied when a rule proposes one. Refer to the table that matches your share's generation, and enter the Scaling Logic settings listed.
Note
Provisioned size (quota) can be decreased only 24 hours after the last quota increase — there is no cooldown on increases.
Provisioned V1 supports up to two rules, both targeting size (quota). Each rule contains both a scale-out condition and a scale-in condition — the two rules are not "one for scale-out, one for scale-in." Instead, they're distinguished by trigger: one rule can use average latency, the other maximum latency; each trigger can be used once.
When more than one rule's conditions are met at once, auto-scale combines them as follows: any proposed increase wins over any proposed decrease; if two rules both propose a decrease, the higher (less aggressive) resulting value is applied; a rule whose latency is between its own scale-out and scale-in thresholds proposes nothing — it does not veto another rule that does propose a change.
UI Element
Type
Description
Select auto-scale trigger
Drop-down list
The latency metric that drives scaling: Success Server Latency (avg) (default) or Success Server Latency (max) — the average or maximum time Azure Storage takes to process a successful request.
Increase quota (scale out) by
Text field (% or GiB)
The step size to increase the quota by (in the unit set under Quota unit) each time the scale-out condition below is met. While the latency threshold is exceeded, the system keeps scaling out until it either reaches the configured maximum size or the latency drops back under the threshold.
if Success Server Latency exceeds
Text field (ms)
The latency threshold, in milliseconds, that triggers a scale-out.
for … Minutes (scale-out)
Drop-down list
The measurement window the scale-out latency threshold must be sustained for: 5, 15, 30, or 60 minutes.
Decrease quota (scale in) by
Text field (% or GiB)
The step size to decrease the quota by each time the scale-in condition below is met.
if Success Server Latency drops below
Text field (ms)
The latency threshold, in milliseconds, that triggers a scale-in.
for … Minutes (scale-in)
Drop-down list
The measurement window the scale-in latency threshold must be sustained for: 5, 15, 30, or 60 minutes.
Note
Provisioned IOPS and throughput can each be decreased only 24 hours after their own last increase — there is no cooldown on increases. (Size has its own independent 24-hour lock too, tracked separately from IOPS and throughput.)
Provisioned V2 supports up to four rules — one for each combination of target (Provisioned IOPS or Provisioned throughput) and trigger (average or maximum latency); each combination can be used once. Each rule contains both a scale-out condition and a scale-in condition — a rule is not "for scale-out" or "for scale-in" only. Select + to add a rule and choose which value and trigger it uses.
When more than one rule's conditions are met at once, auto-scale combines them as follows: any proposed increase wins over any proposed decrease; if two rules on the same target both propose a decrease, the higher (less aggressive) resulting value is applied; the result is then clamped to the target's cap; and a decrease is dropped entirely if the target is currently locked. A rule whose latency is between its own scale-out and scale-in thresholds proposes nothing — it does not veto another rule that does propose a change.
UI Element
Type
Description
Type
Drop-down list
-
Provisioned IOPS: this rule scales provisioned IOPS.
-
Provisioned throughput: this rule scales provisioned throughput (MiB/s).
Each rule targets one value and uses one trigger, but covers both directions (scale-out and scale-in) for that value. Up to four rules can exist at once — one for each combination of target (IOPS or throughput) and trigger (avg or max latency).
Unlike size, which can use either % or GiB (set under Quota unit in the previous step), IOPS and throughput scaling steps are always entered as absolute values (IOPS or MiB/s) — there is no percentage option for either.
Select auto-scale trigger
Drop-down list
The latency metric that drives scaling — the average or maximum time Azure Storage takes to process a successful request. The options available depend on the Type selected above:
-
Type: Provisioned IOPS — both Success Server Latency (avg) (default) and Success Server Latency (max) are available.
-
Type: Provisioned throughput — only Success Server Latency (max) is available.
Increase provisioned IOPS / throughput (scale out) by
Text field (IOPS or MiB/s)
The step size to increase the value selected under Type by, each time the scale-out condition below is met. The increase is bounded by the value's cap (see Provisioned IOPS / Provisioned throughput in the previous step).
if Success Server Latency exceeds
Text field (ms)
The latency threshold, in milliseconds, that triggers a scale-out.
for … Minutes (scale-out)
Drop-down list
The measurement window the scale-out latency threshold must be sustained for: 5, 15, 30, or 60 minutes.
Decrease provisioned IOPS / throughput (scale in) by
Text field (IOPS or MiB/s)
The step size to decrease the value selected under Type by, each time the scale-in condition below is met.
if Success Server Latency drops below
Text field (ms)
The latency threshold, in milliseconds, that triggers a scale-in.
for … Minutes (scale-in)
Drop-down list
The measurement window the scale-in latency threshold must be sustained for: 5, 15, 30, or 60 minutes.
-
-
Once you have entered all the desired information, select Save or Save & close.
The configured file share appears on the Azure Files list.
Related Topics
Comments (0 comments)