NAS in the cloud: file shares, costs, and migration

NAS in the cloud provides shared file storage over a network, usually through a managed service using SMB or NFS. It can replace an office file server or serve applications running in a cloud environment. For IT teams considering a move, the key questions are protocol compatibility, network performance, access permissions, and recovery. This guide compares the main approaches and explains what to test before migrating.

A service can remove the work of replacing hard drives while leaving you responsible for permissions, connectivity, backups, and costs. Choose around the applications that open the files and the people who maintain them.

What counts as cloud NAS?

Network-attached storage presents files and folders to clients on a computer network. A local NAS device supplies that service from hardware you operate. With managed cloud NAS, the provider operates the underlying file-storage infrastructure, and your clients reach a share through a supported network path.

Three deployment models commonly appear under this label:

• Managed cloud file storage: clients connect to a provider-operated file system. You select the service, capacity or performance settings, access rules, and protection policies.
• Hybrid storage: a local file server or gateway keeps some data nearby and connects to cloud storage. You still operate the local component.
• A self-managed file server in a cloud VM: you install and maintain the operating system and file-sharing software. Hosting it remotely does not remove patching or backup responsibilities.

A remotely accessible home NAS is another possibility. It remains your device, with dependencies on its power, disks, software, and network connection. Use its supported secure access method rather than exposing a file-sharing port broadly to the internet.

File storage, object storage, and sync apps

A file system has behavior beyond displaying folders: permissions, metadata, locking, and how concurrent changes are handled all matter. Our guide to cloud file-system architecture explains those requirements in more detail.

Object storage uses object APIs; a gateway can present a file interface over it, but the gateway's behavior needs testing. A storage area network, or SAN, generally presents block storage instead. Consumer sync apps such as Google Drive serve a different workflow again. A folder visible on a laptop does not, by itself, prove that a service can replace an application's SMB or NFS share.

Cloud NAS services to compare

Start with the protocol and operating system, then check the exact deployment option. Product names alone are too broad to establish compatibility. The examples below reflect provider documentation checked on October 12, 2026.

Service	File access	Useful starting point	Important check
Amazon EFS	NFS	Shared files for Linux applications on AWS	Regional or One Zone storage, throughput mode, and client support
Amazon FSx for Windows File Server	SMB	Windows file shares and Active Directory environments	Identity integration, provisioned performance, and availability configuration
Azure Files	SMB or NFS, depending on the share	Managed shares for compatible Windows or Linux workloads	Protocol-specific identity, networking, and feature support
Google Cloud Filestore	NFS	Shared file storage for Google Cloud workloads	Service tier, protocol version, capacity, and network path

Amazon EFS and FSx

Amazon EFS grows and shrinks with stored data and supports NFS clients. Windows-based EC2 instances are not supported. Its Regional and One Zone options have different failure exposure. For performance, AWS currently recommends General Purpose mode; the older Max I/O mode should not be treated as the default choice for demanding workloads. Check the EFS performance specifications separately from storage capacity.

FSx for Windows File Server provides managed Windows file systems with SMB and Active Directory integration. You choose storage and performance settings. Single-AZ and Multi-AZ configurations offer different availability characteristics, so record which one your estimate includes.

Azure Files

Azure Files supports SMB and NFS shares, but a single share does not serve both protocols. Authentication and supported features differ by protocol. Check the share's management model, media tier, and regional availability before treating a feature as universal.

For a hybrid Windows environment, Azure File Sync can synchronize Windows Server folders with an Azure file share and optionally keep frequently used files locally. Its deployment guidance limits File Sync to classic SMB shares; it is not an NFS synchronization service.

Google Cloud Filestore

Filestore supplies managed NFS file servers. Clients need a supported network route, such as the same VPC or a connected on-premises network. Its service tiers differ in capacity, performance, availability, and supported protocol versions. A zonal configuration should not be assumed to provide the same protection against a zone outage as a regional one.

Where Hivenet fits

Hivenet's storage page lists network storage for shared files and datasets through a sales conversation. For a NAS project, ask for the supported protocols, identity integration, region, performance limits, and recovery commitments for the proposed deployment. Store with Hivenet is described as everyday file storage and photo backup; those features alone do not establish compatibility with an application's network file share.

When a hybrid NAS makes sense

A hybrid design can be useful when applications remain in an office or data center and repeatedly use the same working files. A local cache can reduce remote reads, while cloud storage holds a larger dataset. This adds a local server or appliance that someone must monitor, update, and recover.

For example, Amazon S3 File Gateway exposes an SMB or NFS interface to S3-backed data and uses local caching. It is a gateway architecture with its own requirements, rather than evidence that every S3 bucket behaves like a native file server.

Test both a file already in the cache and one that must be retrieved. During a network outage, the files available locally and the ability to save changes depend on the specific product and configuration. Also test how multiple sites handle conflicting edits. Synchronization does not automatically provide a shared real-time lock across independent servers.

Performance: test the workload and the route

Moving the application close to its storage can produce a different result from leaving the application on an office laptop. “Cloud” alone does not tell you how far each file operation travels. Bandwidth, latency, client configuration, file size, concurrency, and the selected service all affect the result.

A folder containing thousands of small files can be slow even when a single large transfer is fast. Opening, listing, and checking permissions may involve many operations. Measure a representative task, such as opening a project or completing a build, alongside throughput and operation latency. Include peak concurrent use.

