EFS & FSx Shared File Systems

## The problem EFS solves Once a service runs on more than one instance behind a load balancer, any state written to a local disk becomes wrong: an upload handled by instance A is invisible to instance B, and it disappears when the Auto Scaling group replaces A. The three AWS answers are object storage (S3), block storage attached to one instance, and a shared file system. Amazon EFS is the shared file system. ## What EFS actually is EFS is a managed implementation of NFS version 4.1 (4.0 is also accepted). Concretely: - **One namespace, many writers.** Every client mounting the file system sees the same directory tree at the same time. Reads and writes are visible to other clients, and NFSv4 byte-range locking works, so cooperating processes on different hosts can coordinate. - **POSIX semantics.** Files have owners, groups, mode bits, symlinks, timestamps and directories. Software written for a local filesystem — a CMS writing `wp-content/uploads`, a Git server, a training job checkpointing to a path — runs unmodified. - **Elastic capacity.** There is no size to choose. The file system grows as you write and shrinks as you delete, and you pay per GB-month actually stored. That is the single biggest operational difference from provisioning a fixed-size volume you must monitor and resize. - **Regional by default.** A standard EFS file system stores data redundantly across multiple Availability Zones in the Region. (A cheaper `One Zone` variant keeps data in a single AZ and accepts the corresponding risk.) ## How clients reach it EFS lives inside your VPC. For each Availability Zone you create a **mount target**: an elastic network interface with a private IP in a subnet of that AZ, protected by a security group. Clients mount the file system's DNS name, and NFS traffic flows over TCP port 2049 to that interface. Because the network path is a normal VPC path, there is no internet gateway or NAT involved. A typical mount using the `amazon-efs-utils` package looks like: ```bash sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/shared ``` The `-o tls` option routes the NFS session through a local stunnel process so the traffic is encrypted in transit; encryption at rest is a checkbox set when the file system is created. EFS is not EC2-only. ECS and Fargate tasks can declare an EFS volume in the task definition, and a Lambda function can mount an EFS access point under `/mnt`, which is how people give a function a large model file or dependency set that will not fit in a deployment package. ## What it costs you Two things make EFS the wrong default rather than the obvious default: 1. **Latency.** Every file operation is a network round trip to a distributed service. Per-operation latency is an order of magnitude above a locally attached block device, and metadata-heavy work (`find` over millions of small files, an `npm install` into an EFS path, a build tree) feels dramatically slower than the same work on local storage. 2. **Price per GB.** EFS Standard storage costs several times object storage per GB-month. Storing bulk media on it because "the code already writes files" is a common and expensive mistake. ## When something else is the right answer - **S3** when the data is whole objects written once and read many times — user uploads, images, backups, data-lake files. It is cheaper, effectively unbounded, serves as a CloudFront origin, and lets browsers upload directly with presigned URLs. The cost of choosing it is that your code must speak the object API: no partial in-place writes, no rename, no directories. - **A block volume attached to one instance** when a single writer needs the lowest possible latency — most obviously a self-managed database's data directory. Running a relational database's data files on NFS is the classic misuse of EFS. - **FSx** when you need a file system EFS does not speak: SMB with Active Directory permissions for Windows applications, or a parallel file system for HPC-scale throughput. The interview test is simple: choose EFS when multiple hosts genuinely need concurrent POSIX access to the *same* mutable tree. If only one host writes, or the access pattern is really "fetch an object by key", EFS is the expensive answer to a question you did not have.