Plan for an Azure Files deployment

Here’s a concise summary of the article "Plan to deploy Azure Files".

Overview

• Two main deployment approaches:

  • Directly mount serverless Azure file shares (SMB or NFS) from on-premises or cloud clients — no need to manage file servers/NAS.

  • Cache Azure file shares on-premises using Azure File Sync to keep on-premises performance and compatibility while centralizing data in Azure.

• This article focuses on planning for directly mounted Azure file shares. For Azure File Sync planning, see Planning for an Azure File Sync deployment.

Management concepts

• Resources in Azure are created and managed in subscriptions/resource groups by resource providers.

• Storage accounts (Microsoft.Storage) are top-level resources that provide a shared pool of storage, IOPS, and throughput. Classic file shares live in storage accounts and share account-level limits and settings.

Classic file shares (Microsoft.Storage)

• Traditional method for Azure Files; supports SMB and NFS, SSD and HDD tiers, and redundancy options.

• Key limitations:

  • Capacity planning: multiple shares in a storage account share the same pool of capacity/IOPS/throughput.

  • Shared settings: network/security rules applied at the storage account level (treat storage account as a trust boundary).

  • Scaling complexity: large deployments may require managing many subscriptions due to storage account constraints.

• Two storage account kinds for classic shares:

  • Provisioned (FileStorage): for provisioned SSD/HDD classic file shares; recommended for new deployments.

  • Pay-as-you-go (StorageV2): supports pay-as-you-go HDD shares and other storage resources.

Available protocols

• Azure Files supports SMB (SMB 2.1, 3.0, 3.1.1) and NFS (NFS 4.1). A share supports either SMB or NFS, not both.

• Protocol differences include OS recommendations, tiers, redundancy support, authentication/authorization models (Kerberos/AD and Win32 ACLs for SMB; host-based auth and POSIX perms for NFS), case-sensitivity, internet accessibility (SMB 3.0+ yes; NFS no), and various filesystem features and semantics.

Identity

• Authentication/authorization options:

  • On-premises AD DS: domain-join storage account for Kerberos-based auth (recommended for server-like behavior).

  • Microsoft Entra Domain Services: managed domain controller option; uses Kerberos.

  • Microsoft Entra Kerberos: use Microsoft Entra ID for Kerberos tickets (hybrid scenarios and internet access from joined VMs).

  • AD authentication over SMB for Linux is supported via Kerberos.

  • Storage account key (not recommended): acts like an admin credential; uses NTLMv2 for SMB. If used, restrict access via private or service endpoints.

Networking

• Consider network configuration because SMB uses port 445 (commonly blocked) and NFS requires restricted networks.

• Options:

  • Public endpoint (internet-accessible).

  • Service endpoints to restrict access to virtual networks.

  • Private endpoints for private IP addressing (recommended for static IP/high availability).

• Typical guidance:

  • SMB access from clients in Azure: no special networking required.

  • SMB access from on-premises: use VPN or ExpressRoute plus private endpoints.

  • NFS: use service endpoints or private endpoints; private endpoints recommended for static IP/HA.

• SMB over QUIC is possible via Azure File Sync caching on Windows Server 2022 Azure Edition (not directly by Azure Files).

Encryption

• Encryption in transit:

  • Enabled by default — requires SMB 3.x with encryption or HTTPS for FileREST. Disabling is possible for legacy OS support (enables SMB 2.1 and unencrypted HTTP), but not recommended.

• Encryption at rest:

  • All data is encrypted at rest via Azure Storage service-side encryption (SSE). Default is Microsoft-managed keys; customer-managed keys are supported but must be authorized for Azure Files to access them.

Data protection

• Multi-layered protection: soft delete, snapshots, Azure Backup, and Microsoft Defender for Storage.

• Soft delete:

  • Storage-account level; deleted shares become recoverable for a configurable retention period (enabled by default for new accounts).

• Backup:

  • Share snapshots are incremental, up to 200 snapshots per share and up to 10-year retention. Azure Backup offers scheduled GFS retention and restore orchestration.

• Microsoft Defender for Storage:

  • Provides threat detection and alerts by analyzing storage telemetry; detects known malware (based on file hashes for REST API) and surfaces alerts in Defender for Cloud.

Storage tiers

• SSD (premium): low-latency, high-performance for I/O-intensive workloads; available for SMB and NFS and via provisioned billing models.

• HDD (standard): cost-effective for general-purpose shares; available via provisioned v2 and pay-as-you-go (provisioned v2 recommended).

• Shares can’t be moved directly between media tiers — you must create a new share and copy data.

Redundancy

• Options to protect against data loss:

  • LRS (Locally redundant)

  • ZRS (Zone-redundant)

  • GRS (Geo-redundant, async replication to secondary region)

  • GZRS (Geo-zone-redundant)

• HDD supports all four; SSD supports LRS and ZRS only.

• Note: RA-GRS/RA-GZRS are storage-account settings not supported for reading from the secondary by Azure Files.

Disaster recovery and failover

• Have a disaster recovery plan for regional outages. See Disaster recovery and failover for Azure Files for details.

Migration

• Most deployments involve migrating existing on-premises shares. Choose the right migration strategy and tools — see the migration overview article for guidance.

Next steps / links

• Planning for an Azure File Sync Deployment

• Deploying Azure Files

• Deploying Azure File Sync

• Migration overview to find a migration guide

Last updated: 11/24/2025

If you want, I can:

• Produce a one-page checklist for deployment (networking, identity, encryption, tier, redundancy, backup).

• Convert the protocol comparison into a compact table or tabs for SMB vs NFS.