Before Azure, we need to understand the simple idea underneath: shared files in folders.

Files, folders and drives

A file is a named piece of stored information, such as a document, a photo, a spreadsheet or a configuration setting. Folders, also called directories, group files into a tree-like structure so people can find them: a folder named Finance may contain a folder named 2026, which contains a file named Budget. This familiar arrangement is called a hierarchical file system, and it is how almost every personal computer organises its storage.

Why sharing matters

On a single computer, files are stored on its own disk and only that computer can use them. In an organisation, many people and many programs need the same files at the same time. A design team edits the same project folders, a web application reads shared configuration, and a group of servers writes to a common logging location. A file share solves this by making a folder on one machine available over the network, so that many other machines can open it as if it were local.

The traditional file server

For decades, companies ran file servers: physical or virtual computers whose main job was to hold shared folders. These servers needed hardware purchases, operating system updates, antivirus software, backups, disk replacements and capacity planning. When they filled up, someone bought more disks. When they broke, work stopped. A branch office often needed its own server, multiplying the effort.

Fully managed file shares in the cloud, reachable using standard file-sharing protocols.

The definition

Azure Files is a Microsoft Azure service that offers fully managed file shares in the cloud. Fully managed means Microsoft operates the underlying servers, disks and software, and you simply create shares, set their size and decide who may use them. The shares can be accessed using industry-standard protocols, which means that ordinary Windows, Linux and macOS machines, and many applications, can use them without special software or code changes.

Where it sits in Azure’s storage family

Azure Files is one of several services under the Azure Storage umbrella. Each is designed for a different style of data.

What makes it attractive

A small set of nested resources explains how everything is organised.

The hierarchy

Everything in Azure Files lives inside a storage account, which is a top-level container that holds your storage services and defines key settings such as region, performance type and redundancy. Inside a storage account you create file shares. Each file share holds directories, which hold more directories and files. The share is the unit you mount, size, protect with snapshots and assign permissions to.

flowchart TD
  SUB[Subscription] --> RG[Resource Group]
  RG --> SA[Storage Account]
  SA --> FS1[File Share: Finance]
  SA --> FS2[File Share: Engineering]
  FS1 --> D1[Directory: 2026]
  FS1 --> D2[Directory: Archive]
  D1 --> F1[File: Budget]
  D1 --> F2[File: Forecast]
        

Shares as boundaries

Because performance, snapshots, quotas and permissions are applied per share, how you divide data into shares is a design decision. Putting every team in one huge share is simple but makes permission management and performance isolation harder. Giving each department or application its own share creates cleaner boundaries, as long as you do not create so many that management becomes tedious.

A protocol is a language. Azure Files speaks the main languages that operating systems already understand.

SMB

Server Message Block, known as SMB, is the file-sharing protocol native to Windows and widely supported on Linux and macOS. When you map a network drive on a Windows computer, you are almost certainly using SMB. Azure Files supports modern versions of SMB, including the SMB 3 family, which adds important features such as encryption of data in transit and resilience to brief network interruptions. SMB shares are the most common choice for Windows-centred environments, user home folders and general business shares.

NFS

Network File System, known as NFS, is the file-sharing protocol that originated in the Unix world and is the natural choice for Linux and many container and high-performance applications. Azure Files supports NFS version 4.1 for shares of the premium type, within certain constraints. NFS shares use Linux-style permissions and are well suited to Linux applications that expect a POSIX-like file system, meaning one that follows common Unix rules for ownership and permissions.

REST

Azure Files can also be accessed through a REST interface, which means web-style requests over HTTPS. This allows applications and tools to create, read and manage files without mounting a drive, and it underpins many management features, automation and tools. It is mostly used by developers and administrators rather than ordinary users.

The kind of storage account decides speed, features and price. This is the biggest early decision.

Standard and premium

