EFS and Choosing Between EBS, EFS and Instance Store

By the end of this lesson you will be able to

• Tell block, file and object storage apart, and say which AWS service gives each one.
• Explain what Amazon EFS is: a managed NFS file system that many Linux instances in several Availability Zones mount at the same time.
• Connect instances to EFS through mount targets and security groups, and fix a mount that hangs.
• Choose between Regional and One Zone file systems, General Purpose and Max I/O, and the Elastic, Provisioned and Bursting throughput modes, using today’s AWS defaults.
• Use the Standard, Infrequent Access and Archive storage classes with lifecycle management, and work out what it really saves.
• Secure EFS with encryption, access points and IAM, protect it with AWS Backup and replication, and know when FSx is the answer instead.
• Pick EBS, EFS or instance store (or FSx) from any exam scenario.

#Three ways to store data

Lessons 5.1 to 5.3 covered two kinds of disk an EC2 instance can use: EBS volumes and instance store. Both are block storage. Before adding EFS, it helps to have one clear model of the three ways storage can be offered.

#What Amazon EFS is

Amazon Elastic File System (EFS) is a managed network file system. You create a file system, and EC2 instances mount it with the standard Linux NFS client, exactly like a shared drive on an office network. AWS runs the servers, the disks, the replication and the scaling.

• Protocol: NFS version 4.0 and NFSv4.1, over TCP port 2049.
• Shared: hundreds or thousands of instances can mount the same file system at once and read and write the same files. Containers and Lambda functions can mount it too, and on-premises servers can reach it over Site-to-Site VPN or Direct Connect.
• Across AZs: a Regional file system stores its data redundantly in at least three Availability Zones, and instances in every AZ of the Region can use it at the same time.
• Linux only: EFS works with Linux instances (and EC2 Mac instances). It is not supported on Windows. It behaves like a Linux file system: POSIX permissions (owner, group, read/write/execute), directories, and NFSv4 file locking.
• Elastic size: there is no size to choose. The file system grows when you add files and shrinks when you delete them, up to petabytes. You never run out of space and never pay for empty space.
• Pay per use: you pay for the GB you actually store each month (plus, depending on the throughput mode, for throughput). There is nothing to provision.

#How instances reach EFS: mount targets

An EFS file system lives at Region level, but instances live in subnets. The bridge between them is a mount target.

1. One mount target per AZ

   A mount target is a network interface that EFS places in one subnet of your VPC, with a private IP from that subnet. A Regional file system can have one mount target in each AZ (never two in the same AZ). Create one in every AZ where instances will mount the file system; mount targets are free.

2. A security group on the mount target

   Each mount target has one or more security groups. The rule that matters is inbound TCP 2049 (NFS) from the instances, best written with the instances’ security group as the source. The instances need outbound 2049 to the mount target, which the default “allow all outbound” rule already gives.

3. Mount by name

   On the instance you mount the file system by its DNS name, fs-0abc1234.efs.us-east-1.amazonaws.com. Inside the VPC (with DNS resolution and DNS hostnames turned on) that name resolves to the mount target in the instance’s own AZ, so the traffic stays inside the AZ. The easiest way is the EFS mount helper (the amazon-efs-utils package): sudo mount -t efs -o tls fs-0abc1234:/ /mnt/efs.

Mounting through a mount target in another AZ works, but each GB that crosses the AZ boundary costs the usual cross-AZ data transfer ($0.01 per GB in each direction) and adds latency. Use the local mount target.

#When the mount hangs

A blocked NFS port does not produce a neat “access denied”. A security group simply drops the packets, so the mount command waits and then fails with “Connection timed out”. Check, in this order:

#What EFS costs, compared with EBS

EFS charges for the average GB stored per month, in each storage class. Prices below are for us-east-1 at the time of writing; other Regions differ, so always check the pricing page.

So per GB, EFS Standard costs almost four times as much as gp3. That is the note’s point that “EFS storage is a bit expensive”. But compare the whole picture:

