AWS EFS: How I Finally Got Shared Storage Working Across Multiple Servers (and Regions)

I’ll be honest — the first time I tried setting up EFS, I spent two hours wondering why my EC2 instance couldn’t mount anything. Turned out I forgot to open port 2049 in the security group. Two hours. For one missing inbound rule. So if you’re here because something isn’t working, check that first before you do anything else.

This post covers everything I walked through in my  latest video:

creating an EFS file system, mounting it on Nginx servers, keeping the mount alive after reboots, peering across regions, and setting up replication. It’s a lot, but I’ll try to keep it practical rather than just copying the AWS docs.

So What Even Is EFS and Why Should You Care

If you’ve used EBS before, you already know the frustration. You provision a volume, attach it to one instance, and that’s it. Need another instance to access the same files? Now you’re thinking about snapshots, syncing scripts, or some other workaround that will absolutely break at 2am on a Sunday.

EFS is different. It’s a managed file system that multiple EC2 instances can mount at the same time. All of them read and write to the same place, in real time. No syncing. No snapshots. It just works — once you get the setup right, anyway.

The other thing worth knowing is that EFS is regional, not tied to a single availability zone like EBS is. So if one AZ goes down, your file system is still accessible. AWS handles that redundancy automatically. You don’t configure anything for it, which is a nice change of pace.

Storage also scales on its own. You don’t pick a size when you create it. It just grows as you add files and you pay for what you actually use. Coming from EBS where you’re constantly resizing volumes and running out of space at the worst times, this feels almost too easy.

EFS vs EBS vs S3 — The Quick Version

People overthink this. Here’s how I actually think about it:

Use EBS when you need fast block storage for one instance — databases, anything that needs raw IOPS, stuff like that.

Use EFS when multiple servers need to share the same files and you want it to feel like a normal file system. Web servers sharing content, ML nodes reading the same dataset, that kind of thing.

Use S3 when you don’t need to mount anything and you’re fine with API access. Backups, static assets, logs — S3 is great for all of that.

The mistake I see most often is people trying to use S3 for something that really needs EFS, then spending weeks building workarounds because their legacy app expects an actual file path.

Creating the File System

Go to EFS in the AWS Console, hit Create, and you’ll get through most of it pretty quickly. The network settings page is where people mess up.

You’re assigning mount targets to each availability zone. Each one needs a security group that allows inbound NFS traffic on port 2049. That’s the rule I missed my first time. No error message tells you clearly that this is the problem — your mount command just hangs and times out. So save yourself the frustration and set that rule before you even try to mount anything.

Also think about performance mode here. For most things, General Purpose is fine. If you’re running something with massive parallelism — big data jobs, media processing — Max I/O might be worth looking at, but you’ll trade some latency for throughput. Elastic Throughput is what I’d recommend for most people starting out because it scales automatically without you needing to guess what you need upfront.

Mounting on Your EC2 Instances

Once the file system is ready, SSH into your instance and install the NFS client or the amazon-efs-utils package if you’re on Amazon Linux. Then create a directory for the mount point and mount it:

sudo yum install -y amazon-efs-utils
sudo mkdir /mnt/efs
sudo mount -t efs fs-xxxxxxxx:/ /mnt/efs

Replace fs-xxxxxxxx with your actual file system ID. After that, anything you write to /mnt/efs on one instance shows up immediately on every other instance that has the same file system mounted. In the video I demonstrated this with two Nginx servers — I created an HTML file on one and refreshed the browser hitting the other. Instant. No delay.

That’s the moment it clicks for most people. You’re not copying files around anymore. They’re just… there.

Don’t Forget fstab

This is the part everyone skips and then complains about later. When you mount EFS manually, it works great until the instance reboots. Then the mount is gone and your application is broken.

Open /etc/fstab and add this line:

fs-xxxxxxxx:/ /mnt/efs efs _netdev,tls 0 0

The _netdev part tells the system to wait for the network before trying to mount. Without it, your instance might try to mount before the network is up and fail, which causes its own set of headaches. The tls option encrypts data in transit, which you should always have on.

After adding the line, run sudo mount -a to test it. If nothing breaks, you’re good. If it errors, fix it now — not after a reboot at 3am when everything is down.

Security Stuff You Shouldn’t Skip

I’m going to keep this section short because security configurations can fill an entire post on their own, but here are the things that actually matter:

Turn on encryption at rest when you create the file system. You can’t enable it after the fact without creating a new file system and migrating your data. Takes two seconds during creation, impossible to add later. Just do it.

Use TLS for encryption in transit — that’s the tls flag in your mount options above.

Lock down your security groups so only your application instances can reach port 2049. Don’t leave it open to 0.0.0.0/0 unless you enjoy getting paged at midnight.

Cross-Region Access with VPC Peering

Here’s where it gets interesting. In the video I walked through connecting an EC2 instance in Mumbai to an EFS file system in US-East. The short version is: you need VPC Peering, and you need to update your route tables or nothing will actually flow through the connection.

The peering part itself is straightforward — request the peering connection from one VPC, accept it from the other. Where people get stuck is the route tables. You have to add routes on both sides pointing to the other VPC’s CIDR range through the peering connection. Skip this step and the peering connection shows as Active but your traffic goes nowhere.

Once that’s done, mount EFS using the mount target’s IP address instead of the DNS name. The DNS name only resolves inside the file system’s home region, so cross-region you need the IP. It’s a small detail but it’ll save you another frustrating hour of debugging.

Replication for Disaster Recovery

Setting up EFS Replication is honestly one of the easier things in this whole guide. Go to your file system in the console, find the Replication tab, and choose a destination region. AWS handles the rest.

The replica is read-only while replication is running. If you actually need to fail over to it — because something went badly wrong in your primary region — you break the replication relationship and the replica becomes a standalone writable file system. It’s not automatic failover, so you’ll need to update your application config or DNS to point to the new region. But at least your data is there and intact.

I’d recommend setting this up for anything that matters. The cost is manageable and the alternative — losing data because a region had a bad day — is a lot worse.

Keeping Costs Under Control

EFS is not the cheapest storage option by default. A few things help:

Enable Intelligent Tiering or set up lifecycle policies to move files you haven’t accessed recently to the Infrequent Access storage class. The price difference is significant and most file systems have plenty of data that’s rarely touched.

Watch your throughput mode. Provisioned Throughput adds cost on top of storage. If you enabled it during testing and forgot about it, check your bill — it might be higher than expected.

Clean up old data. EFS charges for what’s stored, so a file system that’s accumulated years of stale data is quietly costing you money every month.

Things I Wish I Knew Earlier

A few lessons learned the hard way:

Port 2049. Always check it first.

Test your fstab entry with mount -a before you assume it’s fine. A broken fstab can prevent an instance from booting properly.

Cross-region mounts use IP addresses, not DNS names. Write that somewhere you’ll remember it.

Encryption at rest has to be set at creation time. There’s no enabling it later.

That covers everything from the video, plus a few extras. If something isn’t working for you, drop a comment — there’s a good chance I’ve run into the same issue. And if you want to see the full hands-on walkthrough rather than reading through all of this, above video shows every step in real time.