Azure Files shares come in two broad performance classes. Standard shares run on hard-disk-based hardware, offering good value for general-purpose use, with performance that is adequate rather than extreme. Premium shares run on solid-state drives, providing low delay and high, predictable performance for workloads that are sensitive to speed, such as databases, development environments and busy application shares.

The account kinds behind them

HDD versus SSD at a glance

Share size limits

Modern Azure Files shares can grow very large, with limits that are measured in tens of tebibytes up to around one hundred tebibytes per share in current documentation. A tebibyte is roughly a thousand gigabytes. Limits for each share, each account and each file can change, so always check Microsoft’s current limits when designing for very large datasets.

Storage can be cheap to hold but costly to touch, or the reverse. Tiers let you choose the balance.

Tiers for standard shares

Standard file shares offer several access tiers that trade storage price against the cost of accessing the data. These apply per share and can be changed over time as usage patterns change.

What decides performance

Performance is measured in three ways. IOPS means input and output operations per second, how many individual reads and writes can be handled. Throughput is how many megabytes per second can flow. Latency is the delay before a response begins. Standard shares offer limits that apply per share and account, and premium shares provide IOPS and throughput that scale with the capacity you provision, with burst allowances for short spikes.

Factors beyond the share

Disks fail and data centres sometimes lose power. Redundancy is how copies keep your files safe.

Why copies matter

Azure Files stores multiple copies of your data. The question is how far apart the copies are kept. More distance means greater protection against large disasters, but usually higher cost and, for some options, a delay before copies are fully in sync. This choice is called the redundancy option and is set on the storage account.

The main options

Availability of each option depends on the account type and region. Premium shares typically offer LRS and ZRS, while standard shares offer the full range, and some options are unavailable in some regions. Check current documentation for your region.

flowchart TD
  U[Writes to a share] --> P[Primary Region]
  P --> Z1[Copy in Zone 1]
  P --> Z2[Copy in Zone 2]
  P --> Z3[Copy in Zone 3]
  P -.asynchronous copy.-> S[Paired Secondary Region]
  S --> L[Local copies in secondary]
        

Failover and its limits

With geo redundancy, the copy in the secondary region is made asynchronously, meaning a short time after the write in the primary region. If the primary region fails and a failover is performed, the most recent changes that had not yet been copied could be lost. The measurement of this window is called the recovery point objective. Failover is a significant event and normally a deliberate decision, not an automatic switch for ordinary failures.

A share only helps when people and programs can actually reach it.

Mounting on different systems

Once a share exists, a computer connects to it by mounting. On Windows, users can map the share as a drive letter or connect through a network path. On Linux, an administrator mounts the share to a folder using the operating system’s file-system tools, and can make the mount permanent through configuration so it returns after a restart. On macOS, users connect through the file-sharing option in the system’s file manager. Azure provides ready-made connection instructions for each system in the portal.

Where clients can be

The port 445 problem

SMB uses a network port numbered 445. Many internet providers and corporate firewalls block this port outbound because of its history with security problems. As a result, mounting an SMB share directly over the public internet often fails from home networks or hotels. The usual remedies are to connect through a VPN or private circuit so that traffic travels on a secure private route, to use private endpoints, or, where available, to use SMB over QUIC, an option that carries SMB over a more internet-friendly secure transport. Check current documentation for supported configurations.

Deciding who may open which folder is where most real security work happens.

Two ways to authenticate with SMB

Identity sources

Identity-based access with SMB can use on-premises Active Directory Domain Services, Microsoft Entra Domain Services, or Microsoft Entra Kerberos for hybrid identities, which lets users who exist in the cloud directory and in on-premises directories use their familiar sign-in, including for machines that are joined to Entra ID, depending on configuration. Which one fits depends on where your users and computers are managed. The setup requires planning because the storage account must be registered with the identity system.

Two layers of permission

Both layers apply. A user must be allowed through the share-level door and also be permitted by the folder-level permissions. The most restrictive result wins, so a mistake at either layer can block access.

