Understand Azure Files Billing

Here’s a concise, structured summary of the article “Understand Azure Files billing models.” I preserved the original meaning and links where applicable.

Overview

  • Azure Files cost depends on four main factors:

    • Billing model: provisioned v2 (recommended), provisioned v1, or pay-as-you-go.

    • Media tier: SSD (premium) or HDD (standard).

    • Redundancy: LRS (Local), ZRS (Zone), GRS (Geo, HDD only), GZRS (GeoZone, HDD only).

    • Usage of value-added services (Azure File Sync, Azure Backup, Microsoft Defender for Storage), which add licensing, transaction, and Azure Files costs.

  • Pricing details: https://azure.cn/pricing/details/storage/files/

Storage units

  • Uses base-2 units: KiB, MiB, GiB, TiB (commonly mislabeled as KB/MB/GB/TB by some OSes).

  • OS labeling varies (Windows uses base-2 but labeled as base-10; macOS uses base-10).

File share total cost of ownership checklist

  • Compare billing models (provisioned vs pay-as-you-go).

  • Confirm resiliency and redundancy requirements.

  • Consider management overhead (Azure Files is fully managed).

  • Include costs of value-added services (licensing, their own transactions, and added Azure Files resource usage).

Provisioned v2 (recommended)

  • Predictable billing: you provision storage (GiB), IOPS, and throughput (MiB/s) and pay for what you provision.

  • Can scale up/down; decreases allowed only after 24 hours from last increase.

  • Default IOPS/throughput recommendations based on provisioned storage; you can override.

  • Bursting: credit-based IOPS bursting (accrual/decline/constant states). Burst limits and credits computed via given formulas.

  • Snapshots: differential; if snapshot differential + live data > provisioned storage, excess billed as Overflow Snapshot Usage (formula provided).

  • Soft delete: deleted shares while retained are billed for used storage during retention; provisioned quotas still count toward account limits (but not billed).

  • Billing meters: Provisioned Storage, Provisioned IOPS, Provisioned Throughput MiBPS, Overflow Snapshot Usage, Soft-Deleted Usage. Consumption emitted hourly.

  • Migration guidance:

    • Without Azure File Sync: Migrate files between shares (link).

    • With Azure File Sync: Use share-to-share migration guidance (link).

  • Availability and resource models: table-driven combinations of media, redundancy, protocol and storage-account SKUs (see article for full tables and limits).

Provisioned v1

  • Provisioned storage determines IOPS/throughput in fixed ratio (SSD only). Similar lifecycle rules to v2 (dynamic scale with 24-hour decrease restriction).

  • Baseline IOPS and throughput computed by formulas; to get more performance you must provision more storage.

  • Bursting: credit-based, with formulas and examples provided.

  • Snapshots: differential; snapshot storage billed to a used-snapshot meter (reduced price vs provisioned storage).

  • Soft delete: soft-deleted shares billed based on used storage, emitted against used snapshot storage meter.

  • Billing meters: Premium Provisioned (GiB) and Premium Snapshots. Consumption emitted hourly/monthly-unit conversions described.

  • Availability and resource models: SSD-only, specific SKUs required; account limits and planning considerations included.

Pay-as-you-go (HDD-only)

  • Usage-based billing: charged for used storage, transactions, and data transfer. Less predictable for budgeting.

  • Access tiers (transaction optimized, hot, cool) affect data-at-rest price and transaction prices—choose based on workload:

    • Transaction optimized: best for high IOPS; highest storage price, lowest transaction price.

    • Hot: middle ground.

    • Cool: lowest storage price, highest transaction price and data retrieval charges.

  • Transactions: SMB and REST operations translate to multiple transactions. Transactions are categorized (write, list, read, other/protocol, delete) with example operations per category.

  • Switching access tiers: causes transaction and possibly data retrieval charges; tier changes limited (max 5 changes per 30 days; 24-hour cooldown between changes).

  • Snapshots and soft-delete: snapshot differential and soft-deleted used storage billed to normal used-storage meter (no separate snapshot line item).

  • Billing meters: Data Stored, Metadata (hot/cool only), Write/List/Read/Other operations (buckets of 10,000), Data Retrieval (cool only), Geo-Replication Data Transfer (for GRS/GZRS). Consumption patterns and hourly/monthly unit conversions explained.

  • Availability and resource models: supported SKUs/combinations and storage-account limits listed; planning notes to avoid throttling and to track billing per resource.

Provisioned/quota, logical size, and physical size

  • Provisioned/quota: maximum allowed size (provisioned affects billing for provisioned models; quota for pay-as-you-go does not directly affect billing).

  • Logical size: reported “size” (used for enforcement and pay-as-you-go billing).

  • Physical size: actual allocated size on disk; used for snapshot billing (differential allocation between snapshots).

Value-added services (impact on TCO)

  • Costs divided into:

    • Licensing for the service.

    • Transaction costs from the service.

    • Additional Azure Files costs caused by the service (storage, transactions, provisioning needs).

  • Azure File Sync:

    • Syncs on-prem Windows servers to Azure file share; consider server infrastructure cost, per-server registration fee, Azure Files resource usage (storage, snapshots, IOPS/throughput).

    • Azure File Sync generates transactions from churn and daily cloud enumeration (one ListFiles per directory per day).

  • Azure Backup:

    • Snapshot-based backup for Azure Files; licensing per protected instance (250 GiB unit).

    • Adds snapshot storage and restore transaction costs.

  • Microsoft Defender for Storage:

    • Adds its own transaction-based charges (charged even on provisioned shares). Consider excluding storage accounts with heavy transactions if costs are high.

Operational guidance & planning notes

  • Account-level limits mean grouping and placement of file shares into storage accounts affects scalability and chargeability; plan headroom for 3–5 years.

  • Billing granularity is per resource; to track share-level costs, group shares into separate storage accounts as needed.

  • For pay-as-you-go, to pick access tier, start with transaction optimized during migration, then use actual metrics/pricing calculator to choose best tier.

  • To view transactions in the portal, follow the Metrics steps (converted into a stepper below).

Steps to see previous transactions (portal)

1

Navigate to your storage account in the Azure portal.

2

In the service menu, under Monitoring, select Metrics.

3

Select Scope as your storage account name, Metric Namespace as "File", Metric as "Transactions", and Aggregation as "Sum".

4

Select Apply Splitting.

5

Select Values as "API Name". Set Limit and Sort as desired.

6

Select your desired time period. Ensure timeframe excludes initial provisioning and is long enough for realistic averages.

Key links

  • Azure Files pricing: https://azure.cn/pricing/details/storage/files/

  • Provisioned v2 migration without File Sync: https://docs.azure.cn/en-us/storage/files/migrate-files-between-shares

  • Provisioned v2 migration with File Sync: https://docs.azure.cn/en-us/storage/file-sync/file-sync-share-to-share-migration

  • Create a classic file share: https://docs.azure.cn/en-us/storage/files/create-classic-file-share

  • Pricing calculator: https://azure.cn/pricing/calculator/

If you’d like, I can:

  • Produce an even shorter one-paragraph TL;DR,

  • Create a decision checklist (questions and recommended billing model/access tier),

  • Extract the key formulas and limits into a single quick-reference table. Which would you prefer?

Was this helpful?