Microsoft.FileShares (Preview): NFS File Shares Without the Storage Account Hassle#

Microsoft has introduced Microsoft.FileShares (preview), a new way to deliver NFS-based Azure file shares without relying on a storage account. Instead of being tucked inside a storage account that pools IOPS, throughput, and capacity, each share is now its own top-level resource. That means simpler management, cleaner billing, and more predictable scaling.

This new model uses the provisioned v2 billing structure. You specify exactly how much SSD storage, IOPS, and throughput you want. Azure suggests reasonable defaults, but you can override them to fine-tune for your workload. At launch, the focus is on NFS over premium SSDs. SMB and HDD remain part of the classic storage-account-based shares, so this is aimed at high-performance Linux workloads.

Provisioning speed is a standout feature. Creating a share is roughly twice as fast as with traditional methods. Each subscription can host up to 1,000 shares per region during preview, with limits expected to increase as the service matures. You also get flexible redundancy options with both locally redundant and zone-redundant storage.

Creating a File Share in the Portal#

Creating a file share in the portal is straightforward:

  1. Pick a unique name.
  2. Choose SSD as the media tier.
  3. Set NFS as the protocol.
  4. Select your region.
  5. Provision capacity between 32 GiB and 262,144 GiB.
  6. Decide on redundancy (LRS or ZRS).
  7. Configure IOPS and throughput (use defaults or customize).
  8. Optionally configure root squash behavior and a custom mount name.
  9. Configure networking with private endpoints or service endpoints.

Hit Review + Create, and deployment is complete in seconds.

Infrastructure as Code#

For Infrastructure as Code, support is already available in Bicep, ARM templates, and Terraform (via AzAPI). A simple resource definition lets you specify media tier, protocol, capacity, IOPS, throughput, redundancy, root squash mode, allowed subnets, and tags. Everything is designed for modular, per-share configuration without the baggage of a storage account.
Infrastructure as Code (Bicep / ARM / Terraform)

If you live in IaC land, here’s the template snippet (via API version 2025-06-01-preview):

resource fs 'Microsoft.FileShares/fileShares@2025-06-01-preview' =
{

  name: 'myShare'
  location: '<region>'
  properties: {
    mediaTier: 'SSD'
    protocol: 'NFS'
    provisionedStorageGiB: <size>
    provisionedIOPerSec: <iops> 
    provisionedThroughputMiBPerSec: <throughput>
    redundancy: 'Local' // or 'Zone'
    nfsProtocolProperties: {
      rootSquash: 'RootSquash'
    }
    publicAccessProperties: {
      allowedSubnets: [ '<subnetResourceID>' ]
    }
    publicNetworkAccess: 'Enabled' // or 'Disabled'
  }
  tags: {
    project: 'myProject'
  }
}

Why This Matters#

Benefit Why It Matters
Simplicity One resource per share instead of juggling shared storage accounts.
Predictable billing Tag and track costs per team or workload.
Performance control Fine-tune IOPS and throughput for each workload.
Faster deployments Provisioning is about twice as fast as classic file shares.
Scale-friendly Up to 1,000 shares per subscription per region, with growth ahead.
Security-ready Built-in networking with private endpoints or subnet restrictions.

Limitations to Keep in Mind#

  • NFS only, for now. SMB remains with classic file shares.
  • Premium SSDs only; no HDD tier yet.
  • Some integrations like snapshots and backup may not be available during preview.
  • Current limit of 1,000 shares per subscription per region, expected to rise later.

Final Thoughts#

Microsoft.FileShares (preview) eliminates the storage account overhead for NFS shares, offers fine-tuned provisioning, speeds up deployments, and scales cleanly with modern infrastructure. For anyone building modular cloud environments, Kubernetes clusters, or team-specific app stacks, this is a big step toward simpler, faster, and more predictable file storage in Azure.