NFS security

NFS shares use a different model. They do not authenticate individual users through the cloud identity system in the way SMB does. Instead, access is mostly controlled at the network level, by restricting which networks, virtual networks and endpoints may reach the share, and by Linux-style user and group identifiers and permissions on files. This makes network design and private endpoints especially important for NFS.

A strong lock on the door is useful, but it is better still if the door is not on a public street.

The default: a public endpoint

By default, a storage account has a public endpoint, an internet-reachable address. Access still requires authentication, but the address itself can be reached from anywhere unless you restrict it. For many organisations that is more exposure than necessary.

Ways to restrict access

Connecting from on-premises

On-premises networks reach private endpoints through a VPN gateway or a private dedicated circuit between the office and Azure. Name resolution must also be arranged so that the storage account’s name resolves to the private address from the office network, which is a frequently overlooked step and a common source of confusing failures.

flowchart LR
  OFF[Office Network] -->|VPN or private circuit| VNET[Azure Virtual Network]
  VM[Azure VMs] --> VNET
  VNET --> PE[Private Endpoint]
  PE --> SA[Storage Account with Azure Files]
  INET[Public Internet] -.blocked by firewall.-> SA
        

Encryption turns stored data into unreadable text for anyone without the key.

Encryption at rest

All data stored in Azure Files is encrypted at rest by default, meaning it is scrambled on the physical disks using strong encryption. This happens automatically, with no setup, and Microsoft manages the keys unless you choose otherwise. If someone were to obtain a physical disk, the data on it would be unreadable.

Customer-managed keys

Some organisations must control their own encryption keys for regulatory or policy reasons. Azure Files supports customer-managed keys held in Azure Key Vault. You decide who may use the key, can rotate it and can revoke it, which would make the data unreadable. This brings extra responsibility: if the key is lost or deleted incorrectly, the data may be unrecoverable, so key protection and recovery settings need careful attention.

Encryption in transit

Data moving between clients and the service is protected by encryption when secure transfer is enabled. SMB 3 encrypts the connection itself, and REST traffic uses HTTPS. Requiring this setting stops older, unencrypted connection types and guards against eavesdropping on the network path. NFS shares have different transit-security considerations, which is why private networking matters for them.

Redundancy protects against hardware loss. These features protect against human error and attack.

Share snapshots

A share snapshot is a read-only copy of a share at a specific moment. Snapshots are incremental, meaning each one stores only what changed since the previous snapshot, so they are space-efficient. Users can browse a snapshot and copy back an earlier version of a file they accidentally deleted or overwrote. There is a limit on how many snapshots a share can keep, so a retention schedule is needed to prune old ones.

Soft delete

Soft delete protects against accidental deletion of an entire share. When it is on, a deleted share is not removed at once. It is kept in a deleted state for a configurable retention period during which it can be restored. This is a simple, valuable safety net, and it is typically enabled by default, though you should verify the setting and retention period for your accounts.

Azure Backup for file shares

Azure Backup can protect file shares by scheduling snapshots and managing their retention centrally through a vault, with policies describing frequency and duration, such as daily copies for a month and monthly copies for a year. Backup integrates with soft delete features to resist deliberate deletion by an attacker, and restore options include recovering a whole share or individual files and folders, either in place or to a different location.

flowchart TD
  FS[Production File Share] --> RED[Redundancy: LRS ZRS GRS GZRS]
  FS --> SNAP[Share Snapshots]
  FS --> SD[Soft Delete]
  FS --> AB[Azure Backup Vault]
  RED -->|hardware failure| OK1[Data survives]
  SNAP -->|overwritten file| OK2[Restore earlier version]
  SD -->|deleted share| OK3[Undelete within retention]
  AB -->|ransomware or long term| OK4[Restore from backup]
        

Many organisations cannot move every file server to the cloud overnight. Azure File Sync bridges the gap.

