Four cloud workloads where SMB still wins, and why it matters for your platform

Windows and macOS have never stopped relying on SMB. Roaming profiles, home folders, redirected folders, mapped drives, centralized application settings: all of it moves over SMB. That has not changed as organizations have shifted their infrastructure to the cloud, and it is not going to. So as cloud service providers build out file services for enterprise customers, the protocol question is not going away. AWS, Microsoft, and Google have all shipped SMB-backed services for exactly this reason, and each of them has effectively said the same thing: to serve Windows and macOS clients properly, you need SMB, and you need it to be reliable at scale.

The catch is that SMB is genuinely hard to get right in a multi-tenant, highly available cloud environment. It is easy to set up a basic file share. It is much harder to guarantee data integrity under load and survive node failures without interrupting active sessions. That gap is where the opportunity, and the risk, sits for CSPs building these services.

Key takeaways

• Windows and macOS still run on SMB. Moving to the cloud does not change that.
• Four CSP workloads turn SMB into revenue: managed clusters, PaaS, Windows VDI, and internal infrastructure.
• VDI has no NFS alternative. Windows cannot host profiles or settings on NFS.
• Standing up a share is easy. Holding data integrity under load and surviving node failures is not.
• In published benchmarks, Fusion SMB read over 10 times faster than Samba on identical hardware.

Here are four workloads where SMB support creates a clear opportunity, and what separates a production-grade SMB implementation like Tuxera Fusion from a do-it-yourself Samba deployment.

1. Managed SMB clusters

This is the highly available, scale-out file server offered as a managed service. Customers get enterprise file serving for Windows and macOS clients without babysitting a file server themselves, whether those clients sit on-premises, in a hybrid setup, or run as VMs in the cloud.

Offering this as a managed service, rather than pointing customers at a bare IaaS file server they have to configure and scale themselves, is real, monetizable value on top of infrastructure that would otherwise commoditize.

What matters at the implementation layer: data integrity (Direct I/O guarantees writes land correctly, instead of relying on caches that can corrupt data under failure), high availability (active-active scale-out with persistent handles and transparent failover, so a node failure does not interrupt service), and cost efficiency (modern multi-threading instead of a per-client process model means better density on the same hardware, and better margins for the provider). In published benchmarks, Fusion SMB delivered over 10x the read throughput of Samba on 200GbE on identical hardware, and closer to 20x on 400GbE.* In heavy access workloads, it used up to 90% less CPU and 92% less memory,** which translates directly into that density advantage.

File systems play a large role in network delivery. Fusion’s VFS layer directly interfaces and optimises the throughput. For example, using Fusion over a CEPH filesystem delivers 14.8 GB/s vs 1.67 GB/s for Samba.

Contracted support with a real SLA matters too, especially at enterprise scale, where customers expect a committed response time rather than a community forum.

2. Managed SMB PaaS

This is the fully native, cloud-service version of SMB, where the file server itself disappears into the platform. Customers get highly scalable file serving for Windows and macOS without provisioning or managing any server at all.

Beyond the same data integrity and high-availability requirements as managed clusters, PaaS-grade SMB needs to handle demanding workloads gracefully and elastically, since customers expect the service to scale with them rather than requiring a re-architecture at some threshold. RDMA networking support, for instance, is what makes SMB viable for HPC-adjacent use cases such as AI data ingestion pipelines and media and entertainment production, running natively in the cloud rather than being routed around it.

3. SMB for Windows VDI

Virtual desktop infrastructure has a structural problem: the VM is ephemeral, but the user’s settings, roaming profile, and data are not supposed to be. Every time a session ends, the underlying machine can disappear, and the next login needs to feel like picking up exactly where the user left off.

It is worth noting that there is no NFS alternative here. SMB is the only option, which makes the quality of the SMB implementation directly load-bearing for the VDI experience. Persistent handles and transparent fail-over prevent a node hiccup from disrupting an active desktop session, and SMB over QUIC adds another layer of security that increases value at the edges of that picture: for remote and mobile VDI clients connecting in over the open internet before their traffic ever reaches the tenant’s own network boundary.

4. SMB for internal cloud infrastructure

This one is easy to overlook: a CSP is also just an IT organization. Its own employees run Windows and macOS desktops and need file servers for the same reasons any enterprise does, including shared drives, home directories, and centrally managed settings. And behind the scenes, cloud platforms move enormous volumes of data for infrastructure purposes, such as staging and shuttling data behind VM operations, distributing golden images to hypervisor hosts, and collecting logs and telemetry from fleet machines.

SMB is the only protocol that works natively and at speed across Windows, macOS, and Linux, which makes it the practical choice for this kind of internal infrastructure workload, with the same requirements for compression, scale-out clustering, and fail-over that show up everywhere else on this list. It is a less visible workload, but the operational cost of getting it wrong internally is just as real.

The common thread

Across all four workloads, the pattern repeats: Windows and macOS clients need SMB, and the quality of the SMB layer, meaning its data integrity guarantees, its availability under failure, its performance density, and the support behind it, determines whether that workload becomes a differentiated, margin-positive service or a support burden that quietly erodes the business case.

Tuxera Fusion SMB is designed to close that gap, handling CSP production workloads offering throughput, efficiency, security, and scale.

• * Throughput test rig. Server: Ubuntu 24.04.4 LTS, kernel 6.8.0-111-generic, 2x Intel Xeon Gold 6526Y (16 physical cores per socket, 64 logical processors), 8x Samsung MZQL21T9HCJR-00A07 NVMe in RAID-0, XFS at /mnt/raid0. Client: Ubuntu 24.04.4 LTS, kernel 6.17.13-smbdirect, 1x Intel Xeon Gold 6526Y (16 physical cores, 32 logical processors).
• ** CPU and memory test rig. Ubuntu 24.04.4 LTS, Intel Xeon Gold 6226R at 2.90 GHz, 32 physical cores, 500 Docker containers running on a remote client.
• *** Fusion SMB 3026.4.1 prerelease with an updated CephFS module using libcephfs, tested over TCP and RDMA/SMB Direct. Samba 4.24.0 with its new low-level VFS module (vfs objects = ceph_new) and the previous module (vfs objects = ceph), tested over TCP. Cluster: CephFS on 8 OSDs (Samsung NVMe), 200GbE network, Windows Server 2025 client.