EBS & EFS: Block and File Storage

In one line

EBS is a network-attached disk for one instance in one AZ, with snapshots for backup; EFS is a managed NFS filesystem that many instances across AZs can mount at once.

0/4 · 0%

Think of it like this

EBS is a USB drive plugged into one laptop — fast, yours alone, and it only works in the room (AZ) where it was made. EFS is a shared network drive on the office server that everyone's laptop can open at the same time.

Key ideas

01
EBS VOLUMES are block devices attached to one EC2 instance (multi-attach exists only for special io2 cases). A volume lives in ONE AZ and can only attach to instances in that AZ. It persists independently of the instance unless 'delete on termination' is set (the default for root volumes).
02
Volume types: gp3 is the default general-purpose SSD — baseline 3,000 IOPS and 125 MB/s regardless of size, tunable independently (cheaper and more predictable than the older gp2, whose performance scaled with size). io2 for databases needing high guaranteed IOPS; st1/sc1 HDD for large sequential throughput.
03
SNAPSHOTS are incremental, point-in-time backups stored in S3 (managed by AWS). They're how you back up, copy a volume to another AZ or region (restore the snapshot there), or build an AMI. Automate them with Data Lifecycle Manager or AWS Backup.
04
EFS is a managed NFS filesystem: elastic (no size to provision), mountable concurrently by many instances, containers, and Lambda functions across all AZs in a region. It suits shared content, CMS uploads, and ML datasets; it's slower per operation and pricier per GB than EBS, and not a place for a database's data files.
05
Rule of thumb: prefer S3 for application data whenever possible; use EBS for an instance's own disk and single-node databases; use EFS only when multiple machines genuinely need the same POSIX filesystem.

Code & diagrams

ebs.shbash

# gp3 volume with tuned performance, same AZ as the instance
VOL=$(aws ec2 create-volume --availability-zone ap-south-1a --size 200 \
  --volume-type gp3 --iops 6000 --throughput 250 --encrypted \
  --query VolumeId --output text)
aws ec2 attach-volume --volume-id $VOL --instance-id i-0abc --device /dev/sdf

# On the instance (Nitro exposes it as NVMe):
#   lsblk                         # find it, e.g. nvme1n1
#   sudo mkfs -t xfs /dev/nvme1n1
#   sudo mount /dev/nvme1n1 /data

# Snapshot, then restore into another AZ
SNAP=$(aws ec2 create-snapshot --volume-id $VOL --description "pre-upgrade" \
  --query SnapshotId --output text)
aws ec2 create-volume --snapshot-id $SNAP --availability-zone ap-south-1b --volume-type gp3

efs-mount.shbash

# On each instance (amazon-efs-utils installed); TLS in transit
sudo mkdir -p /shared
sudo mount -t efs -o tls fs-0123456789abcdef:/ /shared

# Persist across reboots
echo 'fs-0123456789abcdef:/ /shared efs _netdev,tls 0 0' | sudo tee -a /etc/fstab

Explain it without notes

An instance in ap-south-1a fails and you want to attach its data volume to a new instance in ap-south-1b. Why can't you, and what do you do instead?

Why is gp3 usually preferred over gp2 today?

Practice

Three web servers behind an ALB need to serve the same user-uploaded images. Compare EFS vs S3 for this.

How would you make daily EBS backups with 14-day retention without writing a cron job?

Trade-offs

↔
EBS is fast and cheap but tied to one instance and one AZ; EFS is shared and multi-AZ but slower per operation and more expensive. Needing shared POSIX storage is often a sign the application should use S3 instead.

Done when you can

I know EBS volumes are single-AZ and how to move data between AZs via snapshots.
I default to gp3 and can tune IOPS/throughput.
I know when EFS is the right choice and when S3 is better.
I automate snapshots with AWS Backup or DLM.