EFS: Shared File Storage for Linux

Amazon Elastic File System (EFS) is a fully managed, elastic, shared POSIX file system that can be mounted by thousands of EC2 instances, Lambda functions, and ECS/EKS containers simultaneously. Unlike EBS (which attaches to a single instance), EFS provides a shared file system where all connected clients see the same files in real time. Capacity grows and shrinks automatically — you never provision storage upfront. EFS is ideal for content management, shared code repositories, home directories, and data analytics.

EFS offers two storage classes: EFS Standard (multi-AZ, highest availability, sub-millisecond latency) and EFS One Zone (single AZ, 47% lower cost, slightly less resilient). Within each tier, there is also an Infrequent Access (IA) variant that stores data at 92% lower cost than Standard for files that are not accessed regularly. The difference from S3: EFS is a full POSIX file system that your applications can mount — it is not an object store.

EFS has two performance modes: General Purpose (default, recommended for most workloads — lowest latency, ideal for web serving, content management, home directories) and Max I/O (designed for massively parallel workloads with thousands of concurrent connections at the cost of slightly higher latency, ideal for big data and media processing). Performance mode is set at creation and cannot be changed after the file system is created. For the SAA-C03 exam, choose Max I/O only when you explicitly need thousands of parallel connections.

EFS supports three throughput modes: Elastic (automatically scales throughput up and down based on workload — recommended for most use cases, billed per GB transferred), Bursting (throughput scales with storage size, earns and consumes burst credits like EC2 T-series — free baseline), and Provisioned (you specify a fixed throughput regardless of storage size — useful when you need consistent throughput beyond what Bursting provides). Elastic mode is the modern default and eliminates the need to plan throughput capacity.

To access an EFS file system from an EC2 instance, you create a mount target in each subnet (AZ) where your instances run. For EFS Standard, you should create a mount target in each AZ in your VPC — EC2 instances connect to the mount target in their own AZ for the lowest latency. Mount targets have security groups that must allow NFS traffic (port 2049 TCP) from the instance's security group. Without this inbound rule, mount operations will time out.

The recommended way to mount EFS on EC2 is using the Amazon EFS Mount Helper (amazon-efs-utils package), which supports TLS encryption in transit and automatic reconnection. You mount using the file system ID rather than the IP address so DNS resolves to the nearest AZ mount target automatically. For persistent mounts that survive reboots, add the mount entry to /etc/fstab using the _netdev option to ensure the network is available before mounting.

EFS Access Points are application-specific entry points into an EFS file system that enforce a specific POSIX user, group, and root directory for all connections using that access point. This allows multiple applications on the same file system to be isolated from each other — Application A mounts via Access Point A and only sees /data/app-a/, while Application B using Access Point B only sees /data/app-b/. Access Points are the recommended way to grant Lambda functions, ECS tasks, and EKS pods isolated access to shared EFS file systems.

EFS Intelligent-Tiering automatically moves files between Standard and Standard-IA (Infrequent Access) storage classes based on access patterns. You configure a lifecycle policy — for example, move files to IA after 30 days without access. When a file in IA is accessed again, it is automatically moved back to Standard. The retrieval from IA has a per-GB retrieval fee but costs significantly less for storage. This is similar to S3 Intelligent-Tiering and eliminates the need to manually manage file placement.

Lambda functions can mount EFS file systems to share large model files, persistent data, or configuration across invocations — overcoming the 512 MB-10 GB /tmp limit. ECS and EKS tasks mount EFS via persistent volume claims using the EFS CSI driver. The Lambda function or container must be in a VPC that has a mount target, and the EFS security group must allow inbound NFS from the Lambda or container VPC security group. EFS + Lambda is a common pattern for sharing trained ML models across function instances.

The SAA-C03 exam frequently asks you to choose between EFS and EBS. EFS: POSIX shared file system, mounts on multiple EC2 instances simultaneously, elastic capacity, Linux only (NFS), accessible by Lambda and containers, higher cost per GB. EBS: block device, attaches to a single EC2 instance (except io1/io2 Multi-Attach), fixed provisioned size, both Linux and Windows, not natively accessible by Lambda, lower cost per GB. If the scenario says 'multiple instances must share the same files', the answer is EFS.

EFS supports encryption at rest (enabled at file system creation using a KMS key — cannot be changed after creation) and encryption in transit (TLS encryption when using the EFS mount helper with the tls option). AWS recommends enabling both. You can enforce in-transit encryption using an EFS resource-based policy that denies mount without TLS by requiring the elasticfilesystem:ClientRootAccess and elasticfilesystem:ClientWrite conditions.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: EFS is a shared POSIX file system that can be mounted on thousands of instances and Lambda functions simultaneously with elastic capacity, Access Points provide per-application isolation with enforced POSIX user and root directory, and Intelligent-Tiering automatically moves infrequently accessed files to a lower-cost IA storage class. Next up we explore FSx for Windows File Server and Lustre for specialised workloads.