The problem it solves

Offices often have Windows file servers whose users depend on fast local access. Moving everything straight to a cloud share could mean slower access across the internet, especially for large files or branch offices with limited bandwidth. At the same time, those servers need backup, disaster recovery and growth, which the cloud does well. File Sync lets you keep the local server while using Azure Files as the central, always-protected copy.

The building blocks

flowchart TD
  SSS[Storage Sync Service] --> SG[Sync Group]
  SG --> CE[Cloud Endpoint: Azure File Share]
  SG --> SE1[Server Endpoint: Head Office Server]
  SG --> SE2[Server Endpoint: Branch Office Server]
  SE1 |sync| CE
  SE2 |sync| CE
        

Cloud tiering

Cloud tiering is the feature that makes File Sync especially valuable. When the local server runs short of space, rarely used files are replaced locally by small placeholders, called stubs, while the full content stays in Azure. A user still sees the file in the folder. When they open it, the content is fetched from Azure on demand. Frequently used files stay local for speed. This allows a modestly sized server to present a share far larger than its own disks.

Benefits in practice

Patterns become clearer when you see where Azure Files is actually used.

Less suitable uses

Be cautious using file shares as the storage for heavy transactional databases, where managed disks or dedicated database services give better performance and consistency. Be cautious too when many users edit the same large file concurrently over slow links. And for web-scale delivery of images and videos to the public, blob storage with a content delivery network is generally the better fit.

Several Azure services can store files. Choosing among them prevents mismatched designs.

Rules of thumb

Understanding what you pay for turns a flexible service into a predictable bill. Exact prices change and vary by region, so check the current Azure pricing pages.

What contributes to the bill

Provisioned versus pay-as-you-go thinking

Premium shares are billed on what you provision, which makes cost predictable but means you pay for unused capacity. Standard shares have historically been billed mostly on what you actually use, with transaction charges depending on the tier. Microsoft has been evolving the billing models for standard shares, including options based on provisioned capacity with defined performance, so review the current model offered for your account and compare it with your usage.

Optimisation habits

You cannot fix what you cannot see. Good monitoring turns mysterious slowness into a diagnosed cause.

What to watch

Tools

Azure Monitor provides metrics for storage accounts and file shares, and diagnostic settings can send detailed logs to a Log Analytics workspace or storage for analysis, where a query language lets you examine who accessed what and when. Alerts can warn of high latency, throttling or capacity limits. Microsoft Defender for Storage can help detect suspicious activity, such as unusual access or possible malware uploads.

A troubleshooting routine

Most real-world adoption begins with files that already exist somewhere else.

Common sources

Data may come from Windows file servers, Linux servers, network-attached storage appliances or other cloud services. Each source has its own considerations, particularly regarding permissions, file names and special attributes, which must carry across if users and applications are to behave the same after the move.

Migration paths

The migration journey

An honest view of both sides leads to better decisions.

When it is the right tool

Azure Files fits when you need shared folders accessible from many machines, particularly Windows environments, lift-and-shift applications, virtual desktop profiles, container storage and hybrid arrangements where local servers must sync with the cloud.

When it is not

Look elsewhere for massive object storage served through web addresses, ultra-low-latency transactional databases, or highly specialised enterprise storage features that demand a dedicated service. A single machine’s private fast storage is usually better provided by a managed disk.

Let us combine the ideas into one sensible design for a medium-sized company with an office, branches and virtual desktops.

Imagine a company with a head office, two branch offices and a set of virtual desktops. It needs department shares, user profile storage, protection against deletion and ransomware, private access and controlled cost. The design below shows how the pieces fit.

