Understand Azure Files billing models

Azure Files supports two different media tiers of storage, SSD and HDD, which allow you to tailor your file shares to the performance and price requirements of your scenario:

• SSD (premium): file shares hosted on solid-state drives (SSDs) provide consistent high performance and low latency, within single-digit milliseconds for most IO operations.
• HDD (standard): file shares host on hard disk drives (HDDs) provide cost-effective storage for general purpose use.

Azure Files has multiple pricing models including provisioned and pay-as-you-go options:

• Provisioned billing models: In a provisioned billing model, the primary costs of the file share are based on the amount of storage, IOPS (input and output operations per second), and throughput you provision when you create or update your file share, regardless of how much you use. Azure Files has one provisioned model provisioned v1.

  • Provisioned v1: In the provisioned v1 model for Azure Files, you provision the amount of storage you need for the share, while IOPS and throughput are determined based on how much storage you provision. The provisioned v1 model for Azure Files is only available for SSD file shares.

• Pay-as-you-go billing model: In a pay-as-you-go model, the cost of the file share is based on how much you use the share, in the form of used storage, transaction, and data transfer costs. The pay-as-you-go model is only available for HDD file shares.

This article explains how the billing models for Azure Files work, so you can better understand your monthly Azure Files bill. For Azure Files pricing information, see Azure Files pricing page.

Management model	Billing model	Media tier	Redundancy	SMB	NFS
Microsoft.Storage	Provisioned v1	SSD (premium)	Local (LRS)
Microsoft.Storage	Provisioned v1	SSD (premium)	Zone (ZRS)
Microsoft.Storage	Pay-as-you-go	HDD (standard)	Local (LRS)
Microsoft.Storage	Pay-as-you-go	HDD (standard)	Zone (ZRS)
Microsoft.Storage	Pay-as-you-go	HDD (standard)	Geo (GRS)
Microsoft.Storage	Pay-as-you-go	HDD (standard)	GeoZone (GZRS)

Azure Files uses the base-2 units of measurement to represent storage capacity: KiB, MiB, GiB, and TiB.

The base-2 units of measure are commonly used by most operating systems and tools to measure storage quantities. However, they're frequently mislabeled as the base-10 units, which you might be more familiar with: KB, MB, GB, and TB. The common reason why operating systems like Windows mislabel the storage units is because many operating systems began using these acronyms before they were standardized by the International Electrotechnical Commission (IEC), International Bureau of Weights and Measures (BIPM), and US National Institute of Standards and Technology (NIST).

The following table shows how common operating systems measure and label storage:

Check with your operating system vendor if your operating system isn't listed.

If you're migrating to Azure Files from on-premises or comparing Azure Files to other cloud storage solutions, consider the following factors to ensure a fair, apples-to-apples comparison:

• How do you pay for storage, IOPS, and bandwidth? Most cloud solutions have models that align with the principles of either provisioned storage, such as price determinism and simplicity, or pay-as-you-go storage, which can optimize costs by only charging you for what you actually use. Provisioned billing models can differ based on minimum provisioned share size, the provisioning unit, and the ability to increase and decrease provisioning.

• How do you achieve storage resiliency and redundancy? With Azure Files, storage resiliency and redundancy are included in the product offering. All tiers and redundancy levels ensure that data is highly available and at least three copies of your data are accessible. When considering other file storage options, consider whether storage resiliency and redundancy is built in, or something you must assemble yourself.

• What do you need to manage? Azure Files is a fully managed solution. Other solutions might require operating system updates or managing virtual resources such as VMs, disks, and network IP addresses.

• What are the costs of value-added products? Azure Files supports integrations with multiple first- and third-party value-added services. Value-added services such as Azure Backup, Azure File Sync, and Microsoft Defender for Storage provide backup, replication and caching, and security functionality for Azure Files. Value-added solutions, whether on-premises or in the cloud, have their own licensing and product costs, but are often considered part of the total cost of ownership for file storage.

The provisioned v1 method provides storage, IOPS, and throughput in a fixed ratio to each other, similar to how storage is purchased in an on-premises storage solution. When you create a new provisioned v1 file share, you specify how much storage your share needs, and IOPS and throughput are computed values. The provisioned v1 model for Azure Files is only available for SSD file shares.