• With EBS you pay for the size you provision, used or not. A 1 TB gp3 volume holding 400 GB still costs $80.
• With EFS you pay only for the GB actually stored, and nothing is ever full.
• Three instances that each need the data would need three EBS volumes (and a way to keep them in sync). One EFS file system serves all of them.
• With lifecycle management (below), cold files drop to IA or Archive and the average price per GB falls a long way.

#Regional or One Zone

When you create a file system, you choose its type:

The notes call One Zone a “storage class”. In today’s console it is a file system type you pick at creation; it cannot be changed later. The two One Zone storage classes inside it are One Zone and One Zone-IA.

#Performance: performance mode and throughput mode

Two separate settings decide how fast a file system is.

#Performance mode: always General Purpose

Older courses say “use Max I/O for big data and thousands of instances”. That advice is out of date: General Purpose with Elastic throughput now reaches hundreds of thousands of read operations per second (and more on request), so AWS recommends General Purpose everywhere. If an exam option still offers Max I/O for “highly parallel, can tolerate higher latency”, recognise it as the legacy answer.

#Throughput mode: how many MiB per second

A few numbers to feel Bursting: 100 GiB in Standard earns about 5 MiB/s of write baseline (reads are metered at one third, so about 15 MiB/s). After a quiet day it has enough credits to burst at 100 MiB/s for about 72 minutes. File systems over 1 TiB can burst half of the time. Every file system gets at least 1 MiB/s.

The ceilings are much higher with Elastic. A Regional file system on Elastic throughput can read at 20–60 GiB/s and write at 1–5 GiB/s in total, depending on the Region, compared with 3–5 GiB/s reads on Bursting. A single client tops out at 1,500 MiB/s with the current EFS mount helper (500 MiB/s otherwise). Older slides quote 3 GiB/s reads and 1 GiB/s writes for Elastic; those limits have since been raised.

#Storage classes and lifecycle management

Most files are busy for a few days or weeks and then hardly ever opened again. EFS lets that cold data sit in cheaper storage classes without any change for the application.

#Lifecycle policies

Lifecycle management moves files between classes based on how long ago each file was last accessed in Standard. A file system has three lifecycle policies:

Details that exam questions and bills both care about:

• EFS uses its own access timer, reset whenever a file in Standard is read or written. Metadata operations such as listing a directory or checking attributes do not count as access.
• File names, ownership and the directory tree always stay in Standard, so browsing feels the same.
• Writes to a file in IA or Archive go to Standard first and become eligible to move again 24 hours later.
• With Transition into Standard = None, every read of a cold file pays the access charge and the higher latency. Set On first access for files that may become hot again (for example many small files read by an application), so the file moves back and later reads are fast and free of access charges.
• A file system created through the CLI or API has no lifecycle policy until you add one with put-lifecycle-configuration.
• Policies apply to the whole file system, not per folder.

#Worked example: does IA really save 92%?

The notes say EFS-IA costs about 92% less than regular EFS. Check it against today’s us-east-1 prices:

• IA on a Bursting or Provisioned file system: $0.025 ÷ $0.30 = 8.3%, so about 92% less. The note is right for that case.
• IA on an Elastic file system (the console default): $0.016 ÷ $0.30 = 5.3%, so about 95% less.
• Archive: $0.008 ÷ $0.30 = 2.7%, so about 97% less.

That is the price per GB. The saving on the bill is smaller, because hot data stays in Standard and cold data has access charges. Take a 1,000 GB Regional file system with Elastic throughput, where only 200 GB is touched in any given month:

So lifecycle cuts this bill by about 76%, not 92%, and the Archive step adds a little more. (Elastic throughput charges for reads and writes are the same in every row, so they are left out.) The more of your data is truly cold, the closer you get to the per-GB figure; on data that is touched every week, access and tiering charges can eat the saving.

#Security

#Encryption

• At rest: EFS encrypts data and metadata with an AWS KMS key, the AWS managed key aws/elasticfilesystem or your own customer managed key. The console turns it on by default; through the CLI or API you must ask for it (--encrypted). It can be set only when the file system is created. To encrypt an existing unencrypted file system, create a new encrypted one and copy the data across.
• In transit: mount with the EFS mount helper and the tls option. The helper wraps the NFS traffic in TLS 1.2 (still on port 2049). To make TLS compulsory, add a file system policy that denies access when aws:SecureTransport is false; the console offers this as “Enforce in-transit encryption for all clients”.

