Skip to content
Notifications
Clear all

Has anyone benchmarked Azure Files against EFS for shared home directories?

4 Posts
4 Users
0 Reactions
1 Views
 bobC
(@bobc)
Trusted Member
Joined: 1 week ago
Posts: 44
Topic starter   [#16318]

Hi everyone! New to the forum, but I've been deep in the helpdesk side of things lately.

We're moving our team's dev environment to the cloud and need a solid solution for shared home directories. I keep seeing Azure Files and AWS EFS as the main options. The official docs have specs, but I'm looking for real-world experience.

Has anyone run performance benchmarks between them, specifically for this use case? I'm especially curious about latency during peak hours when many engineers are accessing the same mount, and how the cost models compare for lots of small, frequent file operations. Any gotchas from your own deployments would be amazing to hear about!

Thanks in advance



   
Quote
(@backend_latency_queen)
Reputable Member
Joined: 2 months ago
Posts: 159
 

We tested both for a similar use case with around 100 concurrent developers. The latency profile for lots of small files was the real differentiator.

Azure Files Premium with SMB multichannel was consistently under 5ms for stat/open operations during our load tests, while EFS (Standard, Provisioned Throughput) saw occasional spikes to 20-30ms during concurrent git operations. This was with a working set of thousands of small config and source files.

Cost-wise, watch out for the "burst credits" model on EFS. For a dev home directory pattern with spiky activity, we found Azure Files' straightforward provisioned IOPS more predictable. EFS can get expensive if you consistently exceed your baseline throughput.

A major gotcha for EFS: watch your mount target security group configs and NFS client settings. A misconfigured `rsize/wsize` tanked our initial performance. Azure Files was simpler to lock down with just private endpoints.


sub-100ms or bust


   
ReplyQuote
(@code_reviewer_anna)
Estimable Member
Joined: 3 months ago
Posts: 122
 

Great to see actual latency numbers from a real test! That's super helpful.

The mount config issues with EFS ring so true. We've seen teams miss the `noresvport` NFS option on Linux clients, which causes instability during failover. Azure Files SMB is definitely simpler to get right from an endpoint and permissions standpoint.

One thing I'd add: if your dev workflow involves lots of `git status` or file watching (like IDE auto-saves), those small operation latencies compound quickly. EFS's occasional 30ms spikes can make a terminal feel sluggish, while a steady 5ms is often unnoticeable.


Clean code is not an option, it's a sanity measure.


   
ReplyQuote
(@finnj)
Estimable Member
Joined: 6 days ago
Posts: 57
 

Hang on, let's not anoint SMB as the paragon of simplicity just yet. While the endpoint config is simpler, you're now trading NFS quirks for the delightful world of SMB permissions and credential management, which can be its own special kind of hair-pulling.

Also, the whole "steady 5ms vs spiky 30ms" argument is valid, but it assumes you're comparing the highest, most expensive tier on Azure to maybe a mid-tier EFS setup. The moment you try to cut costs on Azure Files, you'll find your own latency spikes. The predictability comes with a price tag that's rarely mentioned in these side-by-side charts.

The real contrarian move? Skip the cloud filesystem premium altogether for dev home dirs. A halfway-decent self-hosted NFS server on a decent instance often beats both on cost and, ironically, consistency. But that's a conversation the cloud vendors would rather we not have.


FOSS advocate


   
ReplyQuote