The amount of storage you provision determines the guaranteed storage, IOPS, and throughput limits of your file share's usage. For example, if you provision a 2 TiB share and upload 2 TiB of data to your share, your share will be full. You won't be able to add more data unless you increase the size of your share, or delete some of the data. Credit-based IOPS bursting provides added flexibility around usage, on a best-effort basis, while credits remain.

Unlike purchasing storage on-premises, provisioned v1 file shares can be dynamically scaled up or down as your needs change. However, you can only decrease the provisioned storage after 24 hours have elapsed since your last storage increase. Storage, IOPS, and throughput changes are effective within a few minutes after a provisioning change.

It's possible to decrease the size of your provisioned share below your used GiB. If you do, you won't lose data, but you're still billed for the size used. You'll receive the performance of the provisioned share, not the size used.

The provisioned v1 model is provided for SSD file shares in storage accounts with the FileStorage storage account kind:

SSD file shares using the provisioned v1 model are generally available in most Azure regions. For more information, see Azure products by region.

When you create a provisioned v1 file share, you specify how much storage your share needs. Each GiB that you provision entitles you to more IOPS and throughput in a fixed ratio. File shares are limited based on the following attributes:

The following formulas determine the amount of IOPS and throughput provisioned on the share:

Depending on your individual file share requirement, you might find that you require more IOPS or throughput than our provisioning formulas provide. In this case, you need to provision more storage to get the required IOPS or throughput.

Credit-based IOPS bursting provides added flexibility around IOPS usage. This flexibility is best used as a buffer against unanticipated IO-spikes. For established IO patterns, we recommend provisioning for IO peaks.

Burst IOPS credits accumulate whenever traffic for your file share is less than provisioned (baseline) IOPS. Whenever a file share's IOPS usage exceeds the provisioned IOPS and there are available burst IOPS credits, the file share can burst up to the maximum allowed burst IOPS limit. File shares can continue to burst as long as there are credits remaining, based on the number of burst credits accrued. Each IO beyond provisioned IOPS consumes one credit. Once all credits are consumed, the share returns to the provisioned IOPS. IOPS against the file share don't have to do anything special to use bursting. Bursting operates on a best effort basis.

Share credits have three states:

• Accruing, when the file share is using less than the provisioned IOPS.
• Declining, when the file share is using more than the provisioned IOPS and in the bursting mode.
• Constant, when the files share is using exactly the provisioned IOPS and there are either no credits accrued or used.

A new file share starts with the full number of credits in its burst bucket. Burst credits don't accrue if the share IOPS fall below the provisioned limit due to throttling by the server. The following formulas are used to determine the burst IOPS limit and the number of credits possible for a file share:

The following table illustrates a few examples of these formulas for the provisioned share sizes:

Azure Files supports snapshots, which are similar to volume shadow copies (VSS) on Windows File Server. For more information on share snapshots, see Overview of snapshots for Azure Files.

Snapshots are always differential from the live share and from each other. In the provisioned v1 billing model, the total differential size is billed against a usage meter, regardless of how much provisioned storage is unused. The used snapshot storage meter has a reduced price over the provisioned storage price.

Deleted file shares in storage accounts with soft-delete enabled are billed based on the used storage capacity of the deleted share for the defined retention period. The soft-deleted usage storage capacity is emitted against the used snapshot storage meter. For more information on soft delete, see How to enable soft delete on Azure file shares.

File shares provisioned using the provisioned v1 billing model are billed against the following meters:

• Premium Provisioned: The amount of storage provisioned in GiB.
• Premium Snapshots: The amount of used snapshots and used soft-deleted capacity.

Consumption against the provisioned v1 billing meters are emitted hourly in terms of monthly units. For example, for a share with 1,024 GiB provisioned, you should see:

• A variable number of units for an individual hour depending on the number of days in the month:
  • 28 day month (normal February): 1.5238 units against the Premium Provisioned meter.
  • 29 day month (leap year February): 1.4713 units against the Premium Provisioned meter.
  • 30 day month: 1.4222 units against the Premium Provisioned meter.
  • 31 day month: 1.3763 units against the Premium Provisioned meter.
• A variable number of units if aggregated for a day depending on the number of days in the month:
  • 28 day month (normal February): 36.5714 units against the Premium Provisioned meter.
  • 29 day month (leap year February): 35.3103 units against the Premium Provisioned meter.
  • 30 day month: 34.1333 units against the Premium Provisioned meter.
  • 31 day month: 33.0323 units against the Premium Provisioned meter.
