Azure Files and File Sync

Azure Files is a fully managed file share service in the cloud that uses the Server Message Block (SMB) protocol and the Network File System (NFS) protocol. Imagine your company has dozens of on-premises file servers storing shared documents, project files, and configuration scripts. Maintaining those servers requires hardware procurement, patching, backup, and disaster recovery planning. Azure Files eliminates that overhead by providing a cloud-based file share that you can mount just like a local drive from Windows, Linux, or macOS machines, either on-premises or in Azure.

The core business problem Azure Files solves is the need for a central, highly available, and scalable file storage that multiple users and applications can access simultaneously without managing physical servers. For example, a global engineering team can use Azure Files to share CAD drawings; an enterprise can lift-and-shift legacy applications that require SMB file shares; or a DevOps team can share configuration files across virtual machines.

Azure Files operates on a simple but powerful architecture. You start by creating a storage account in Azure. Within that storage account, you create a file share. The file share is accessible via a UNC path like \\mystorageaccount.file.core.windows.net\myshare. Behind the scenes, Azure stores the file data as objects in blob storage but exposes it through the SMB protocol. This means you get the reliability and durability of Azure Blob Storage (99.9999999999% durability for RA-GRS) with the familiar SMB interface.

When a client mounts the share, it uses standard SMB 3.0 (or later) with encryption. Azure enforces encryption in transit for SMB connections—unencrypted SMB 2.1 is not allowed. This is a key exam point: Azure Files requires SMB 3.0+ with encryption for connections over the internet. For on-premises clients, you can use Azure VPN Gateway or ExpressRoute to connect privately, and then SMB 2.1+ is allowed because the traffic is already encrypted by the VPN/tunnel.

Azure Files supports both Active Directory Domain Services (AD DS) and Azure Active Directory (Azure AD) for authentication. You can set NTFS-style permissions on folders and files, just like on a Windows file server. This makes it a seamless drop-in replacement for many on-premises file servers.

Azure Files has two main performance tiers: Standard and Premium.

Within Standard, there are two transaction-optimized tiers: Transaction Optimized (for high transaction workloads like log files) and Cool (for infrequently accessed data like archives). The Cool tier has lower storage cost but higher transaction costs, so it's only cost-effective for data you access rarely.

Pricing for Azure Files includes storage cost (per GB/month) plus transaction cost (per operation). For Standard shares, you also pay for data access (read/write/list operations). Premium shares have a higher storage cost but no transaction cost—you pay for provisioned capacity, not used capacity.

On-premises file servers require upfront hardware investment, ongoing maintenance, backup software, and disaster recovery planning. Azure Files provides built-in redundancy (LRS, ZRS, GRS, RA-GRS), automatic failover, and snapshots (file share snapshots) for point-in-time recovery. You can also integrate with Azure Backup for managed backups.

However, Azure Files has some limitations compared to on-premises: it doesn't support SMB Multichannel in all regions (though it's rolling out), and it has a maximum file size of 1 TiB (Standard) or 4 TiB (Premium). Also, certain legacy applications may require features like DFS-R or FSRM, which Azure Files does not natively support—but Azure File Sync can bridge some gaps.

Azure File Sync is a service that caches Azure file shares on Windows Servers on-premises or in other clouds. It uses a sync engine to keep the local server's file share in sync with the Azure file share. The key feature is cloud tiering: you can set a policy that only the most recently accessed files are kept locally; older or less frequently accessed files are replaced with a stub (a pointer) and the actual data resides only in Azure. When a user accesses a stub, the file is seamlessly recalled from Azure.

This solves a huge problem: you can migrate your file servers to Azure without changing how users access files. Users still connect to the same UNC path on the local server, but the server is now a cache for the cloud share. This gives you a single, central file share in Azure that all your branch offices can sync to, eliminating the need for complex DFS replication.

You can create and manage Azure file shares and File Sync via the Azure portal, Azure CLI, or PowerShell.

To create a file share via CLI:

az storage share create --name myshare --account-name mystorageaccount --quota 100

To set up Azure File Sync, you first create a Storage Sync Service resource, then register your Windows Server with the service, and finally create a sync group that connects the Azure file share to the server's local path.

# Create Storage Sync Service
az storagesync create --resource-group myRG --name mySyncService --location eastus

# Register server (run on the server)
Install-Module -Name Az.StorageSync
Register-AzStorageSyncServer -ResourceGroupName myRG -StorageSyncServiceName mySyncService

# Create sync group
az storagesync sync-group create --resource-group myRG --storage-sync-service mySyncService --name mySyncGroup

These commands are not required for AZ-900, but understanding the workflow helps you visualize the architecture.

Scenario 1: Global Engineering Firm Sharing CAD Files A multinational engineering company has teams in the US, Europe, and Asia working on large CAD models. Previously, they used a central on-premises file server with slow VPN access for remote offices. They migrated to Azure Files Premium to get low latency and high IOPS. Each office mounts the same Azure file share using SMB 3.0 over ExpressRoute. The share is 10 TiB with snapshots every 6 hours. Cost: about $2,000/month for storage and transactions. The team also uses Azure File Sync to cache a subset of files on a local server in the US office for offline access. The main challenge was ensuring that the SMB protocol worked smoothly over high-latency links—they had to adjust SMB settings like SmbClientServerLatency to avoid timeouts. If they had used Standard tier instead, the latency would have been unacceptable for CAD workloads.

Scenario 2: Enterprise Lift-and-Shift of Legacy Application A financial services company has a legacy .NET application that requires an SMB file share for storing transaction logs. Instead of refactoring the app, they create an Azure Files share and mount it on the Azure VM running the app. The share is Standard with LRS, costing about $100/month for 500 GB. They use Azure Backup to take daily snapshots. The VM and file share are in the same Azure region, so there's no egress cost. The migration took one day: create the share, copy data using AzCopy, and update the app configuration. The risk was that the app used SMB 2.1, which is not supported over the internet—so they had to deploy a VPN gateway between the VM and the share (even though both are in Azure, the VM can use SMB 3.0+ without issue). The exam might test that Azure Files requires SMB 3.0+ with encryption for public endpoints.

Scenario 3: Branch Office Consolidation with Azure File Sync A retail chain has 50 branch offices, each with a local file server for shared documents. Maintaining these servers is costly. They deploy Azure File Sync on each branch's Windows Server, syncing to a central Azure file share. Cloud tiering is enabled with a policy that keeps files accessed within the last 30 days locally. This reduces local storage needs by 70%. Branch employees still access files via the local server path, so no user training is needed. The sync schedule is set to every 24 hours, but urgent changes can be force-synced. The main cost is the Azure file share storage ($0.08/GB/month for Standard) plus transaction costs. A common mistake is forgetting to configure the sync schedule properly, leading to stale files. Another pitfall is not testing the recall performance—if a user accesses a tiered file, it can take seconds to recall from Azure, which may be too slow for some workloads.