Azure Files offers fully managed cloud file shares and extends the ability of organizations to share files across on-premises and the cloud. With support for industry standard SMB protocol, this service is truly cross-platform and can support mounting as file share from any client that implements SMB 3.0 with encryption.

Azure Files was initially launched over 2 years ago and was designed for mostly lift and shift. If you had an application on-premises that required a file share to operate with multiple concurrent users accessing it, Azure Files was designed to provide the same value up in the cloud. Customers could take their applications on-premises and move it up to the cloud and make use of it. In addition to native mount that uses SMB 2.1 and 3.0, it exposes REST APIs for programmability. There is support for Windows, Linux, Mac OS that can mount those file shares. There is encryption over the wire, at rest and secure communication over SMB. With Azure Files, organizations get the added benefit of a storage infrastructure that is highly secure, massively scalable, and globally available.
Why File Servers?

Organizations still use files servers mainly for 2 reasons:

Application compatibility: File shares provide SMB semantics that provide ACLs to port, long path name, extended characters in the path name to name a few. There are a lot of functionalities you don’t get in Azure, say in a BLOB storage. So organizations continue to use File servers.
Performance: There are workloads, a good example being customers who have collaboration scenarios like CAD/CAM drawings, for which latency is an issue. Organizations cannot have users in specific sites dealing with 100ms latency and get the job done. They are dealing with large files that are collaborative and need to be more performant.

What are the pain points with File Servers?

Cold data: Storage continues to grow and a lot of it is cooler data that maybe users or applications need. There are issues usually moving huge data or the workload failing to move.
Capacity management: Related to cold data is capacity management. Do you over provision when you first set up the File server or add more storage once the File server runs out of space.
DR/Backup restore: If an organization has File servers spread across the multiple locations, how do you backup every one of those File servers? How do you test those backups? How do you do a restore especially in a branch office type deployment scenario?

Azure File Sync

Microsoft came up with Azure File Sync to centralize a company’s File servers up into Azure as a value prop that addresses the pain points listed above. It provides value in a managed cloud service, where organizations would not have to deal with managing the hardware or the service itself. It was really designed to reduce the complexity associated with server sprawl and having to manage multiple File servers separately. This also preserves the on-premises experience. The users continue to work just the way they do currently and its seamless to applications or users using File servers.

Azure File Sync keeps your Azure File share in-sync with your on-premises Window Servers. The real magic of Azure File Sync is the ability to tier files between your on-premises file server and Azure Files. This enables you to keep only the newest and most recently accessed files locally without sacrificing the ability to see and access the entire namespace through seamless cloud recall. With Azure File Sync, you can effectively transform your Windows File Server into an on-premises tier of Azure Files.

For additional information on Azure File Sync, you can refer to the documentation here.

Scenarios to use Azure File Sync

Below are the various scenarios you can leverage Azure File Sync:

Top Use Cases for Azure File Sync

Highly Available FTP Server

Creating load balanced stateless FTP servers that use Azure Files to store shared content results in scalable and highly available FTP server.

Existing scripts backup to a file share, replace the on-premises share with Azure Files.

Application running on IaaS VM, output is post-processed on premises, e.g. print on premises

Network ACLs

Storage accounts are on public IPs. If you need to secure your storage accounts, you will need to utilize Network ACLs which is available in the portal as shown below. You can change the default access to deny and whitelist certain VNETs or IP ranges to allow access to them.

Additionally, Azure File Sync is still in Preview. “Preview” for an Azure service or service capability means that you can use it for production data, but that the service/service capability may not yet be available in all regions, may be lacking some important features, and does not yet have a full production service level agreement (SLA). Currently Azure File Sync is available in West US, West Europe, Southeast Asia, and Australia East to get started with the initial preview offering.

Azure Files itself has current file share limit of 5 TiB. Although Azure File shares are limited to 5 TiB, Azure File Sync can connect to as many shares as you need. This allows you to, as an example, split an on-premises file share across multiple Azure File shares to get around the 5 TiB limit.

Azure File Sync preserves discretionary ACLs (also known as DACLs), which are the ones that authorize user access to a file. Unfortunately, there is no support for ACLs directly in Azure Files, meaning that if you mount an Azure File share directly, rather than accessing your data through your Windows Server endpoint, Azure cannot enforce the ACLs. Azure can accomplish this by storing the ACLs privately so when you add multiple server endpoints to your sync group Azure can ensure that the ACLs exist on the files as expected.