• 1,024 units against the Premium Provisioned meter if aggregated for a month.

In the pay-as-you-go model, you're billed on how much storage you use, not how much you provision. At a high level, you pay a cost for the amount of logical data stored, and you're also charged for transactions based on your usage of that data. Pay-as-you-go billing can be difficult to plan for as part of a budgeting process, because you pay based on end-user consumption. The pay-as-you-go model is only available for HDD file shares.

The pay-as-you-go model is provided for HDD file shares in storage accounts with the StorageV2 or Storage storage account kind:

HDD file shares using the pay-as-you-go model are generally available in all Azure regions.

When you create an HDD file share, you pick between the following access tiers: transaction optimized, hot, and cool. All three access tiers are stored on the exact same storage hardware. The main difference for these three access tiers is their data at-rest storage prices, which are lower in cooler tiers, and the transaction prices, which are higher in the cooler tiers. This means:

• Transaction optimized, as the name implies, optimizes the price for high IOPS (transaction) workloads. Transaction optimized has the highest data at-rest storage price, but the lowest transaction prices.
• Hot is for active workloads that don't involve a large number of transactions. It has a slightly lower data at-rest storage price, but slightly higher transaction prices as compared to transaction optimized. Think of it as the middle ground between the transaction optimized and cool tiers.
• Cool optimizes the price for workloads that don't have high activity, offering the lowest data at-rest storage price, but the highest transaction prices.

Selecting the appropriate access tier for your use case allows you to considerably reduce your costs. If you put an infrequently accessed workload in the transaction optimized access tier, you pay almost nothing for the few times in a month that you make transactions against your share. However, you pay a high amount for the data storage costs. If you moved this same share to the cool access tier, you'd still pay almost nothing for the transaction costs, simply because you're infrequently making transactions for this workload. However, the cool access tier has a cheaper data storage price.

Similarly, if you put a highly accessed workload in the cool access tier, you pay a lot more in transaction costs, but less for data storage costs. This can lead to a situation where the increased costs from the transaction prices increase outweigh the savings from the decreased data storage price, and you might pay more for cool than you would have paid for transaction optimized. For some usage levels, it's possible that the hot access tier will be the most cost efficient, and the cool access tier will be more expensive than transaction optimized.

Your workload and activity level determine the most cost efficient access tier for your pay-as-you-go file share. In practice, the best way to pick the most cost efficient access tier involves looking at the actual resource consumption of the share (data stored, write transactions, etc.). For pay-as-you-go file shares, we recommend starting in the transaction optimized tier during the initial migration into Azure Files, and then picking the correct access tier based on usage after the migration is complete. Transaction usage during migration typically isn't indicative of normal transaction usage.

When you mount an Azure file share on a computer using SMB, the Azure file share is exposed on your computer as if it were local storage. This means that applications, scripts, and other programs on your computer can access the files and folders on the Azure file share without needing to know that they're stored in Azure.

When you read or write to a file, the application you're using performs a series of API calls to the file system API provided by your operating system. Your operating system then interprets these calls into SMB protocol transactions, which are sent over the wire to Azure Files to fulfill. A simple task that the end user perceives as a single operation, such as reading a file from start to finish, might be translated into multiple SMB transactions served by Azure Files.

As a principle, the pay-as-you-go billing model used by standard file shares bills based on usage. SMB and FileREST transactions made by applications and scripts represent usage of your file share, and they show up as part of your bill. The same concept applies to value-added cloud services that you might add to your share, such as Azure File Sync or Azure Backup.

Transactions are grouped into five different transaction categories which have different prices based on their impact on the Azure file share. These categories are: write, list, read, other, and delete.

The following table shows the categorization of each transaction:

Although you can change a pay-as-you-go file share between the three access tiers, the best practice to optimize costs after the initial migration is to pick the most cost optimal access tier to be in, and stay there unless your access pattern changes. This is because changing the access tier of a standard file share results in extra costs as follows:

• Transactions: When you move a share from a hotter access tier to a cooler access tier, you incur the cooler access tier's write transaction charge for each file in the share. Moving a file share from a cooler access tier to a hotter access tier incurs the cooler access tier's read transaction charge for each file in the share.

• Data retrieval: If you're moving from the cool access tier to hot or transaction optimized, you incur a data retrieval charge based on the size of data moved. Only the cool access tier has a data retrieval charge.

