Skip to content

Lab 8 · S3, EBS & EFS

Performance · Est. time: 35–40 min · Cost: mostly Free Tier (5 GB S3, 30 GB EBS gp3, EFS has a small free allowance). EC2 for the mount step is Free-Tier t3.micro. Tear down volumes/EFS after.

Goal. Touch all three storage shapes — object (S3), block (EBS), file (EFS) — and see why "many instances share the same files" means EFS, not EBS (Topic 8).

Part A — S3 object storage + lifecycle

  1. S3 → Create bucket lab-storage-<random>.
  2. Upload a file. Note the storage class (Standard) on the object.
  3. Management → Create lifecycle rule: transition objects to Standard-IA after 30 days, then Glacier after 90 — the cost pattern from Topic 11.
aws s3 mb s3://lab-storage-$(date +%s)
# lifecycle: see put-bucket-lifecycle-configuration

Point: S3 is accessed by API/key from anywhere — it's not a mounted disk.

Part B — EBS block storage (single instance)

  1. EC2 → Volumes → Create volume: gp3, 10 GiB, in the same AZ as an instance you'll attach it to.
  2. Actions → Attach volume → pick a running t3.micro.
  3. On the instance: lsblk shows the new device; format + mount it (mkfs, mount). It's a raw disk for one instance.
VOL=$(aws ec2 create-volume --volume-type gp3 --size 10 --availability-zone us-east-1a --query VolumeId --output text)
aws ec2 attach-volume --volume-id $VOL --instance-id <instance-id> --device /dev/sdf

Point: an EBS volume attaches to one instance in one AZ. Try to attach it to a second AZ's instance — you can't. That's the exam's EBS limitation.

Part C — EFS shared file system (many instances)

  1. EFS → Create file system lab-efs in your VPC (mount targets in two AZs).
  2. On two t3.micro instances (different AZs), install the client and mount it: 
    sudo dnf install -y amazon-efs-utils
sudo mkdir /mnt/efs
sudo mount -t efs <fs-id>:/ /mnt/efs
  3. Write a file from instance A (echo hi | sudo tee /mnt/efs/shared.txt) and read it from instance B. Both see the same file, across AZs — concurrently.
aws efs create-file-system --tags Key=Name,Value=lab-efs
# create mount targets in each subnet, then mount as above

Point: EFS is a shared NFS file system many Linux instances mount at once across AZs — the thing EBS can't do. (Windows/SMB → FSx for Windows.)

Teardown

  1. Unmount and delete the EFS file system (delete mount targets first if prompted).
  2. Detach and delete the EBS volume.
  3. Empty and delete the S3 bucket.
  4. Terminate the lab instances.
aws ec2 detach-volume --volume-id $VOL && aws ec2 delete-volume --volume-id $VOL
aws efs delete-file-system --file-system-id <fs-id>   # after mount targets removed
aws s3 rb s3://<bucket> --force

✅ What you should understand now

  • S3 = object (API access, not a disk); EBS = block (one instance, one AZ); EFS = file (many instances mount concurrently across AZs).
  • You can't share one EBS volume read/write across AZs — that's an EFS (or FSx) job.
  • gp3 is the default general-purpose EBS volume; HDD types (st1/sc1) can't be boot volumes.
  • S3 lifecycle rules move data to cheaper classes by age — the storage cost lever.
  • EFS is Linux/NFS; for Windows/SMB shares use FSx for Windows.

Related: Learn — Storage Performance