Azure Files: SMB, NFS, and Choosing a Share Tier

Azure Files is a fully managed file share service. A PaaS offering with no VMs, no operating systems, and no patching, providing a familiar file server experience with persistent storage over SMB, NFS, and REST. Multiple machines can mount the same share with read and write access, which makes it the obvious landing place for shared configuration, tooling, diagnostic logs, and anything an on-premises application already expects to find on a file share.

It's also the part of Azure Storage that has changed most since most training material was written, so it's worth starting with what a file share actually is now.

Two management models

Classic file shares (Microsoft.Storage) are shares deployed inside a storage account. They support everything Azure Files does: SMB and NFS, both media tiers, every redundancy type, and availability in every region. Their limitations are structural:

• Capacity planning. Every share in an account — along with blob containers in the same account — shares one pool of storage, IOPS, and throughput. Placing several shares in one account means planning for all of them together, because one share's growth can crowd out the others.
• Shared settings. Network and security rules apply at the account level. Treat the storage account as a trust boundary and only co-locate shares you're happy giving identical security settings.
• Scaling complexity. Large deployments can require managing multiple subscriptions to work around storage account limits.

File shares (Microsoft.FileShares) are a newer top-level Azure resource that needs no storage account at all. Each share is created directly in a resource group, gets its own dedicated storage, IOPS, and throughput, and carries its own networking and security configuration. That removes the capacity-planning and trust-boundary problems in one step.

The catch is coverage. Microsoft.FileShares is currently NFS only — if you need SMB, you need classic shares. It also doesn't support Azure File Sync, soft delete, customer-managed keys, data-plane REST APIs, the AKS CSI driver, or GRS and GZRS redundancy.

Microsoft's guidance is to evaluate the new experience for new NFS deployments, and use classic shares where a required feature isn't there yet or the workload needs SMB.

Media tiers

Azure Files offers two media tiers:

Training material commonly describes four tiers — Premium, Transaction optimised, Hot, and Cool. That framing is out of date. Those labels belonged to the standard tier under the pay-as-you-go billing model, and they no longer describe how a share is configured. The current model is two media tiers crossed with three billing models.

Billing models

• Provisioned v2: provision storage, IOPS, and throughput separately, and pay for what you provision regardless of use. Use this for all new deployments. The portal recommends IOPS and throughput based on the storage you specify, and you can override in either direction.
• Provisioned v1: provision storage; IOPS and throughput are derived from it in a fixed ratio, the way on-premises storage is bought. SSD only. Supports credit-based bursting for free and optional paid bursting.
• Pay-as-you-go: usage-based, billed on used storage, transactions, and data transfer.

Classic shares use one of two storage account kinds: provisioned accounts (the FileStorage kind, which holds only file shares) or pay-as-you-go accounts (StorageV2, which can also hold blobs, queues, and tables).

A share can't be moved between media tiers after creation. Migrating from HDD to SSD means creating a new share and copying the data across, worth knowing before defaulting to the cheaper option.

Redundancy

HDD file shares support all four redundancy types LRS, ZRS, GRS, and GZRS.
SSD file shares support only LRS and ZRS, with zone redundancy available in a subset of regions.

One caveat catches people out. You can provision a file share in an RA-GRS or RA-GZRS account, but Azure Files doesn't support reading from the secondary region. The share works, and it's billed as geo-redundant or geo-zone-redundant respectively — you simply don't get the read-access half you're conceptually paying for. If read access to a secondary is the requirement, Azure Files isn't the service that delivers it.

Protocols

A single file share can't serve both SMB and NFS. You can create SMB and NFS shares side by side in the same storage account, but not one share speaking both. That, plus NFS being SSD-only and unavailable over the internet, usually settles the protocol decision before preference does.

When Azure Files isn't the answer

Two other services cover adjacent ground, and the boundaries between them are worth knowing before defaulting to Files.

The shape of it: Blob for sequential throughput, Files for random access at moderate scale, and NetApp Files when you need genuine enterprise NAS behaviour — simultaneous multi-protocol access, very low latency, or advanced data management — and are willing to pay for it.

Networking and port 445

Port 445 must be open for SMB, and it's routinely blocked outbound by ISPs and corporate networks. That single fact is the most common reason a mount fails from on-premises, and it isn't something you can fix from the Azure side.

The supported approach for on-premises SMB access is a VPN or ExpressRoute connection with the share exposed through a private endpoint. NFS shares rely on network-level authentication and are only reachable over restricted networks, so they always need some network configuration and a service endpoint or a private endpoint. Where a static IP or high availability is needed, use a private endpoint: with service endpoints, a rare event such as a zone outage can change the storage account's underlying IP, and while the data stays available, clients need to remount.

If both the client and the share are in Azure and the protocol is SMB, no special configuration is required at all.

Large file shares

Shares up to 100 TiB need the account enabled for large file shares and the share quota raised:

Set-AzStorageAccount -ResourceGroupName RG1 -Name storage1 -EnableLargeFileShare
Update-AzRmStorageShare -ResourceGroupName RG1 -StorageAccountName storage1 -Name share1 -QuotaGiB 102400

Encryption in transit

Encryption in transit is enabled by default on all storage accounts, meaning Azure Files only accepts SMB 3.x with encryption or HTTPS. Clients that can't do SMB 3.x with encryption simply can't mount the share.

Disabling it also permits SMB 2.1, unencrypted SMB 3.x, and unencrypted REST over HTTP. The only good reason is a legacy operating system that can't do better — and note that SMB 2.1 connections are only accepted from within the same Azure region as the share, so an on-premises client can't fall back to it anyway.

At rest, Azure Files uses the same service-side encryption as the rest of Azure Storage, applying to both SMB and NFS. Classic shares support customer-managed keys; shares created through Microsoft.FileShares must use Microsoft-managed keys.

What it's good for

• Migrating on-premises applications that already use file shares. Mount the share to the same drive letter the application expects and it often needs no change at all.
• Sharing configuration files across virtual machines.
• Giving a team of developers one copy of shared tooling, so everyone finds the same version.
• Collecting diagnostic logs, metrics, and crash dumps for later analysis.
• Replacing or supplementing on-premises NAS devices and file servers.

Identity-based access, share snapshots, and soft delete are the other half of running a share in production, and are covered in the post on Azure Files access control and snapshots.

Sources

• Plan for an Azure Files deployment — Azure Storage | Microsoft Learn
• Understand Azure Files billing — Azure Storage | Microsoft Learn
• Azure Files networking considerations — Azure Storage | Microsoft Learn