This chapter covers Azure Files premium file shares and NFS support, two advanced storage features that differentiate Azure Files from simple SMB shares. For the AZ-104 exam, expect questions on performance tiers, NFS v4.1 limitations, and use cases for premium shares versus standard. This area typically accounts for 5-10% of storage-related questions, often appearing in scenario-based items where you must choose the correct storage solution for a given workload. Mastering these concepts ensures you can design high-performance file storage for enterprise applications.
Jump to a section
Imagine a busy highway with multiple lanes. Standard file shares are like a general-purpose lane where all traffic mixes—cars, trucks, buses—and everyone slows down when there's congestion. Premium file shares, on the other hand, are like a dedicated express lane reserved for high-priority vehicles. This lane has a guaranteed minimum speed (throughput) and a toll booth that processes vehicles faster (lower latency). The express lane is built with better materials (SSD-backed storage) and has its own dedicated entry and exit ramps (private endpoints) to avoid bottlenecks. Just as the express lane costs more per vehicle, premium file shares cost more per gigabyte but provide consistent performance. The lane is also wider (higher IOPS) and can handle more vehicles simultaneously. When you choose premium, you're paying for predictability—no surprise slowdowns during peak hours—and the ability to support demanding applications like databases or high-performance computing that can't tolerate delays. Azure Files premium shares use SSDs and provisioned capacity to guarantee IOPS and throughput, much like the express lane guarantees a certain number of vehicles per minute. If you try to send more traffic than the lane can handle, vehicles are queued (throttled) just as Azure throttles requests exceeding the provisioned limits.
What Are Premium File Shares?
Azure Files offers two performance tiers: Standard and Premium. Premium file shares are backed by solid-state drives (SSDs) and provide consistent, low-latency performance. They are designed for IOPS-intensive workloads such as databases, high-performance computing (HPC), and real-time analytics. Unlike standard shares, which use HDDs and have variable performance, premium shares offer provisioned IOPS and throughput based on the share size.
Key Characteristics
Storage Media: SSDs only.
Performance Model: Provisioned IOPS and throughput. You allocate a specific size (in GiB) and get a corresponding baseline IOPS and throughput. For example, a 100 GiB share provides 3,100 IOPS and 100 MiB/s throughput.
Bursting: Premium shares support bursting. When your workload exceeds baseline IOPS, Azure can burst up to 7,000 IOPS (for shares >= 1 TiB) for up to 60 minutes, using burst credits. Credits accumulate during idle periods.
Latency: Single-digit millisecond latency for most operations.
Redundancy: Locally-redundant storage (LRS) and zone-redundant storage (ZRS) are supported. Geo-redundancy (GRS) is not available for premium.
Protocols: SMB and NFS v4.1. SMB supports both Active Directory (AD) and Azure AD authentication; NFS only supports AD authentication (no Azure AD).
Networking: Private endpoints are recommended for NFS to avoid public internet exposure. Premium shares can also be accessed over public endpoints with firewall rules.
How Premium Shares Work Internally
When you create a premium file share, Azure allocates a specific amount of SSD capacity on a storage cluster. The share is thinly provisioned—you pay for the provisioned size, not the actual data stored. The IOPS and throughput are calculated based on the provisioned size using fixed formulas:
Baseline IOPS = Provisioned GiB × 3.1 (up to 100,000 IOPS for 100 TiB shares)
Burst IOPS = Baseline + (Provisioned GiB × 1.2) up to 7,000 IOPS (for shares >= 1 TiB)
Throughput = Provisioned GiB × 0.1 MiB/s (up to 10 GiB/s for 100 TiB shares)
For example, a 1 TiB (1024 GiB) share provides:
Baseline IOPS: 1024 × 3.1 = 3,174 IOPS
Burst IOPS: 3,174 + (1024 × 1.2) = 4,403 IOPS (capped at 7,000)
Throughput: 1024 × 0.1 = 102.4 MiB/s
Burst credits accumulate at a rate equal to the difference between the burst IOPS and baseline IOPS when the share is idle. Each credit represents one I/O operation at burst speed. The credit bucket can hold up to 60 minutes of burst credits. When you exceed baseline, credits are consumed. Once exhausted, performance drops to baseline.
NFS Support on Azure Files
Azure Files supports NFS v4.1 protocol for Linux-based workloads. NFS shares are only available on premium file shares. Key points:
Authentication: NFS uses AD-based authentication (Kerberos) or UNIX-style numeric IDs (root squash). Azure AD authentication is not supported.
Root Squash: By default, root on the client is mapped to anonymous (nobody). You can disable root squash if needed.
Ports: NFS uses port 2049 for TCP. You must allow this port in firewalls and network security groups.
Export Path: The NFS export path is the share name. For example, if your share is named 'myshare', the mount path is //storageaccount.file.core.windows.net/myshare.
Permissions: File permissions are managed using NFS export policies (read-only, read-write, no root squash) and POSIX ACLs. Azure does not support Windows ACLs for NFS.
Limitations: NFS shares cannot be accessed via SMB simultaneously. Only NFS v4.1 is supported (no v3). The share must be created as NFS-enabled at creation time—you cannot convert an existing SMB share to NFS.
Creating and Configuring Premium Shares
To create a premium file share, you need a storage account of type 'FileStorage' (premium). Here's the Azure CLI command:
az storage account create -n mystorageaccount -g myresourcegroup --sku Premium_LRS --kind FileStorage
az storage share-rm create -n myshare -g myresourcegroup --storage-account mystorageaccount --quota 100For NFS, you must enable the '--enable-nfs-v3' flag (note: it's misnamed; it actually enables NFS v4.1). Also, you need to restrict network access to prevent NFS from being exposed to the internet:
az storage account create -n mystorageaccount -g myresourcegroup --sku Premium_LRS --kind FileStorage --enable-nfs-v3 true --default-action Deny --bypass AzureServices
az storage share-rm create -n myshare -g myresourcegroup --storage-account mystorageaccount --quota 100 --enabled-protocols NFSPerformance Optimization
Provisioning Size: To achieve higher IOPS, increase the provisioned size. For example, a 10 TiB share gives 31,000 baseline IOPS and 1 GiB/s throughput.
Bursting: For spiky workloads, rely on bursting. Ensure the share has enough idle time to accumulate credits.
Caching: On the client side, use Azure Files sync or local caching for read-heavy workloads.
Network: Use Azure ExpressRoute or VPN for consistent latency. Private endpoints eliminate internet hops.
Interaction with Related Technologies
Azure Backup: Premium shares can be backed up using Azure Backup. Backup creates snapshots that count toward the share's IOPS limits.
Azure File Sync: Works with premium SMB shares but not with NFS shares.
Azure Storage Firewalls: Premium shares support virtual network service endpoints and private endpoints. For NFS, private endpoints are strongly recommended to avoid public access.
Azure Active Directory: SMB shares support Azure AD DS and AD DS authentication. NFS only supports AD DS via Kerberos.
Exam-Relevant Details
Premium shares are only available for the FileStorage account kind.
Minimum share size is 100 GiB (provisioned).
NFS shares cannot use Azure AD authentication.
NFS shares require the storage account to have '--enable-nfs-v3 true' (even though it enables v4.1).
Premium shares support LRS and ZRS, not GRS.
Bursting is automatic but limited to 7,000 IOPS for shares >= 1 TiB.
Common Commands
List shares: az storage share-rm list --storage-account mystorageaccount -g myresourcegroup
Show share metrics: az storage share-rm show -n myshare --storage-account mystorageaccount -g myresourcegroup
Mount NFS share on Linux: sudo mount -o nfsvers=4.1,sec=sys //storageaccount.file.core.windows.net/myshare /mnt/myshare
Create Premium Storage Account
Use Azure CLI or portal to create a storage account with kind 'FileStorage' and SKU 'Premium_LRS' or 'Premium_ZRS'. This is the only account type that supports premium file shares. For NFS, add the flag '--enable-nfs-v3 true' (misleading name; it enables NFS v4.1). Also set '--default-action Deny' to block public access and '--bypass AzureServices' to allow Azure services. This step is critical because you cannot change the account kind or enable NFS later.
Create Premium File Share
Use 'az storage share-rm create' with a quota (provisioned size) of at least 100 GiB. Specify '--enabled-protocols NFS' for NFS shares, or leave default for SMB. The share name must be all lowercase and can contain hyphens. The provisioning size determines IOPS and throughput. For example, a 500 GiB share yields 1,550 baseline IOPS and 50 MiB/s throughput. If you need more performance, increase the quota.
Configure Networking for NFS
For NFS shares, create a private endpoint to ensure traffic stays within Azure backbone. Alternatively, configure firewall rules to allow specific IP ranges. NFS requires port 2049 TCP open. If using public endpoint, Azure enforces '--default-action Deny' and you must add a firewall rule. Private endpoints require a private DNS zone for 'privatelink.file.core.windows.net'. This step prevents NFS from being exposed to the internet.
Mount NFS Share on Linux Client
On a Linux VM, install NFS client (nfs-common on Ubuntu). Use mount command: 'sudo mount -o nfsvers=4.1,sec=sys //storageaccount.file.core.windows.net/myshare /mnt/myshare'. The 'sec=sys' uses UNIX UID/GID for permissions. If using AD authentication, replace 'sec=sys' with 'sec=krb5' and ensure Kerberos is configured. The mount must use TCP; UDP is not supported. Verify with 'df -h' and 'mount | grep nfs'.
Monitor Performance and Bursting
Use Azure Monitor metrics: 'File Share Capacity', 'File Share IOPS', 'File Share Throughput', and 'File Share Burst Credits'. The 'Burst Credits' metric shows remaining burst capacity. If credits are low, consider increasing provisioned size or throttling workloads. The 'Transactions' metric shows read/write operations. For exam, remember that bursting is automatic up to 7,000 IOPS for shares >= 1 TiB, and the burst duration is limited by accumulated credits.
Enterprise Scenario 1: Database Storage for SQL Server on Azure VMs
A financial services company runs SQL Server on Azure VMs and needs low-latency storage for transaction logs and data files. They choose premium file shares over managed disks because they want to decouple storage from compute and avoid disk management. The share is provisioned at 1 TiB, providing 3,174 baseline IOPS and 102 MiB/s throughput, with bursting up to 7,000 IOPS for peak loads. They mount the share using SMB and enable Azure File Sync for disaster recovery. The challenge is that SQL Server requires exclusive access to files, so they must ensure no other processes access the files. They also configure private endpoints to reduce latency. Performance is monitored using Azure Monitor; during month-end processing, bursting kicks in and maintains performance. Misconfiguration occurs when the share size is too small—e.g., 100 GiB—causing IOPS starvation and query timeouts.
Enterprise Scenario 2: HPC Workloads with NFS
A research lab uses Linux-based HPC clusters for genomic analysis. They need a shared file system with high throughput and low latency. They deploy premium file shares with NFS v4.1, provisioning 10 TiB to get 31,000 baseline IOPS and 1 GiB/s throughput. The shares are mounted on compute nodes via private endpoints. They use root squash disabled to allow administrative scripts to run with root privileges. The key performance consideration is that NFS over Azure Files has a single endpoint, so throughput is limited by the share's provisioned throughput. For higher throughput, they distribute data across multiple shares. A common misconfiguration is forgetting to install the NFS client or not opening port 2049 in the NSG, resulting in mount failures. Also, they initially used public endpoints, causing security policy violations; they switched to private endpoints after audit.
Enterprise Scenario 3: Home Directories for Remote Employees
A global company provides home directories for remote employees using Azure Files premium SMB shares. They use Azure AD DS for authentication and configure folder redirection via Group Policy. The share is provisioned at 500 GiB per department. They enable Azure Backup for snapshots. The challenge is that each user's home folder is a subfolder, and Azure Files doesn't support quotas per folder—only share-level quotas. So they monitor capacity alerts. A misconfiguration occurs when they initially used standard shares; users experienced slow logins due to high latency. Switching to premium resolved the issue. They also had to enable SMB Multichannel for better performance on Windows clients, which is supported only on premium shares.
What AZ-104 Tests: Objective 2.2 – Configure Azure Files
The exam covers premium file shares and NFS under the 'Implement and Manage Storage' domain. Key subtopics:
Differentiate between standard and premium file shares.
Identify use cases for NFS vs SMB.
Understand provisioning and performance characteristics.
Configure network access (private endpoints, firewalls) for NFS.
Recognize limitations: NFS does not support Azure AD authentication; premium shares do not support GRS.
Common Wrong Answers
Choosing NFS for Windows workloads: NFS is Linux-native. Candidates often select NFS for Windows VMs because it's 'faster'. Reality: Windows uses SMB. NFS on Windows requires additional services and is not recommended. Exam expects SMB for Windows.
Enabling NFS on an existing share: You cannot convert an SMB share to NFS. The protocol is set at creation. Many candidates think you can change it later.
Using GRS for premium shares: Premium only supports LRS and ZRS. Candidates who see 'geo-redundancy' in a question about disaster recovery for premium shares may incorrectly choose GRS.
Assuming NFS uses Azure AD: NFS uses AD DS or UNIX-style auth, not Azure AD. The exam tests this distinction.
Forgetting to deny public access for NFS: NFS shares require network restrictions. Candidates configure NFS but leave public access enabled, which is insecure and may not be allowed in scenarios.
Specific Numbers and Terms on the Exam
Minimum premium share size: 100 GiB.
IOPS formula: 3.1 IOPS per GiB.
Throughput: 0.1 MiB/s per GiB.
Burst max: 7,000 IOPS (for shares >= 1 TiB).
Burst duration: up to 60 minutes based on credits.
NFS version: 4.1 only.
Port: 2049 TCP.
Storage account kind: FileStorage.
SKUs: Premium_LRS, Premium_ZRS.
Edge Cases and Exceptions
Premium shares can be accessed from on-premises only via VPN or ExpressRoute; no public internet access if firewall is set to deny.
NFS shares cannot be accessed via SMB simultaneously; they are mutually exclusive.
Premium shares support Azure Backup, but snapshots count against performance.
SMB Multichannel is supported only on premium shares.
The '--enable-nfs-v3' flag actually enables NFS v4.1 despite the name.
How to Eliminate Wrong Answers
If the scenario mentions 'Linux', 'POSIX', or 'UNIX permissions', lean toward NFS.
If the scenario mentions 'Active Directory Domain Services' (not Azure AD), NFS can work with Kerberos.
If the scenario requires 'geo-redundancy', eliminate premium shares.
If the scenario requires 'Azure AD authentication', eliminate NFS.
If performance numbers are given, calculate IOPS/throughput using the formulas to verify if premium is needed.
Premium file shares require a FileStorage storage account and SKU Premium_LRS or Premium_ZRS.
Minimum provisioned size for a premium share is 100 GiB.
IOPS = Provisioned GiB × 3.1; Throughput = Provisioned GiB × 0.1 MiB/s.
Bursting is automatic up to 7,000 IOPS for shares >= 1 TiB, limited by accumulated credits (60 min max).
NFS v4.1 is only available on premium shares and cannot be used with Azure AD authentication.
NFS shares require network restrictions (private endpoint or firewall) and port 2049 TCP open.
You cannot change the protocol of an existing share; recreate if needed.
Premium shares do not support geo-redundant storage (GRS).
SMB Multichannel is supported only on premium shares.
The '--enable-nfs-v3' flag actually enables NFS v4.1 despite the name.
These come up on the exam all the time. Here's how to tell them apart.
Standard File Shares
Backed by HDDs; variable performance
Pay-as-you-go for storage; no provisioned IOPS
Maximum IOPS per share is limited (e.g., 1,000 IOPS for 1 TiB)
Supports SMB only; no NFS
Supports LRS, ZRS, GRS, and GZRS
Premium File Shares
Backed by SSDs; consistent low latency
Provisioned IOPS and throughput based on size
Higher IOPS (3.1 per GiB) and bursting up to 7,000 IOPS
Supports both SMB and NFS v4.1
Supports only LRS and ZRS; no GRS
Mistake
NFS shares support Azure AD authentication.
Correct
NFS shares only support Active Directory Domain Services (AD DS) via Kerberos or UNIX-style numeric IDs. Azure AD authentication is not available for NFS; it is only supported for SMB shares.
Mistake
You can convert an existing SMB file share to NFS.
Correct
The protocol (SMB or NFS) is set at share creation time and cannot be changed. You must delete and recreate the share to switch protocols.
Mistake
Premium file shares support geo-redundant storage (GRS).
Correct
Premium file shares only support locally-redundant storage (LRS) and zone-redundant storage (ZRS). Geo-redundancy is not available for premium shares.
Mistake
NFS shares can be accessed over the public internet without restrictions.
Correct
NFS shares require network restrictions. By default, public access is denied when you create the storage account with '--default-action Deny'. You must use private endpoints or firewall rules to allow specific clients.
Mistake
Premium file shares provide unlimited burst IOPS.
Correct
Bursting is capped at 7,000 IOPS for shares >= 1 TiB. Smaller shares have lower burst limits. Burst credits accumulate and are consumed; once exhausted, performance drops to baseline.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. NFS shares on Azure Files only support Active Directory Domain Services (AD DS) authentication via Kerberos or UNIX-style numeric IDs. Azure AD authentication is not supported for NFS. For Azure AD, you must use SMB shares. This is a common exam distinction.
The minimum provisioned size is 100 GiB. You are billed for the provisioned capacity, not the actual data stored. The size determines IOPS and throughput. For example, a 100 GiB share provides 310 baseline IOPS and 10 MiB/s throughput.
Bursting allows a premium share to exceed its baseline IOPS up to 7,000 IOPS (for shares >= 1 TiB) for a limited time. Burst credits accumulate when IOPS are below baseline. Each credit represents one I/O at burst speed. The credit bucket holds up to 60 minutes of burst. Once credits are exhausted, performance returns to baseline.
Yes, but only if you configure network rules to allow specific IP addresses or ranges. By default, premium storage accounts are created with '--default-action Deny', blocking public access. You must explicitly add firewall rules. For NFS, private endpoints are strongly recommended to avoid security risks.
Azure Files supports NFS v4.1 only. NFS v3 is not supported. The CLI flag '--enable-nfs-v3' is misleading; it actually enables NFS v4.1. This is a known exam trick.
No. A premium file share is created with either SMB or NFS protocol. You cannot access the same share using both protocols simultaneously. If you need both, create separate shares.
Use the mount command: 'sudo mount -o nfsvers=4.1,sec=sys //storageaccount.file.core.windows.net/myshare /mnt/myshare'. Ensure the NFS client is installed (e.g., nfs-common on Ubuntu). For AD authentication, use 'sec=krb5' and configure Kerberos. The share must be accessible via network (private endpoint or firewall rule).
You've just covered Premium File Shares and NFS — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?