The following table illustrates the cost breakdown of moving access tiers:

You can change a file share's access tier up to five times within a 30-day window. The first day of the 30-day window begins when the first tier change happens. Changes between access tiers happen instantly, however, once you change the access tier of a share, you can't change it again within 24 hours, even if you've changed the access tier property fewer than five times within the last 30 days.

Regardless of how you migrate existing data into Azure Files, we recommend initially creating the file share in the transaction optimized access tier. This is due to the large number of transactions incurred during migration. After your migration is complete and you operate for a few days or weeks with regular usage, you can plug your transaction counts into the pricing calculator to determine which access tier is best suited for your workload.

Because pay-as-you-go file shares only show transaction information at the storage account level, using the storage metrics to estimate which access tier is cheaper at the file share level is an imperfect science. If possible, we recommend deploying only one file share in each storage account to ensure full visibility into billing.

To see previous transactions:

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". Select your desired Limit and Sort.
6. Select your desired time period.

Azure Files supports snapshots, which are similar to volume shadow copies (VSS) on Windows File Server. For more information on share snapshots, see Overview of snapshots for Azure Files.

Snapshots are always differential from the live share and from each other. In the pay-as-you-go billing model, the total differential size is billed against the normal used storage meter. This means that you won't see a separate line item on your bill representing snapshots for your pay-as-you-go storage account. This also means that differential snapshot usage counts against reservations that are purchased for pay-as-you-go file shares.

Deleted file shares in storage accounts with soft-delete enabled are billed based on the used storage capacity of the deleted file share for the defined retention period. The soft-deleted used storage capacity is emitted against the normal used storage meter. This means that you won't see a separate line item on your bill representing soft-deleted file shares for your pay-as-you-go storage account. This also means that soft-deleted file share usage counts against reservations that are purchased for pay-as-you-go file shares.

File shares created using the pay-as-you-go billing model are billed against the following meters:

• Data Stored: The used storage including the live shares, differential snapshots, and soft-deleted file shares in GiB.
• Metadata: The size of the file system metadata associated with files and directories such as access control lists (ACLs) and other properties in GiB. This billing meter is only used for file shares in the hot or cool access tiers.
• Write Operations: The number of write transaction buckets (one bucket = 10,000 transactions).
• List Operations: The number of list transaction buckets (one bucket = 10,000 transactions).
• Read Operations: The number of read transaction buckets (one bucket = 10,000 transactions).
• Other Operations / Protocol Operations: The number of other transaction buckets (one bucket = 10,000 transactions).
• Data Retrieval: The amount of data read from the file share in GiB. This meter is only used for file shares in the cool access tier.
• Geo-Replication Data Transfer: If the file share has the Geo or GeoZone redundancy, the amount of data written to the file share replicated to the secondary region in GiB.

Consumption units against the Data Stored and Metadata billing meters are emitted hourly in terms of monthly units. For example, for a share with 1,024 used GiB, you should see:

• A variable number of units for an individual hour depending on the number of days in the month:
  • 28 day month (normal February): 1.5238 units against the Data Stored meter.
  • 29 day month (leap year February): 1.4713 units against the Data Stored meter.
  • 30 day month: 1.4222 units against the Data Stored meter.
  • 31 day month: 1.3763 units against the Data Stored meter.
• A variable number of units if aggregated for a day depending on the number of days in the month:
  • 28 day month (normal February): 36.5714 units against the Data Stored meter.
  • 29 day month (leap year February): 35.3103 units against the Data Stored meter.
  • 30 day month: 34.1333 units against the Data Stored meter.
  • 31 day month: 33.0323 units against the Data Stored meter.
• 1,024 units against the Data Stored meter if aggregated for a month.

Consumption against the other meters (ex. Write Operations or Data Retrieval) are emitted hourly, but since they aren't emitted in terms of a timeframe, don't have any special unit transformations to be aware of.

Azure Files tracks three distinct quantities with respect to share capacity:

• Provisioned size or quota: With both provisioned and pay-as-you-go file shares, you specify the maximum size that the file share is allowed to grow to. In provisioned file shares, this value is called the provisioned size. Whatever amount you provision is what you pay for, regardless of how much you actually use. In pay-as-you-go file shares, this value is called quota and doesn't directly affect your bill. Provisioned size is a required field for provisioned file shares. For pay-as-you-go file shares, if provisioned size isn't directly specified, the share defaults to the maximum value that the storage account supports (100 TiB).