#Who may mount and what they may do

Three layers work together:

1. Network: security groups and NACLs decide which machines can reach port 2049 at all.
2. IAM: an EFS file system policy (a resource policy) plus the instance’s IAM role decide whether a client may mount, write, or act as root (ClientMount, ClientWrite, ClientRootAccess). Mount with -o tls,iam so the client presents its IAM identity. Ready-made options include preventing root access, enforcing read-only access and denying anonymous access.
3. POSIX permissions: inside the file system, normal Linux owner, group and mode bits apply, just as on a local disk.

#Access points

An access point is an application-specific entry into the file system. It can:

• force every request through it to use a fixed POSIX user ID and group ID, whatever the client claims;
• expose only one directory as the root (for example /apps/billing), creating it with chosen owner and permissions if it does not exist;
• be named in IAM policies, so the billing application’s role may mount only the billing access point.

Access points are the clean way to let several applications, containers or Lambda functions share one file system without seeing each other’s data.

#Protection: backups and replication

• AWS Backup: daily incremental backups with 35-day retention under the default EFS backup plan. Automatic backups are on by default for file systems created in the console, and for One Zone file systems from any tool; for Regional file systems created by CLI/API, turn them on (--backup). Restores can bring back the whole file system or single files, to a new or existing file system, even in another AZ or Region. Restored files land in Standard.
• EFS Replication: keeps a read-only copy of the file system in another Region (or the same Region), continuously, with a recovery point objective of 15 minutes for most file systems. In a disaster you fail over by deleting the replication configuration, which makes the copy writable, and point clients at it. The copy can be Regional or One Zone.

#EFS or FSx?

EFS is the general-purpose shared file system for Linux. Amazon FSx offers fully managed versions of other well-known file systems for the cases EFS does not cover. The details come in a later chapter; for now know the two that appear most:

#Choosing between EBS, EFS and instance store

#The full comparison

#How to choose

1. Windows server sharing files?

   Shared files for Windows → FSx for Windows File Server. EFS does not support Windows.

2. Several instances need the same files at the same time?

   Yes, Linux → EFS (Regional for production; One Zone for dev/test). If it is HPC on data in S3 → FSx for Lustre.

3. Can the data be lost when the instance stops or the host fails?

   Yes, it is a cache, buffer or scratch space you can rebuild, and you need the highest IOPS → instance store (on an instance type that has it).

4. Otherwise

   One instance, data must persist, boot volume or database → EBS (gp3 by default, io2 for the highest sustained IOPS, st1/sc1 for cheap sequential data). Several instances in one AZ sharing one block device with a cluster-aware application → io2 Multi-Attach.

#Worked exam scenarios

#How EFS is used in system design

• Web fleets behind a load balancer: WordPress, Drupal and other CMS sites put uploads, themes and plugins on EFS so any instance can serve any request and Auto Scaling can add or remove instances freely.
• Shared home directories and development environments for Linux users.
• Containers and serverless: tasks and Lambda functions that come and go need state that outlives them; an access point per application keeps them apart.
• Content and media workflows: several processing servers read and write the same project folders.
• Machine learning: training and inference nodes load the same datasets and models.

Where EFS is the wrong tool:

• Databases with heavy small random writes: every operation crosses the network to a distributed file system, so latency is higher than on EBS. Use EBS (or a managed database).
• Windows: use FSx for Windows File Server.
• Archives and public assets served over HTTP: S3 is far cheaper per GB and scales to any number of clients.
• Scratch space that needs the very lowest latency: instance store.

#Try it yourself

# 1. Security groups: instances (sg-web) and mount targets (sg-efs, inbound NFS from sg-web)
aws ec2 create-security-group --group-name sg-efs --description "EFS mount targets" --vpc-id $VPC
aws ec2 authorize-security-group-ingress --group-id $SG_EFS \
  --protocol tcp --port 2049 --source-group $SG_WEB