flowchart TD
  HO[Head Office Users] -->|VPN or private circuit| VNET[Azure Virtual Network]
  BR[Branch Servers with File Sync agent] -->|sync| SSS[Storage Sync Service]
  VDI[Virtual Desktops] --> VNET
  VNET --> PE[Private Endpoints]
  PE --> SA1[Standard Account GZRS: Department Shares]
  PE --> SA2[Premium Account ZRS: Profile Shares]
  SSS --> SA1
  IDP[Directory Identity] -.authenticates.-> SA1
  IDP -.authenticates.-> SA2
  BKP[Backup Vault] -.protects.-> SA1
  BKP -.protects.-> SA2
  MON[Azure Monitor and Log Analytics] -.collects.-> SA1
  MON -.collects.-> SA2
        

Walking through the design

Why this works

Every risk has a specific answer. Hardware and data centre failures are handled by redundancy, user errors by snapshots and soft delete, ransomware by isolated backup, interception by encryption and private networking, slow logons by premium storage, branch speed by local servers with tiering, and cost by matching tier and redundancy to each data set.

Habits that separate smooth file services from fragile and costly ones.

Common mistakes at a glance

Azure Files presents folders and files that you mount like a network drive using SMB or NFS. Blob storage holds objects accessed through web-style requests and is usually cheaper for huge amounts of unstructured data. Choose by how your software expects to reach storage.

Yes. SMB shares can be mounted on all three, and NFS shares, available on premium storage, suit Linux. Azure shows connection instructions for each system.

Many internet providers block the SMB port 445. Use a VPN or private connection, a supported secure alternative such as SMB over QUIC where available, or access through Azure File Sync or another route.

Use standard for general business files and archives where cost matters. Use premium where low latency and predictable performance matter, such as user profiles, development environments and busy application shares.

Yes. Data is encrypted at rest by default, and encrypted in transit when secure transfer settings are used. You can optionally manage the encryption keys yourself through Key Vault.

With identity-based SMB access, share-level roles control entry to the share and Windows-style access control lists control individual folders and files. A user needs to be allowed at both layers.

NFS version 4.1 is supported on premium shares with Linux-style permissions. Security relies mainly on network controls such as private endpoints, rather than per-user cloud identities.

No. Redundancy protects against hardware and site failures but copies mistakes and attacks everywhere. Add soft delete, snapshots and backup for human error and ransomware.

It is a service that keeps Windows servers in step with an Azure file share, with cloud tiering to save local space. It supports multi-site sharing, simpler backup, faster recovery and gradual migration.

It replaces rarely used local files with small placeholders while the full data stays in Azure. When a user opens such a file, it is downloaded on demand, so a small server can present a very large share.

Deleted shares can be recovered within the soft delete retention period. Individual files can be restored from share snapshots or from Azure Backup recovery points.

Charges relate to capacity stored or provisioned, transactions on some tiers, redundancy, snapshots, data leaving Azure and add-on services. Review the current pricing page for your region and billing model.

Yes. It is a common choice for profile containers on Azure Virtual Desktop, often using premium shares for fast logons and identity-based access.

Yes. Container services such as Azure Kubernetes Service and Azure Container Apps can mount shares to give containers persistent, shareable storage.

Consider it for demanding enterprise workloads requiring very low latency, very high throughput and advanced data management features that go beyond what Azure Files provides.

Match access tiers to usage, right-size premium provisioning, choose suitable redundancy, prune snapshots, tag resources and set budgets with alerts. Revisit these choices regularly as usage changes.

Azure Files gives organisations the shared-drive experience they already understand, without the burden of running file servers. Data lives in shares inside storage accounts, accessed through standard SMB and NFS protocols, on standard or premium media, with access tiers, redundancy choices and permission layers that you tune to each workload. Snapshots, soft delete and central backup protect against mistakes and attacks, private endpoints and encryption protect against exposure, and Azure File Sync lets on-premises servers and branch offices share the same data with cloud tiering to save local space. The service is not the answer for every storage problem, and it depends on good networking, careful identity setup and regular cost review, but for shared file access it removes a large amount of routine work and replaces it with a service that is protected, elastic and easy to reach.