• Logical size: The logical size of a file share or file relates to how large it is without considering how it's actually stored, without any storage optimization. The logical size of the file is how many KiB/MiB/GiB would be transferred over the wire if you copied it to a different location. In both provisioned and pay-as-you-go file shares, the total logical size of the file share is used for enforcement against provisioned size/quota. In pay-as-you-go file shares, the logical size is the quantity used for the data at-rest usage billing. Logical size is referred to as "size" in the Windows properties dialog for a file/folder and as "content length" by Azure Files metrics.

• Physical size: The physical size of the file relates to the size of the file as encoded on disk. Physical size might align with the file's logical size, or it might be smaller, depending on how the file has been written to by the operating system. A common reason for the logical size and physical size to be different is by using sparse files. The physical size of the files in the share is used for snapshot billing, although allocated ranges are shared between snapshots if they're unchanged (differential storage).

Like many on-premises storage solutions, Azure Files provides integration points for first- and third-party products to integrate with customer-owned file shares. Although these solutions can provide considerable extra value to Azure Files, you should consider the extra costs that these services add to the total cost of an Azure Files solution.

Costs break down into three buckets:

• Licensing costs for the value-added service. Licensing costs might come in the form of a fixed cost per customer, end user (sometimes called a "head cost"), Azure file share, or storage account. They might also be based on units of storage utilization, such as a fixed cost for every 500 GiB-chunk of data in the file share.

• Transaction costs for the value-added service. Some value-added services have their own concept of transactions on top of the Azure Files billing model selected. These transactions show up on your bill under the value-added service's charges; however, they relate directly to how you use the value-added service with your file share.

• Azure Files costs for using a value-added service. Azure Files doesn't directly charge customers for adding value-added services, but as part of adding value to the Azure file share, the value-added service might increase the costs that you see on your Azure file share. These costs are easy to see with pay-as-you-go file shares, because of transaction charges. If the value-added service does transactions against the file share on your behalf, they show up in your Azure Files transaction bill even though you didn't directly do those transactions yourself. This applies to provisioned file shares as well, although it might be less noticeable. Transactions against provisioned file shares from value-added services count against your provisioned IOPS numbers, meaning that value-added services might require provisioning more storage to have enough IOPS or throughput available for your workload.

When computing the total cost of ownership for your file share, you should consider the costs of Azure Files and of all value-added services that you would like to use with Azure Files.

There are multiple value-added first- and third-party services. This document covers a subset of the common first-party services customers use with Azure file shares. You can learn more about services not listed here by reading the pricing page for that service.

Azure File Sync is a value-added service for Azure Files that synchronizes one or more on-premises Windows file shares with an Azure file share. Because the cloud Azure file share has a complete copy of the data in a synchronized file share that is available on-premises, you can transform your on-premises Windows File Server into a cache of the Azure file share to reduce your on-premises footprint. Learn more by reading Introduction to Azure File Sync.

When considering the total cost of ownership for a solution deployed using Azure File Sync, you should consider the following cost aspects:

• Capital and operational costs of Windows File Servers with one or more server endpoints. Azure File Sync as a replication solution is agnostic of where the Windows File Servers that are synchronized with Azure Files are; they could be hosted on-premises, in an Azure VM, or even in another cloud. Unless you are using Azure File Sync with a Windows File Server that is hosted in an Azure VM, the capital (i.e. the upfront hardware costs of your solution) and operating (i.e. cost of labor, electricity, etc.) costs will not be part of your Azure bill, but will still be very much a part of your total cost of ownership. You should consider the amount of data you need to cache on-premises, the number of CPUs and amount of memory your Windows File Servers need to host Azure File Sync workloads (see recommended system resources for more information), and other organization-specific costs you might have.

• Per server licensing cost for servers registered with Azure File Sync. To use Azure File Sync with a specific Windows File Server, you must first register it with Azure File Sync's Azure resource, the Storage Sync Service. Each server that you register after the first server has a flat monthly fee. Although this fee is very small, it is one component of your bill to consider. To see the current price of the server registration fee for your desired region, see the File Sync section on Azure Files pricing page.