Test	What it reveals	What to record
Large sequential transfer	Sustained transfer behavior	Dataset size, elapsed time, route, and concurrent traffic
Many small files	Metadata and per-operation overhead	File count, directory depth, and application completion time
Two clients editing	Locking and conflict behavior	Whether the application blocks, warns, or overwrites
Cold-cache access	Dependence on remote retrieval	First-open time and behavior when connectivity fails
Restore a working folder	Practical recovery capability	Restored permissions, usable files, and elapsed time

Define acceptable results before the trial. A media team may care about playback and save times; a build system may care about metadata operations and job completion. Database storage needs explicit application support and testing, even when the mount succeeds.

Remote access needs network planning

Cloud NAS is not universally reachable from any internet connection. For example, Azure Files networking guidance notes that SMB uses TCP port 445, which some networks block. VPN or other private connectivity can provide a supported path. NFS access has separate network restrictions.

Document routing, DNS resolution, firewall rules, and the approved client configuration. Keep a supported encrypted connection; opening wider access to solve a connection problem can create a separate security problem. Test with ordinary user accounts and from each location that will use the share.

Compare the full storage cost

Managed storage removes a hardware purchase from one part of the budget, but introduces service charges and may leave local costs in place. Some products charge for consumed data; others require provisioned capacity or performance. A nearly empty share can still incur a meaningful bill.

Include these items in the estimate:

• Capacity: live data, retained snapshots, backup copies, growth, and minimum provisioned sizes.
• Performance: selected throughput, IOPS, or service tier, including temporary migration requirements.
• Networking: VPNs, private links, cross-region traffic, data transfer, and local bandwidth.
• Operations: monitoring, support, identity services, gateway hardware, licenses, and staff time.
• Recovery and exit: restoring a full dataset, keeping parallel systems during a move, and transferring data elsewhere.

Compare the same period and protection requirements for local and cloud options. The cloud storage cost guide provides a way to look beyond the headline capacity price. For NAS, add the file-service and connectivity costs specific to the proposed setup.

For an illustrative 10 TB dataset, start with the active data, then add the actual retention policy and measured change rate. Do not assume snapshots consume another complete 10 TB or that they use no extra space. Ask how the chosen service measures and bills them. Price a normal month and a month containing a full recovery or export.

File-storage tiers are service-specific

A generic table promising that “infrequent access” takes minutes or that every archive takes hours is misleading for cloud NAS. EFS, for example, documents different first-byte latency characteristics for Standard, Infrequent Access, and Archive. Those classes should not be confused with S3's restore-before-access archive options.

Before enabling automated tiering, check retrieval behavior, access charges, minimum storage duration, and whether metadata remains on a different tier. Run a trial that includes older files. A policy based on age alone can move rarely opened but time-critical material into an unsuitable configuration.

Permissions, encryption, and recovery

Map access before copying files. Windows ACLs, group membership, and Linux user and group IDs need deliberate handling. A transfer can preserve file contents while changing who can read or modify them. Test a permitted user, a read-only user, and a user who should be denied access.

Check encryption at rest and in transit separately, including the clients and mount settings needed to enforce it. Provider-managed encryption does not establish end-to-end encryption or guarantee that the provider cannot access data. Record who controls the keys and what happens if that account or key becomes unavailable.

Replication can help with infrastructure failure, while snapshots and backups provide recovery options under their own retention and access rules. A synchronized deletion can still spread to another copy. Our explanation of sync and backup covers this distinction.

Set a recovery point objective, meaning the amount of recent work you can lose, and a recovery time objective, meaning how long restoration can take. Use recovery testing to check them. Restore into a separate location, open the files in the real application, and confirm permissions as well as content.

For data-location requirements, verify the chosen region and the locations of backups, replicas, and administrative access. Record the applicable service terms instead of inferring compliance from a regional selector or certification badge.

A practical NAS migration sequence

Use a staged migration with a named owner and a rollback decision. A successful copy is one checkpoint; the application must also work against the destination.

1. Inventory the source. Record shares, owners, file counts, used capacity, permissions, locked files, and application dependencies. Measure current usage and completion times.
2. Select a compatible target. Confirm protocol version, locking, filename rules, identity integration, quotas, region, and recovery options. Set a cost limit for the trial.
3. Build a small test environment. Use representative, non-sensitive sample data. Configure network access, encryption, ordinary user permissions, and monitoring.
4. Test the copy method. Confirm what happens to timestamps, ACLs, ownership, symbolic links, and unsupported file types. Review errors and compare file counts and checksums where supported.
5. Test the application and restore. Include concurrent users, older files, a denied-access check, and recovery from a retained copy. Record results against agreed thresholds.
6. Plan the cutover. Define when writes to the source stop, how the final changes are copied, and how users reconnect. Avoid leaving two independently writable sources of truth.
7. Retain a controlled rollback copy. Verify the destination over an agreed period before decommissioning the source. Document ongoing access reviews, backup checks, and billing ownership.

Migration tools can help with the transfer. AWS DataSync, for example, supports transfers involving SMB and NFS sources and several AWS storage destinations. Verify the exact source-to-destination combination and metadata behavior before scheduling a production move.

Choosing a deployment

Managed cloud NAS is a reasonable candidate when applications need shared file access and your team wants the provider to operate the storage infrastructure. A hybrid design may suit office workloads that need local access to active files. Existing local storage may remain the better choice when connectivity or application requirements make a remote share impractical.

Choose after a small trial demonstrates usable performance, correct permissions, successful recovery, and an acceptable total bill. Keep those results with the configuration so the next capacity or migration decision starts with evidence from your own workload.