General Availability: Azure Active Directory Kerberos with Azure Files for hybrid identities
We are excited to announce General Availability of Azure Files integration with Azure Active Directory (Azure AD) Kerberos for hybrid identities. With this release, identities in Azure AD can mount and access Azure file shares without the need for line-of-sight to an Active Directory domain controller.Migrate the critical file data you need to power your applications
When you migrate applications to Azure, you cannot leave file data behind. The Azure File Migration program can help you migrate data from NFS, SMB, and S3 sources to Azure Storage Services in less time, less risk, and no headache! Learn how to take advantage of this program and about the fundamentals of file migration in this post.Azure Storage Mover can now migrate your SMB shares to Azure file shares.
Azure Storage Mover can now migrate your SMB shares to Azure file shares. Storage Mover is a fully managed migration service that enables you to migrate on-premises files and folders to Azure Storage while minimizing downtime for your workload. Together with Just-in-time permission setting and Azure Key Vault, your migration is secure from source to target. Besides the existing general available capability to migrate from an on-premises NFS share to an Azure blob container, Storage Mover will support many additional source and target combinations in the near future.Cloud Native Identity with Azure Files: Entra-only Secure Access for the Modern Enterprise
Azure Files introduces Entra only identities authentication for SMB shares, enabling cloud-only identity management without reliance on on-premises Active Directory. This advancement supports secure, seamless access to file shares from anywhere, streamlining cloud migration and modernization, and reducing operational complexity and costs.
Azure Files provisioned v2 billing model for flexibility, cost savings, and predictability
We are excited to announce the general availability of the Azure Files provisioned v2 billing model for the HDD (standard) media tier. Provisioned v2 offers a provisioned billing model, meaning that you pay for what you provision, which enables you to flexibly provision storage, IOPS, and throughput. This allows you to migrate your general-purpose workloads to Azure at the best price and performance, but without sacrificing price predictability. With provisioned v2, you have granular control to scale your file share alongside your workload needs – whether you are connecting from a remote client, in hybrid mode with Azure File Sync, or running an application in Azure. The provisioned v2 model enables you to dynamically scale up or down your application’s performance as needed, without downtime. Provisioned v2 file shares can span from 32 GiB to 256 TiB in size, with up to 50,000 IOPS and 5 GiB/sec throughput, providing the flexibility to handle both small and large workloads. If you’re an existing user of Azure Files, you may be familiar with the current “pay-as-you-go” model for the HDD (standard) media tier. While conceptually, this model is simple – you pay for the storage and transactions used – usage-based pricing can be incredibly challenging to understand and use because it’s very difficult or impossible to accurately predict the usage on a file share. Without knowing how much usage you will drive, especially in terms of transactions, you can’t make accurate predictions about your Azure Files bill ahead of time, making planning and budgeting difficult. The provisioned v2 model solves all these problems – and more! Increased scale and performance In addition to the usability improvements of a provisioned model, we have significantly increased the limits over the current “pay-as-you-go” model: Quantity HDD pay-as-you-go HDD provisioned v2 Maximum share size 100 TiB (102,400 GiB) 256 TiB (262,144 GiB) Maximum share IOPS 40,000 IOPS (recently increased from 20,000 IOPS) 50,000 IOPS Maximum share throughput Variable based on region, split between ingress/egress. 5 GiB / sec (symmetric throughput) The larger limits offered on the HDD media tier in the provisioned v2 model mean that as your storage requirements grow, your file share can keep pace without the need to resort to unnatural workarounds such as sharding, allowing you to keep your data in logical file shares that make sense for your organization. Per share monitoring Since provisioning decisions are made on the file share level, in the provisioned v2 model, we’ve brought the granularity of monitoring down to the file share level. This is a significant improvement over pay-as-you-go file shares, which can only be monitored at the storage account level. To help you monitor the usage of storage, IOPS, and throughput against the provisioned limits of the file share, we’ve added the following new metrics: Transactions by Max IOPS, which provides the maximum IOPS used over the indicated time granularity. Bandwidth by Max MiB/sec, which provides the maximum throughput in MiB/sec used over the indicated time granularity. File Share Provisioned IOPS, which tracks the provisioned IOPS of the share on an hourly basis. File Share Provisioned Bandwidth MiB/s, which tracks the provisioned throughput of the share on an hourly basis. Burst Credits for IOPS, which helps you track your IOPS usage against bursting. To use the metrics, navigate to the specific file share in the Portal, and select “Monitoring > Metrics”. Select the metric you want, in this case, “Transactions by Max IOPS”, and ensure that the usage is filtered to the specific file share you want to examine. How to get access to the provisioned v2 billing model? The provisioned v2 model is generally available now, at the time of writing, in a limited set of regions. When you create a storage account in a region that has been enabled for provisioned v2, you can create a provisioned v2 account by selecting “Standard” for Performance, and “Provisioned v2” for File share billing. See how to create a file share for more information. When creating a share in a provisioned v2 storage account, you can specify the capacity and use the recommended performance. The recommendations we provide for IOPS and throughput are based on common usage patterns. If you know your workloads performance needs, you can manually set the IOPS and throughput to further tune your share. As you use your share, you may find that your usage pattern changes or that your usage is more or less active than your initial provisioning. You can always increase your storage, IOPS and throughput provisioning to right size for growth and you can also decrease any provisioned quantity after 24 hours have elapsed since your last increase. Storage, IOPS, and throughput changes are effective within a few minutes after a provisioning change. In addition to your baseline provisioned IOPS, we provide credit-based IOPS bursting that enables you to burst up to 3X the amount of provisioned IOPS for up to 1 hour, or as long as credits remain. To learn more about credit-based IOPS bursting, see provisioned v2 bursting. Pricing example To see the new provisioned v2 model in action, let’s compare the costs of the pay-as-you-go model versus the provisioned v2 model for the following Azure File Sync deployment: Storage: 50 used TiB For the pay as we go model, we need usage as expressed in the total number of “transaction buckets” for the month: Write: 3,214 List: 7,706 Read: 7,242 Other: 90 For the provisioned v2 model, we need usage as expressed as the maximum IOPS and throughput (in MiB / sec) hit over the course of an average time period to guide our provisioning decision: Maximum IOPS: 2,100 IOPS Maximum throughput: 85 MiB / sec To deploy a file share using the pay-as-you-go model, you need to pick an access tier to store the data in between transaction optimized, hot, and cool. The correct access tier to pick depends on the activity level of your data: a really active share should pick transaction optimized, while a comparatively inactive share should pick cool. Based on the activity level of this share as described above, cool is the best choice. When you deploy the share, you need to provision more than you use today to ensure the share can support your application as your data continues to grow. Ultimately this how much to provision is up to you, but a good rule of thumb is to start with 2X more than what you use today. There’s no need to keep your share at a consistent provisioned to used ratio. Now we have all the necessary inputs to compare cost: HDD pay-as-you-go cool (cool access tier) HDD provisioned v2 Cost components Used storage: 51,200 GiB * $0.015 / GiB = $768.00 Write TX: 3,214 * $0.1300 / bucket = $417.82 List TX: 7,706 * $0.0650 / bucket = $500.89 Read TX: 7,242 * $0.0130 / bucket = $94.15 Other TX: 90 * $0.0052 / bucket = $0.47 Provisioned storage: 51,200 used GiB * 2 * $0.0073 / GiB = $747.52 Provisioned IOPS: 2,100 IOPS * 2 * $0.402 / IO / sec = $168.84 Provisioned throughput: 85 MiB / sec * 2 * $0.0599 / MiB / sec = $10.18 Total cost $1,781.33 / month $926.54 / month Effective price per used GiB $0.0348 / used GiB $0.0181 / used GiB In this example, the pay-as-you-go file share costs $0.0348 / used GiB while the provisioned v2 file share costs $0.0181 / used GiB, a ~2X cost improvement for provisioned v2 over pay-as-you-go. Shares with different levels of activity will have different results – your mileage may vary. Typically, when deploying a file share for the first time, you would not know what the transaction usage would be, making cost projections for the pay-as-you-go model quite difficult. But it would still be straightforward to compute the provisioned v2 costs. If you don’t know specifically what your IOPS and throughput utilization would be, you can use the built-in recommendations as a starting point. Resources Here are some additional resources on how to get started: Azure Files pricing page Understanding the Azure Files provisioned v2 model | Microsoft Docs How to create an Azure file share | Microsoft Docs (follow the steps for creating a provisioned v2 storage account/file share)Azure File share NFS Snapshots is now Public Preview!!
Azure Files is a fully managed cloud file share service that enables organizations to share data across on-premises and cloud. The service is truly cross-platform and supports mounting of file share from any client that implements SMB and NFS protocols, it also exposes REST APIs for programmability. A key part file share service offering is its integrated backup for point in time recovery, this enables recovery of data from certain periods in the past in case data is deleted or corrupted. Such capability is best offered by Snapshots. We are excited to announce public preview of Snapshot support for NFS share. Customers using NFS shares will now be able to perform share level Snapshot management operations via REST API, PowerShell and CLI. Using Snapshots users will be able to roll back the entire filesystems or pull specific files that were accidentally deleted or corrupted. Therefore, it is always recommended to create a snapshot schedule that best suits your RPO (recovery point objective) requirement. Snapshot schedule frequency can be hourly, daily, weekly or monthly. Having such flexibility will help IT infra teams to serve a wide spectrum of RPO requirements suiting business needs. Although there are multiple scenarios where snapshots can benefit users, I will be highlighting two important scenarios that are widely sought after. Scenario #1 Recover files in case of accidental deletions, corruption, or user errors. Scenario #2 Start-up read only replica of your application or database in few minutes to serve your reporting or analytics scenarios. Scenario #1 Recovery of data during accidental deletions and corruption is the most common scenario for admins during their day-to-day operations. There are solutions like backup (creating full and incremental copies of data) that help to recover the data from such scenarios, but snapshot technology offers more frequent recovery points (Lower RPO) to restore the data unlike backups. Snapshots are also considered to be space efficient since they capture only incremental changes. Creating snapshots of NFS file share is straightforward. This can be accomplished via Portal, REST, PowerShell or CLI. Let me show you how to access file share snapshots via NFS client to perform single file restore operations which can help you to recover data in accidental deletions or corruption scenarios. The first step is to mount the file share : cd “.snapshots” directory under root to view the snapshots that are already created. “.snapshot” directory is by default hidden but users will be able to access and read from the directory like a normal directory Each snapshot available/listed under .snapshot directory is a recovery point in itself. cd into the specific snapshot to view the files to be recovered. Initiate copy of required files and directories from snapshot to the desired location to complete the restore using cp command. Scenario #2 If you have an application or a database deployed on a NFS file share, one can create crash consistent or application consistent snapshot of NFS file share. Crash consistent is offered by default but Application consistent snapshots are not built-in capability, it will require admins to run few additional steps which can quiesce and unquiesce the application during snapshot creation process. For example, if you have a MySQL database one can write script to a execute a 3-step (quiesce(MySQL), snapshot(File share), and unquiesce(MySQL)) process to create an application-consistent snapshot of the database hosted on file share. Quiesce and unquiesce commands varies depending on the application or the database hosted on the file share. Such application consistent snapshots can be directly mounted on the desired NFS client and can be used as read only replicas for reporting and data analytics use-cases. The mounted snapshots can be used by applications or databases to create read-only static copies of the production database for analytics or reporting use-cases. They can be also copied to another location and then applications can be allowed to perform changes/writes. To improve copy performance, especially for large datasets with multiple files mount NFS snapshot using Nconnect setting which is available on latest Linux distributions and use fpsync to copy data out of snapshot to desired location. Sample scripts updated here For more information refer to documentation Mount an NFS Azure file share on Linux | Microsoft Learn Snapshot Share (FileREST API) - Azure Files | Microsoft Learn
