4.1.2. Azure Files
💡 First Principle: Azure Files provides fully managed, cloud-based file shares accessible via standard network protocols. The key insight is protocol compatibility: Azure Files speaks SMB (Windows) and NFS (Linux), so existing applications that expect a file server "just work." Its core purpose is enabling "lift-and-shift" migrations of applications that rely on file shares without code changes.
What It Is: A service that offers fully managed file shares in the cloud that are accessible via the industry-standard Server Message Block (SMB) and Network File System (NFS) protocols.
Key Concepts:
- Shared Access: Azure file shares can be mounted concurrently by cloud or on-premises deployments of Windows, Linux, and macOS.
- Fully Managed: You don't need to manage a file server VM or its operating system.
Visual: Azure Files vs. Blob Storage
⚠️ Exam Trap: Confusing Azure Files with Blob Storage is heavily tested. The key differentiator is protocol:
- If scenario mentions SMB, file share, or legacy application using file paths → Azure Files
- If scenario mentions images for website, data lake, or HTTP access → Blob Storage
Azure File Sync
Azure File Sync extends an Azure file share out to Windows Servers you already run, which is the usual answer when branch offices each have their own file server.
- Each server keeps a cache of the share, so staff get local-speed access to the files they actually use.
- Cloud tiering leaves rarely-touched files in Azure and keeps only a pointer on the local disk, so a small server can front a very large share.
- Every server syncs against the same Azure file share, which becomes the single authoritative copy — and is backed up centrally rather than server by server.
Reasoning Tool: "file servers at several branch offices" plus "centralise" points at Azure File Sync. Plain Azure Files centralises the storage but does not keep on-premises servers in step with it.