• Azure Files costs. Because Azure File Sync is a synchronization solution for Azure Files, it will cause you to consume Azure Files resources. Some of these resources, like storage consumption, are relatively obvious, while others such as transaction and snapshot utilization may not be. For most customers, we recommend using standard file shares with Azure File Sync, although Azure File Sync is fully supported with premium file shares if desired.

  • Storage utilization. Azure File Sync will replicate any changes you have made to the path on your Windows File Server specified on your server endpoint to your Azure file share, thus causing storage to be consumed. On standard file shares, this means that adding or increasing the size of existing files on server endpoints will cause storage costs to grow, because the changes will be replicated. On premium file shares, changes will be consume provisioned space - it is your responsibility to periodically increase provisioning as needed to account for file share growth.

  • Snapshot utilization. Azure File Sync takes share and file-level snapshots as part of regular usage. Although snapshot utilization is always differential, this can contribute in a noticeable way to the total Azure Files bill.

  • Transactions from churn. As files change on server endpoints, the changes are uploaded to the cloud share, which generates transactions. When cloud tiering is enabled, additional transactions are generated for managing tiered files, including I/O happening on tiered files, in addition to egress costs. Although the quantity and type of transactions is difficult to predict due to churn rates and cache efficiency, you can use your previous transaction patterns to estimate future costs if you believe your future usage will be similar to your current usage.

  • Transactions from cloud enumeration. Azure File Sync enumerates the Azure File Share in the cloud once per day to discover changes that were made directly to the share so that they can sync down to the server endpoints. This scan generates transactions which are billed to the storage account at a rate of one ListFiles transaction per directory per day. You can put this number into the pricing calculator to estimate the scan cost.

  Tip

  If you don't know how many folders you have, check out the TreeSize tool from JAM Software GmbH.

Azure Backup provides a serverless backup solution for Azure Files that seamlessly integrates with your file shares, and with other value-added services such as Azure File Sync. Azure Backup for Azure Files is a snapshot-based backup solution that provides a scheduling mechanism for automatically taking snapshots on an administrator-defined schedule. It also provides a user-friendly interface for restoring deleted files/folders or the entire share to a particular point in time. To learn more, see About Azure file share backup.

When considering the costs of using Azure Backup, consider the following factors:

• Protected instance licensing cost for Azure file share data. Azure Backup charges a protected instance licensing cost per storage account containing backed up Azure file shares. A protected instance is defined as 250 GiB of Azure file share storage. Storage accounts containing less than 250 GiB are subject to a fractional protected instance cost. For more information, see Azure Backup pricing. You must select Azure Files from the list of services Azure Backup can protect.

• Azure Files costs. Azure Backup increases the costs of Azure Files in the following ways:

  • Differential costs from Azure file share snapshots. Azure Backup automates taking Azure file share snapshots on an administrator-defined schedule. Snapshots are always differential; however, the added cost added depends on the length of time snapshots are kept and the amount of churn on the file share during that time. These factors dictate how different the snapshot is from the live file share and therefore how much extra data is stored by Azure Files.

  • Transaction costs from restore operations. Restore operations from the snapshot to the live share incur transaction costs. For standard file shares, reads from snapshots/writes from restores are billed as normal file share transactions. For provisioned file shares, these operations count against the provisioned IOPS for the file share.

Microsoft Defender supports Azure Files as part of its Microsoft Defender for Storage product. Microsoft Defender for Storage detects unusual and potentially harmful attempts to access or exploit your Azure file shares over SMB or FileREST. Microsoft Defender for Storage is enabled on the subscription level for all file shares in storage accounts in that subscription.

Microsoft Defender for Storage doesn't support antivirus capabilities for Azure file shares.

The main cost from Microsoft Defender for Storage is an extra set of transaction costs that the product levies on top of the transactions that are done against the Azure file share. Although these costs are based on the transactions incurred in Azure Files, they aren't part of the billing for Azure Files, but rather are part of the Microsoft Defender pricing. Microsoft Defender for Storage charges a transaction rate even on provisioned file shares, where Azure Files includes transactions as part of IOPS provisioning. The current transaction rate can be found on Microsoft Defender for Cloud pricing page under the Microsoft Defender for Storage table row.

Transaction heavy file shares incur significant costs using Microsoft Defender for Storage. Based on these costs, you might want to opt-out of Microsoft Defender for Storage for specific storage accounts. For more information, see Exclude a storage account from Microsoft Defender for Storage protections.

• Azure Files pricing page.
• Planning for an Azure Files deployment and Planning for an Azure File Sync deployment.
• Create a file share and Deploy Azure File Sync.