Every few years a client asks me whether Azure Files can finally replace their on-premises file server, and for most of a decade my answer carried enough caveats to sound like a no. The caveats are mostly gone now. This series is the current answer, including the parts Microsoft’s marketing will not tell you and the parts most blog posts are still getting wrong.
What Azure Files actually is
Azure Files is a fully managed file share service inside Azure Storage. You create a share, and Azure serves it over the same SMB protocol your Windows file server speaks today, plus NFS 4.1 for Linux estates and an HTTPS REST surface for tooling. There is no operating system underneath it that you patch, no cluster you nurse, no disk you replace. The share presents real NTFS-style ACLs, real Kerberos authentication, previous versions for end users, and a UNC path that mounts as a drive letter. From the desk of the person double-clicking a spreadsheet, it behaves like the F: drive always has.
The vocabulary changed recently, and it matters because most written guidance still uses the old words. Microsoft no longer frames the product as premium versus standard tiers. The current model is a media tier, SSD or HDD, crossed with a billing model: provisioned v2, provisioned v1, or pay-as-you-go. Provisioned v2 is the recommended model for every new deployment, and it is the first version of Azure Files billing I am willing to defend to a CFO, because you provision storage, IOPS, and throughput as three independent dials and pay a predictable hourly rate for each. The older pay-as-you-go model billed per transaction, which is the origin of every “our Azure Files bill tripled overnight” story you have read. Those stories were real. They are also describing a billing model you should no longer choose.
Scale is no longer the objection either. A single provisioned v2 share runs to 256 TiB, 4 TiB per file, and on SSD media up to 102,400 IOPS with sub-two-millisecond latency in region. The constraint that actually bites in production is not capacity; it is the handle limits, 10,000 concurrent handles on a share root, which is a sizing input for profile-container workloads and almost nothing else.
Why everything you have read about it is stale
Three changes landed between late 2024 and mid 2026 that invalidate most of the written record on this product.
The first is identity, and it is the big one. On May 19, 2026, Microsoft shipped general availability of Entra-only identity for SMB shares. Before that date, Kerberos authentication to Azure Files required Active Directory somewhere in the loop: either the storage account was domain-joined to your AD, or your users were hybrid identities synced from AD into Entra ID. A cloud-native organization, the kind with Entra-joined laptops and no domain controllers, simply could not give its users identity-based access to an Azure file share. That rule is dead. Entra ID now issues the Kerberos tickets itself, cloud-only users and groups go straight into NTFS ACLs, and you can edit those ACLs from the Azure portal. A company with zero servers can now run a real SMB file share with real per-folder permissions. Nearly every article, forum answer, and training course on the internet still says this is impossible. It is not, and the gap between what is written and what is true is the reason this series exists.
The second is billing, covered above: provisioned v2 replaced the transaction lottery with dials you set on purpose.
The third is security posture. New storage accounts created in the portal now require encryption in transit for SMB by default, which quietly answers half of the port 445 panic, and vaulted backup went GA, which gives file shares a true offsite copy in a Backup vault rather than snapshots living next to the data they protect.
The question is no longer whether Azure Files can replace a file server. It is which of three postures fits your estate, and whether you are honest about the features you are giving up.
The three postures this series defends
I deploy Azure Files in one of three shapes, and the whole series hangs off this choice.
The first posture is the direct cloud mount. Devices talk SMB straight to the share, authentication is Entra Kerberos, and there is no server in the middle. This is the right shape for cloud-native estates: Entra-joined Windows 11 fleets, no domain controllers, users spread across offices and homes. The design work lives in two decisions, which identity source you enable and which network path carries port 445, and those two decisions get a full article each.
The second posture is the cached server. Azure File Sync keeps a Windows Server, often the one you already own, as a local cache of the share. Users keep hitting the same UNC path over the LAN at LAN speed, and the cloud share becomes the authoritative copy behind it. This is the right shape for hybrid estates, for branch offices, and for any workload where WAN latency to the share would be felt in Explorer. It is also the honest answer to several feature gaps, because a Windows Server in the path gives you back auditing, access-based enumeration, and a place for the tools that expect a server.
The third posture is not deploying Azure Files, and I mean that seriously. Some workloads do not belong here: applications that need alternate data streams or hard links, media pipelines that want more than 4 TiB per file, estates that require security auditing at the file level with no server in the path, latency-sensitive applications that will feel every WAN round trip. For those, the answer is Azure NetApp Files, a file server VM, or in the common case where the data is actually collaborative documents, SharePoint. The capstone article gives you the decision framework; I will not pretend every share belongs in this product.
What I am not going to hide
Because the rest of the series argues that Azure Files is ready, I want the limitations on the table in the first article. There is no multifactor authentication on the SMB flow itself; Conditional Access cannot gate the Kerberos ticket a device presents to the share, and the storage account’s app must be excluded from MFA policies for mounts to work. If MFA must sit in front of file access, it lives at the network layer, and there is an article on exactly that. Access-based enumeration does not work on direct mounts, so users see folder names they cannot open. There is no file-level security auditing without a server in the path. SSD shares have no geo-redundancy. Azure File Sync does not lock files across sites. None of these killed a deployment I have run, but every one of them has surprised someone who was not told.
Where the series goes from here
The next article is a build sheet that takes you from nothing to a mounted drive in under an hour, because I think you should touch the product before you read another five thousand words of my opinions about it. After that: identity in full, the port 445 question and the three ways to carry SMB traffic safely, what provisioned v2 actually costs, Azure File Sync as the hybrid cache, migration off your existing file server at both enterprise and small-shop scale, the operational layer of backup and monitoring and disaster recovery, and finally the decision framework that ties it together. Build sheets sit under the doctrine articles throughout, so every argument I make comes with the steps to reproduce it.
Azure Files
Next: [AF 1.1] Build Sheet: Your First Azure File Share ›