# 2. A Regional, encrypted file system with Elastic throughput and automatic backups
FS=$(aws efs create-file-system --creation-token shared-web-1 \
  --performance-mode generalPurpose --throughput-mode elastic \
  --encrypted --backup --tags Key=Name,Value=shared-web \
  --query FileSystemId --output text)
aws efs describe-file-systems --file-system-id $FS \
  --query "FileSystems[0].[LifeCycleState,ThroughputMode,PerformanceMode,Encrypted]"

# 3. One mount target per AZ (one subnet in each)
for SUBNET in $SUBNET_A $SUBNET_B $SUBNET_C; do
  aws efs create-mount-target --file-system-id $FS --subnet-id $SUBNET --security-groups $SG_EFS
done
aws efs describe-mount-targets --file-system-id $FS \
  --query "MountTargets[].[AvailabilityZoneName,IpAddress,LifeCycleState]"

# 4. Lifecycle: IA after 30 days, Archive after 90, back to Standard on first access
aws efs put-lifecycle-configuration --file-system-id $FS --lifecycle-policies \
  TransitionToIA=AFTER_30_DAYS TransitionToArchive=AFTER_90_DAYS \
  TransitionToPrimaryStorageClass=AFTER_1_ACCESS

# 5. An access point for one application: fixed POSIX identity and its own directory
aws efs create-access-point --file-system-id $FS \
  --posix-user Uid=1001,Gid=1001 \
  --root-directory "Path=/apps/web,CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=750}"

# 6. On an instance (Amazon Linux 2023): install the mount helper and mount with TLS
sudo dnf install -y amazon-efs-utils
sudo mkdir -p /mnt/efs
sudo mount -t efs -o tls fs-0abc1234:/ /mnt/efs
df -h /mnt/efs                     # size shows as 8.0E: there is no fixed size
echo "fs-0abc1234:/ /mnt/efs efs _netdev,tls 0 0" | sudo tee -a /etc/fstab   # remount at boot
#    Through an access point, with IAM authorisation:
sudo mount -t efs -o tls,iam,accesspoint=fsap-0123456789abcdef0 fs-0abc1234:/ /mnt/web

# 7. Troubleshoot a hanging mount: can the instance reach the mount target on 2049?
nc -zv -w 3 10.0.1.25 2049        # times out → check sg-efs inbound 2049 and the NACLs

#Summary

Key takeaways

• Block storage (EBS, instance store) is a raw disk for one instance; file storage (EFS, FSx) is a shared file system for many; object storage (S3) is whole objects over HTTP.
• EFS is a managed NFSv4.1 file system for Linux. Hundreds or thousands of instances, in every AZ of the Region, mount it at once. It grows and shrinks automatically, and you pay per GB stored.
• Instances reach it through one mount target per AZ. The mount target’s security group must allow inbound TCP 2049 from the instances; otherwise the mount hangs and times out.
• Regional (≥ 3 AZs, recommended) vs One Zone (one AZ, about half the price, no Archive, backups on by default, lost with its AZ).
• Performance mode: General Purpose always; Max I/O is legacy and not allowed with Elastic or One Zone.
• Throughput: Elastic (console default, spiky and unpredictable, pay per GB transferred), Provisioned (set MiB/s, pay for it), Bursting (scales with size, burst credits, API default).
• Storage classes: Standard, IA, Archive (plus One Zone and One Zone-IA). Lifecycle moves files after N days without access (console: IA 30, Archive 90) and, if set, back on first access. IA and Archive have per-GB access charges.
• IA is about 92% cheaper per GB on Bursting/Provisioned file systems and about 95% on Elastic; the real bill saving depends on how much data is truly cold.
• Encryption at rest with KMS is chosen at creation only; in transit uses the mount helper’s TLS option. Access points and IAM control who mounts what. AWS Backup and EFS Replication protect the data.
• Windows → FSx for Windows File Server; HPC → FSx for Lustre; one instance, persistent block → EBS; temporary, fastest → instance store; shared Linux files across AZs → EFS.

Self-check: EFS and choosing storage30 questions