Azure Files Complete Guide: SMB/NFS, Standard/Premium, Entra Kerberos & File Sync

Azure Files is a Microsoft-managed file share service that can be mounted via SMB (Server Message Block), NFS (Network File System), or REST API. Delivered as the File service of a Storage Account, it can be mounted from Azure VMs, on-premises Windows/Linux, AKS Pods, App Service, and more using standard file system protocols. Common use cases include: 1) Lift-and-shift migration of on-premises file servers to Azure, 2) Container Persistent Volumes, 3) Shared application settings and centralized log collection, and 4) Cross-region file sharing. Its pay-as-you-go pricing and minimal operational overhead make it a widely adopted replacement for traditional file servers.

Standard File Storage is HDD-based, suited to general-purpose scenarios, low cost, supports up to 100 TB/share, and uses transaction-based billing (per operation). Premium File Storage is SSD-based, delivers low latency (1-2 ms) and high IOPS (100,000+), supports up to 100 TB/share, and uses capacity-based fixed pricing (operations are free). Decision criteria: choose Premium when file I/O is frequent and low latency is required (DB files, ML datasets); choose Standard for lift-and-shift, archival, or infrequent access. Premium requires the dedicated FileStorage account kind (general-purpose StorageV2 cannot host Premium Files). The standard practice is to define requirements along three axes — IOPS, throughput, and latency — before selecting a tier.

SMB protocol: Windows-native, supports Active Directory authentication (Entra Domain Services, on-premises AD), compatible with Windows file servers, and supports SMB 2.1/3.0/3.1.1. Typical use cases include Windows VM file sharing, user profiles, and Office document sharing. NFS protocol: Linux/Unix-native, supports NFSv4.1 (Premium FileStorage only), requires no Active Directory (anonymous access with IP-based control). Typical use cases include Linux VM / AKS Pod file sharing, HPC workloads, and data analytics pipelines. Rule of thumb: Windows workloads = SMB, Linux/container workloads = NFS. SMB and NFS cannot be mixed on the same share — you must create separate shares per protocol.

Azure Files SMB supports three AD authentication options: 1) On-premises Active Directory Domain Services (AD DS) — accessed from domain-joined VMs by registering the Storage Account as an AD Computer Object; the most flexible option. 2) Microsoft Entra Domain Services (Entra DS) — a cloud-managed AD synchronized with Entra ID, ideal for environments without on-premises AD. 3) Microsoft Entra Kerberos (Hybrid User) — direct Microsoft Entra ID authentication for hybrid identity environments, targeting Entra Connect-synchronized users; the latest recommended approach. Setup: Storage Account → File shares → Active Directory → select method and configure domain join. Access is controlled by RBAC roles (e.g., Storage File Data SMB Share Contributor). For production, Entra Kerberos is the modern best practice.

Azure File Sync is a Microsoft-managed hybrid file server capability that synchronizes on-premises Windows file servers with Azure Files. Typical scenarios: 1) Gradual migration from on-premises file servers to Azure Files (Cloud Tiering keeps hot files local and moves the rest to Azure); 2) Central consolidation of branch-office file servers (each site's Windows Server consolidates into a central Azure Files share); 3) Disaster Recovery (restore from Azure Files when on-premises fails). Setup: create a Storage Sync Service resource in Azure, install the Azure File Sync Agent on the on-premises Windows Server, and start syncing via a Server Endpoint. It delivers both cost optimization (Cloud Tiering can cut storage by 80%) and simplified operations — a critical feature in hybrid environments.

On AKS, Azure Files can be used as a Persistent Volume via the built-in Azure File CSI Driver (Container Storage Interface). Specify azurefile-csi (SMB) or azurefile-csi-nfs (NFS) as the Pod's StorageClass, and request capacity and access mode (including ReadWriteMany) via a PVC (Persistent Volume Claim). Unlike Azure Disk (ReadWriteOnce), Azure Files supports file sharing across multiple Pods. Typical use cases: 1) Shared wp-content for WordPress; 2) Shared ML datasets; 3) Centralized log collection. Both Static Provisioning (mounting an existing Azure File Share) and Dynamic Provisioning (auto-creating a share at Pod startup) are supported. The standard production AKS pattern is to use Premium FileStorage NFS to meet low-latency requirements.

Key controls: 1) Eliminate public exposure with Private Endpoint (privatelink.file.core.windows.net Private DNS Zone); 2) Integrate with Entra ID via Microsoft Entra Kerberos authentication; 3) Restrict Network Access to Selected Networks (Allow Trusted Microsoft Services); 4) Enforce SMB 3.0+ (disable SMB 1.0/2.0, require encryption); 5) Enforce share-level permissions via RBAC (Storage File Data SMB Share Reader/Contributor/Elevated Contributor); 6) Enable Microsoft Defender for Storage to detect malicious files; 7) Enable Soft Delete (14-365 days) to guard against accidental deletion; 8) Ship Diagnostic Logs to Log Analytics; 9) Schedule regular Azure Backup for Azure Files; 10) Encrypt with Customer-Managed Keys. In production, these controls should be combined as a layered defense to prevent incidents.

AZ-104 (Administrator) is the primary certification for this area — Domain 2 (Storage, 15-20%) covers Azure Files in depth. AZ-204 (Developer Associate) covers file operations from a developer's perspective, AZ-305 (Solutions Architect Expert) covers architecture selection (Files vs Blob vs Disk), AZ-800/AZ-801 (Windows Server Hybrid) cover Azure File Sync integration, and AZ-140 (AVD Specialty) covers FSLogix Profile Container use cases. Understanding Azure Files is essential for any engineer working with Azure.