AWS Block & File Storage, In Depth: EBS, EFS, FSx & Instance Store

Compute gets the attention, but storage is where production systems live or die. A database is only as fast as the volume beneath it; a shared web farm is only as consistent as the file system every node mounts; a “lost” machine is only a disaster if the data went with it. AWS gives you three fundamentally different shapes of storage, and choosing the wrong one is one of the most expensive mistakes a team can make — not just in money, but in rewrites. Block storage (Amazon EBS, instance store) presents a raw disk you format and mount on a single machine. File storage (Amazon EFS, Amazon FSx) presents a shared file system many machines mount at once. Object storage (Amazon S3, covered in its own lesson) presents a flat namespace of objects you reach over HTTP. Each exists because the others cannot do its job.

This lesson is the exhaustive tour of AWS block and file storage. We will go through every EBS volume type with its real IOPS and throughput numbers and the workload each is for; how snapshots work (incremental, cross-Region copy, Fast Snapshot Restore); encryption and the encrypt-by-default switch; Multi-Attach for clustered applications; resizing and changing a live volume; the difference between the root volume and data volumes; the instance store that vanishes when you stop an instance; Amazon EFS end to end (elastic NFS, performance and throughput modes, lifecycle to Infrequent Access, access points, mount targets); the four FSx file systems (Windows File Server, Lustre, NetApp ONTAP, OpenZFS) and when each one is the answer; and finally a clear decision framework for block vs file vs object. By the end you will be able to size a volume correctly, protect it, share it when you must, and never again reach for the wrong storage shape.

A note on where this sits. This lesson is the foundation — what each service is and every option it exposes. When you need to squeeze maximum performance out of a volume — decoupling IOPS from throughput on gp3, matching EFS throughput modes to a workload, and finding the instance-level bandwidth ceiling that quietly caps everything — read the companion tuning lesson, Tuning Block and File Storage on AWS, linked at the end.

Learning objectives

By the end of this lesson you will be able to:

• Distinguish block, file, and object storage and pick the right shape for a given workload.
• Choose the correct EBS volume type (gp3, gp2, io2 Block Express, io1, st1, sc1) from IOPS, throughput, latency, durability, and cost.
• Explain EBS snapshots (incremental storage, cross-Region/cross-account copy, Fast Snapshot Restore, Recycle Bin) and use them for backup and migration.
• Configure EBS encryption, turn on encrypt-by-default, and reason about KMS keys; and explain Multi-Attach and its constraints.
• Resize and modify a live EBS volume, and tell the root volume apart from data volumes.
• Describe the instance store — when you get it, what it is for, and exactly when the data disappears.
• Set up Amazon EFS end to end: mount targets, performance and throughput modes, lifecycle management to Infrequent Access, and access points.
• Select the right Amazon FSx variant — Windows File Server, Lustre, NetApp ONTAP, or OpenZFS — for a given requirement.

Prerequisites & where this fits

You need an AWS account, a working grasp of Amazon EC2 (instances, AMIs, Availability Zones), and basic familiarity with the AWS CLI and VPC networking (subnets and security groups), because file systems live inside a VPC and are reached through mount targets in your subnets. No prior storage-administration background is assumed — every term is defined as it appears. This is the sixth lesson in the AWS Zero-to-Hero course, in the Storage module, following Amazon S3, In Depth. S3 taught you object storage; this lesson completes the storage picture with block and file. After this, the course moves on to databases with Amazon RDS & Aurora, In Depth.

Core concepts: the three shapes of storage

Before any service, fix the mental model. The three storage shapes differ in their unit, their access protocol, and how many machines can use them at once.

The decisive question is “does more than one machine need the same data at the same time?” If no, block storage is simplest and fastest. If yes, you need file (mountable, POSIX-like) or object (HTTP, web-scale). And if you are storing backups, media, logs, or anything you reach by key rather than by path — that is object storage, S3, and you should not be reaching for a file system at all.

Two more foundational terms:

• IOPS (Input/Output Operations Per Second) — how many individual read/write operations the volume can do per second. Matters for databases and any workload doing many small random reads/writes.
• Throughput — how many megabytes per second the volume can move. Matters for sequential workloads: log processing, big-data scans, video.

A volume can be IOPS-bound, throughput-bound, or capacity-bound, and the type you pick should match which one your workload actually hits.

Amazon EBS: block storage for a single instance

Amazon Elastic Block Store (EBS) provides network-attached block volumes for EC2. An EBS volume behaves like a physical hard disk: you attach it to one instance, format it with a file system, and mount it. But unlike a physical disk, it is decoupled from the instance — it lives independently in an Availability Zone (AZ), persists when the instance stops, and can be detached from one instance and reattached to another (in the same AZ). It is replicated within its AZ for durability, so a single hardware failure does not lose your data.

Three facts to internalise before the options:

1. An EBS volume is locked to one Availability Zone. You cannot attach a us-east-1a volume to an instance in us-east-1b. To move it across AZs you take a snapshot (which lives in S3, Region-wide) and create a new volume from it in the target AZ.
2. Network-attached, not local. EBS traffic shares the instance’s network/EBS bandwidth. On modern Nitro instances EBS has its own dedicated bandwidth lane, but there is still a per-instance ceiling — the single most overlooked cap in AWS storage (covered in the tuning lesson).
3. You pay for what you provision, not what you use. A 500 GiB gp3 volume costs the same whether it holds 5 GiB or 480 GiB. Provisioned IOPS and throughput above the free baseline cost extra.

EBS volume types: every option

There are two SSD families (optimised for IOPS / transactional work) and two HDD families (optimised for throughput / sequential work). Here is every current type with real numbers.

How to choose, the rules I actually apply:

• Default to gp3. It gives you a free baseline of 3,000 IOPS and 125 MiB/s regardless of size, and lets you buy IOPS (up to 16,000) and throughput (up to 1,000 MiB/s) independently of capacity. On gp2, IOPS were tethered to size (3 IOPS per GiB) — so you had to over-provision capacity just to get IOPS. There is almost no reason to choose gp2 on a new system; migrating gp2 → gp3 is a single online modify-volume call and usually cuts cost.
• Reach for io2 Block Express only when you genuinely need it: sustained IOPS above 16,000, single-digit-millisecond p99 latency under heavy load, the 99.999% durability tier (10× the SSD/HDD types), volumes larger than 16 TiB (up to 64 TiB), or Multi-Attach. It is the substrate behind those high ceilings and runs on Nitro instances. io2 also supports a higher IOPS-to-GiB ratio (up to 1,000:1) than io1 (50:1).
• Use st1 for throughput-bound sequential workloads — Kafka, big-data scans, log processing — where you move large blocks and rarely seek. It is far cheaper per GiB than SSD and its throughput model (baseline + burst credits scaling with size) suits streaming reads.
• Use sc1 for cold data you must keep on a block device but rarely touch. It is the cheapest EBS option; if access is truly rare, ask first whether the data belongs in S3 instead.
• Do not provision IOPS the instance can’t deliver. A 64,000-IOPS io2 on an instance whose EBS lane tops out at 4,750 IOPS is money burned. Match the volume to the instance’s EBS bandwidth (the tuning lesson shows how to find it).

HDD types (st1, sc1) cannot be boot/root volumes — they are data-only. Boot volumes must be SSD (gp3/gp2/io2/io1).

gp3 vs gp2: why the decoupling matters

This is an interview favourite, so be precise. On gp2, performance is a function of size: 3 IOPS per provisioned GiB (so a 100 GiB volume gets 300 IOPS baseline), with small volumes able to burst to 3,000 IOPS using a credit bucket. To get 6,000 sustained IOPS on gp2 you had to provision 2,000 GiB — paying for capacity you didn’t need. On gp3, every volume starts at 3,000 IOPS and 125 MiB/s for free, and you dial IOPS and throughput up independently with sliders, decoupled from the 1 GiB–16 TiB capacity. The result: gp3 is typically ~20% cheaper than gp2 for the same baseline and far cheaper when you need IOPS without capacity. The migration is non-disruptive.

EBS snapshots

A snapshot is a point-in-time backup of an EBS volume stored in Amazon S3 (in AWS-managed buckets you don’t see), making it Region-wide and highly durable — your escape hatch from the single-AZ confinement of the volume itself.

The properties that matter:

• Incremental. The first snapshot copies all used blocks; every subsequent snapshot stores only blocks that changed since the last one. You are billed only for unique changed blocks across the chain, so daily snapshots of a mostly-static volume are cheap. Deleting an intermediate snapshot does not corrupt later ones — AWS preserves the blocks newer snapshots still reference.
• Create a volume in any AZ. From a snapshot you can create a new volume in any AZ in the Region — this is exactly how you migrate a volume across AZs, and how you restore after failure.
• Copy across Regions and accounts. copy-snapshot replicates a snapshot to another Region (for DR or to launch in a new Region) or shares it with another account (the basis of cross-account AMI and backup distribution). A copy to a new Region can also re-encrypt with a different KMS key.
• Fast Snapshot Restore (FSR). Normally a volume restored from a snapshot is lazily loaded — blocks are fetched from S3 on first access, so the first read of each block is slow (“initialisation latency”). FSR pre-warms a snapshot in chosen AZs so restored volumes deliver full provisioned performance immediately. It is billed per snapshot per AZ per hour — use it for snapshots you restore often (golden images, fleet launches), not everything.
• Archive tier. EBS Snapshots Archive moves a full (not incremental) snapshot to a low-cost cold tier for long retention (≥90 days); restoring takes 24–72 hours. Good for compliance copies you hope never to need.
• Recycle Bin. Retention rules can hold deleted snapshots (and AMIs) for a set period so an accidental or malicious deletion is recoverable.
• Automate with DLM or AWS Backup. Data Lifecycle Manager (DLM) schedules snapshot creation, retention, and cross-Region copy by tag; AWS Backup does the same centrally across services with vault lock for immutability. Don’t write cron jobs for this.

An AMI (Amazon Machine Image) for an EBS-backed instance is, under the hood, one or more EBS snapshots plus launch metadata — which is why creating an AMI creates snapshots.

EBS encryption

EBS offers encryption at rest using AWS KMS keys, with AES-256. When a volume is encrypted, AWS transparently encrypts: data at rest on the volume, data in transit between the instance and the volume, all snapshots created from it, and all volumes created from those snapshots. There is no measurable performance penalty and nothing to manage inside the guest — encryption happens on the Nitro hardware.

Key facts that trip people up:

• You cannot directly encrypt an existing unencrypted volume in place. The path is: snapshot it → copy the snapshot with encryption enabled → create a new (encrypted) volume from the encrypted copy → swap it in.
• Going the other way (decrypting) is similarly indirect and rarely wanted.
• Encrypt by default is per-Region — enable it in every Region you use.
• Sharing an encrypted snapshot with another account requires a CMK (you cannot share one encrypted with the default aws/ebs key) and a grant on that key to the target account.

Multi-Attach

By default an EBS volume attaches to one instance. EBS Multi-Attach lets a single io2 (or io1) volume attach to up to 16 Nitro instances in the same Availability Zone simultaneously, all with read/write access. This exists for clustered applications that manage concurrent access themselves.

The constraints are strict and examinable:

• io1/io2 only, same AZ only, Nitro instances only, up to 16 instances.
• The file system or application must be cluster-aware — it needs its own coordination (a clustered file system such as GFS2 or an application that arbitrates writes). Mounting a standard single-writer file system like XFS or ext4 on multiple instances at once will corrupt the data, because those file systems assume they are the sole writer. Multi-Attach gives you a shared block device, not a shared file system.
• Multi-Attach volumes do not support I/O fencing with all configurations and have some feature limitations (e.g. you can’t resize while multi-attached). Persistent reservations (SCSI-3 PR) are supported on io2 for fencing.
• If you just want a shared file system, use EFS or FSx instead — that is the right tool 95% of the time. Multi-Attach is for specific clustered software (e.g. certain database clusters) that requires a shared block device.

Resizing and modifying a live volume — Elastic Volumes

With Elastic Volumes, you can increase size, change the volume type, and adjust provisioned IOPS/throughput on a live, attached volume with no downtime — no detach, no stop. After the volume modification completes (it enters an optimizing state, still usable), you must extend the file system inside the guest to use the new space (growpart + resize2fs for ext4, or xfs_growfs for XFS on Linux; Disk Management on Windows). Two limits: you can only grow, never shrink a volume, and after a modification you must wait at least 6 hours (and for the volume to leave optimizing) before modifying the same volume again.

Root volume vs data volumes

• The root (boot) volume holds the operating system; it is created from the AMI when the instance launches. By default it has DeleteOnTermination = true, so it is deleted when the instance terminates — you usually want this for the OS disk but it surprises people who stored data there.
• Data volumes are additional EBS volumes you attach for application data, databases, logs. Best practice: keep data on separate volumes from the root, set their DeleteOnTermination = false so terminating the instance doesn’t destroy your data, and snapshot them on a schedule. Separating data from OS also lets you grow, snapshot, and migrate data independently of the machine.

Instance store: ephemeral, blazing-fast, and gone when you stop

Some EC2 instance types include instance store volumes — block storage on disks physically attached to the host running your instance. Because the storage is local (often NVMe SSD), it offers very high IOPS and throughput and the lowest latency of any EC2 storage — there is no network hop. It is also included in the instance price (no separate charge).

The catch — and it is the whole point — is that instance store is ephemeral:

Use instance store for data you can afford to lose or can rebuild: scratch space, caches, temporary processing files, buffers, replicated data (e.g. a node in a cluster that re-replicates), or the spill/shuffle space of a big-data job. Never put a database’s only copy, or anything you cannot reconstruct, on instance store. Contrast with EBS, which is network-attached and persists across stop/start. Not every instance type has instance store — it is a property of the family (storage-optimised families like i4i, im4gn, d3 are built around it).

Amazon EFS: elastic, shared NFS file storage

Amazon Elastic File System (EFS) is a fully managed, elastic NFS file system for Linux. Many EC2 instances (and Lambda functions, ECS/EKS containers) across multiple Availability Zones can mount the same file system simultaneously and share files with standard POSIX semantics. It is serverless and elastic: it grows and shrinks automatically as you add and remove files — you never provision capacity — and you pay only for the storage you use (plus throughput, depending on mode). EFS is Regional: data is stored redundantly across multiple AZs (in Standard storage classes), so it survives the loss of an entire AZ.

EFS is the answer when multiple Linux instances need a shared file system: web content across an Auto Scaling fleet, shared home directories, content-management uploads, CI/CD artefacts, lift-and-shift apps that expect a POSIX file share, and ML training data shared across nodes.

Mount targets and access

You mount EFS over NFS v4.1 at a mount target — an endpoint with an IP address that EFS creates in a subnet of your VPC. Best practice is one mount target per Availability Zone, so instances mount the file system over a path that stays within their own AZ (lower latency, no cross-AZ data charges). A security group on the mount target controls access — it must allow inbound NFS (TCP 2049) from the instances’ security group. You mount with the EFS mount helper (mount -t efs), ideally with TLS (-o tls) to encrypt data in transit, or via standard NFS.

Storage classes and lifecycle management

Lifecycle Management automatically moves files between the active class and the Infrequent Access (IA) class based on access patterns. You set a policy such as “transition to IA after 30 days without access” and “transition back to active on first access” (the Intelligent-Tiering behaviour). Because most file shares have a long tail of rarely touched files, lifecycle management can cut EFS storage cost dramatically with no code changes. Choose One Zone classes only when you accept that an AZ loss could make the file system unavailable/lost (cheaper for dev, scratch, or easily-reproduced data).

Performance modes and throughput modes

EFS has two independent knobs, and confusing them is the classic mistake.

Performance mode (set at creation, affects latency vs parallelism):

Throughput mode (how much throughput you get, changeable after creation):

The trap: a small file system on Bursting mode gets little baseline throughput (it scales with stored data), so a 10 GiB share can feel painfully slow even though the data is tiny. For most workloads in 2026, Elastic throughput with General Purpose performance is the right starting point.

EFS access points

An EFS access point is an application-specific entry point into an EFS file system that enforces a POSIX user/group and a root directory for anything connecting through it. Instead of every client mounting the file system root and policing paths and permissions itself, you create an access point that says “this app sees /app-data as its root and operates as UID 1001/GID 1001” — and the app simply cannot escape that directory or identity. Access points are the clean way to share one file system among many applications (or many tenants) with isolation, and they integrate with IAM authorisation for NFS. They are especially useful for Lambda and container workloads, where you attach the function/task to an access point rather than managing mount permissions.

EFS security and other features

• Encryption at rest (KMS) can be enabled only at creation and is on by default in the console; encryption in transit is enabled per-mount with the -o tls mount option.
• EFS Replication maintains a read-only cross-Region (or same-Region) copy for DR with a low RPO, managed by AWS.
• IAM/NFS authorisation and file system policies (resource policies) let you require encrypted transport, restrict who can mount, and grant per-access-point permissions.

Amazon FSx: managed third-party and high-performance file systems

Where EFS is AWS’s own elastic NFS for Linux, Amazon FSx is a family of fully managed file systems built on well-known third-party file-system technologies, for cases EFS doesn’t cover — chiefly Windows/SMB, HPC, and rich storage features like snapshots, dedup, and tiering. There are four FSx offerings; knowing which to pick is a frequent exam and design question.

How to reason about it quickly:

• Windows file share? → FSx for Windows File Server (SMB + Active Directory). EFS is Linux/NFS only and is not an option here.
• HPC, ML training, or analytics needing extreme throughput, often over S3 data? → FSx for Lustre. It can transparently present an S3 bucket as a Lustre file system and write results back to S3.
• Need NFS and SMB on the same data, or specific NetApp features (SnapMirror, dedup, tiering)? → FSx for NetApp ONTAP — the most feature-rich and the multi-protocol choice.
• Linux/NFS workload that wants ZFS snapshots/clones and very low latency? → FSx for OpenZFS.

All FSx variants are managed (AWS handles patching, backups, and the underlying servers), live in your VPC behind mount targets/endpoints, support encryption at rest and in transit, and offer automatic backups.

Choosing block vs file vs object

Bring it together with a decision framework. Ask these questions in order:

1. Do I reach the data by HTTP key, and is it backups/media/logs/static assets/data lake? → Object storage (S3). Don’t mount a file system for this.
2. Do multiple machines need to share the same files concurrently?
   • Yes, Linux/NFS, elastic and serverless → EFS.
   • Yes, Windows/SMB → FSx for Windows File Server.
   • Yes, HPC/ML extreme throughput → FSx for Lustre.
   • Yes, multi-protocol or NetApp/ZFS features → FSx for ONTAP / OpenZFS.
3. Single machine, needs a raw disk / database / boot volume? → Block storage (EBS) — gp3 by default, io2 Block Express for demanding databases.
4. Single machine, need the fastest possible scratch and can lose it on stop? → Instance store.

The diagram above maps the landscape: a single EC2 instance with its EBS root and data volumes and local instance store on the left (block, single-host); a multi-AZ fleet mounting one EFS or FSx file system in the middle (file, shared); and S3 as the object store on the right — the same three shapes the decision framework walks through.

Hands-on lab: create, attach, snapshot, and share storage

This lab uses the AWS CLI and stays within or near the AWS Free Tier (EBS includes 30 GiB of gp3/gp2 per month free for 12 months; EFS has a small free allowance). You will create and attach an encrypted EBS data volume, write to it, snapshot it, grow it live, then create an EFS file system and mount target. Replace the placeholder IDs with your own.

Prerequisites: the CLI configured (aws configure), a running EC2 Linux instance you can SSH into, and its instance ID, AZ, subnet ID, and security group ID to hand.

Part A — an encrypted EBS data volume

# 0. (Recommended) turn on encrypt-by-default for this Region
aws ec2 enable-ebs-encryption-by-default

# 1. Find your instance's AZ (volume must be in the SAME AZ)
aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].Placement.AvailabilityZone' --output text
# -> e.g. us-east-1a

# 2. Create a 10 GiB gp3 encrypted volume in that AZ
aws ec2 create-volume \
  --availability-zone us-east-1a \
  --size 10 --volume-type gp3 --encrypted \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=lab-data}]'
# note the returned VolumeId, e.g. vol-0aaa...

# 3. Attach it to the instance as /dev/sdf
aws ec2 attach-volume --volume-id vol-0aaa... \
  --instance-id i-0123456789abcdef0 --device /dev/sdf

On the instance, format and mount it (the device often appears as /dev/nvme1n1 on Nitro):

lsblk                                  # find the new device
sudo mkfs -t xfs /dev/nvme1n1          # format (data only — destroys contents)
sudo mkdir -p /data && sudo mount /dev/nvme1n1 /data
echo "hello block storage" | sudo tee /data/test.txt
df -h /data                            # validation: shows ~10G mounted on /data

Part B — snapshot it

aws ec2 create-snapshot --volume-id vol-0aaa... \
  --description "lab snapshot" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=lab-snap}]'
# note the SnapshotId; wait for it to complete:
aws ec2 wait snapshot-completed --snapshot-ids snap-0bbb...
echo "snapshot ready (incremental, stored in S3, Region-wide)"

You could now create a volume from this snapshot in any AZ — that is the cross-AZ migration path.

Part C — grow the volume live (Elastic Volumes)

# Increase 10 GiB -> 20 GiB with no downtime
aws ec2 modify-volume --volume-id vol-0aaa... --size 20
aws ec2 describe-volumes-modifications --volume-id vol-0aaa... \
  --query 'VolumesModifications[].[ModificationState,Progress]' --output text

On the instance, extend the file system into the new space:

sudo xfs_growfs /data        # XFS grows online; df -h now shows ~20G
df -h /data                  # validation

Part D — an EFS file system and mount target

# 1. Create the file system (encrypted, Elastic throughput, General Purpose)
aws efs create-file-system --encrypted \
  --performance-mode generalPurpose --throughput-mode elastic \
  --tags Key=Name,Value=lab-efs
# note the FileSystemId, e.g. fs-0ccc...

# 2. Create a mount target in your subnet (SG must allow NFS 2049 from your instance)
aws efs create-mount-target --file-system-id fs-0ccc... \
  --subnet-id subnet-0ddd... --security-groups sg-0eee...

On the instance (install the helper first):

sudo yum install -y amazon-efs-utils      # or: apt-get install -y amazon-efs-utils
sudo mkdir -p /efs
sudo mount -t efs -o tls fs-0ccc...:/ /efs    # TLS = encrypted in transit
echo "hello shared file storage" | sudo tee /efs/shared.txt
df -h /efs                                    # validation: EFS mounted

Mount the same fs-0ccc... on a second instance and you will see shared.txt — that is the shared, multi-instance nature of file storage.

Cleanup (avoid charges)

# EFS
sudo umount /efs
aws efs delete-mount-target --mount-target-id fsmt-0fff...
aws efs delete-file-system --file-system-id fs-0ccc...

# EBS
sudo umount /data
aws ec2 detach-volume --volume-id vol-0aaa...
aws ec2 wait volume-available --volume-ids vol-0aaa...
aws ec2 delete-volume --volume-id vol-0aaa...
aws ec2 delete-snapshot --snapshot-id snap-0bbb...

Cost note: within the Free Tier the gp3 volume and snapshot are effectively free at this size; the EFS allowance covers the few KB you wrote. The biggest real-world cost mistakes here are leaving detached EBS volumes around (you pay for provisioned capacity whether or not it is attached) and unused snapshots (they accumulate). Always run the cleanup. Outside the lab, cross-AZ NFS traffic and provisioned IOPS/throughput are the levers that move the bill.

Common mistakes & troubleshooting

Best practices

• Default to gp3, and migrate gp2 → gp3 — it is non-disruptive and usually cheaper.
• Turn on EBS encrypt-by-default in every Region; you almost never want an unencrypted volume.
• Keep data on separate volumes from the OS, set their DeleteOnTermination = false, and snapshot on a schedule with DLM or AWS Backup (not cron).
• Right-size IOPS/throughput to the instance, not to a wishlist — over-provisioned IOPS the instance can’t reach is pure waste.
• Delete unattached volumes and stale snapshots — they cost money silently; tag everything so you can find owners.
• For sharing, reach for EFS/FSx before Multi-Attach — Multi-Attach is only for specific cluster-aware software.
• On EFS, start with Elastic throughput + General Purpose, and enable Lifecycle Management to IA to cut storage cost on cold files.
• Test your restores. A snapshot you have never restored is a hope, not a backup.

Security notes

• Encrypt at rest (EBS and EFS via KMS) and in transit (EFS with -o tls; EBS in-transit encryption is automatic for encrypted volumes). Use encrypt-by-default to make it non-optional.
• Prefer customer managed KMS keys (CMKs) where you need cross-account sharing, key separation, or auditable key policies; the AWS-managed aws/ebs key can’t be shared.
• Lock down NFS/SMB access with security groups (least privilege on 2049/445) and EFS access points + file system policies to enforce per-application identity and require encryption.
• Restrict snapshot sharing — public or broadly-shared snapshots can leak whole disks; audit with IAM Access Analyzer and never make snapshots public.
• Protect deletions with the Recycle Bin for snapshots/AMIs and AWS Backup Vault Lock for immutable, ransomware-resistant backups.
• Remember instance store is not encryptable via KMS in the same way and is wiped on stop — don’t rely on it for sensitive persistent data.

Interview & exam questions

1. What is the difference between block, file, and object storage, and which AWS services provide each? Block = raw disk on one machine (EBS, instance store); file = shared, mountable file system for many machines (EFS for NFS/Linux, FSx for SMB/HPC); object = HTTP key-addressed store (S3). Choose by whether multiple machines share the data and how you access it.

2. gp3 vs gp2 — why migrate? gp2 ties IOPS to size (3 IOPS/GiB) so you over-provision capacity to get IOPS; gp3 gives a free 3,000 IOPS + 125 MiB/s baseline and lets you buy IOPS/throughput independently of capacity, typically ~20% cheaper. Migration is an online modify-volume with no downtime.

3. When do you choose io2 Block Express over gp3? Sustained IOPS above 16,000, single-digit-ms p99 latency, the 99.999% durability tier, volumes >16 TiB (up to 64 TiB), or Multi-Attach. Otherwise gp3 is the cheaper default.

4. How do EBS snapshots work, and how do you move a volume to another AZ? Snapshots are incremental point-in-time backups stored in S3 (Region-wide). To move across AZs, snapshot the volume and create a new volume from it in the target AZ (volumes themselves are AZ-locked). Deleting an intermediate snapshot doesn’t break later ones.

5. What is Fast Snapshot Restore and when do you use it? Normally restored volumes lazy-load blocks from S3, so first reads are slow. FSR pre-warms a snapshot in chosen AZs so restored volumes hit full performance immediately. Billed per snapshot/AZ/hour — use it for frequently restored snapshots (golden images, fleet launches).

6. Explain EBS Multi-Attach and its biggest danger. A single io1/io2 volume attaches to up to 16 Nitro instances in the same AZ. The danger: it shares a block device, not a file system — mounting a single-writer FS (XFS/ext4) on multiple instances corrupts data. You need a cluster-aware FS, or (better) use EFS/FSx for sharing.

7. Instance store vs EBS — when is data lost? Instance store is local, ephemeral, very fast: it survives reboot but is lost on stop/start, hibernate, terminate, or host failure. EBS is network-attached and persists across stop/start. Use instance store only for scratch/cache/replicated data.

8. EFS performance mode vs throughput mode? Performance mode (General Purpose = low latency, default; Max I/O = higher parallel throughput, higher latency) is set at creation. Throughput mode (Elastic = auto-scaling, recommended; Bursting = scales with stored data; Provisioned = fixed) controls how much throughput you get and is changeable. Confusing the two is the classic mistake.

9. A 10 GiB EFS file system is unexpectedly slow — why? It is almost certainly on Bursting throughput, where throughput scales with the (tiny) amount of stored data. Switch to Elastic or Provisioned throughput.

10. You need a shared file system for Windows servers with Active Directory and NTFS permissions. What do you use? FSx for Windows File Server (SMB + AD). EFS is Linux/NFS only and won’t serve SMB.

11. You need extreme parallel throughput for ML training over data in S3. What do you use? FSx for Lustre, which can present an S3 bucket as a high-performance parallel file system and write results back to S3.

12. How do you encrypt an existing unencrypted EBS volume? You can’t encrypt it in place. Snapshot it, copy the snapshot with encryption enabled, create a new (encrypted) volume from the encrypted copy, and swap it in. Turn on encrypt-by-default to prevent the situation recurring.

Quick check

1. Which EBS volume type is the recommended default, and what free baseline does it include?
2. True or false: an EBS volume can be attached to an instance in any Availability Zone in its Region.
3. Name two events that destroy instance-store data and one that does not.
4. Which EFS throughput mode should you use for a small file system that needs steady high throughput?
5. Which FSx variant supports both NFS and SMB on the same data?

Answers

1. gp3, with a free baseline of 3,000 IOPS and 125 MiB/s, and IOPS/throughput purchasable independently of capacity.
2. False. An EBS volume is locked to a single AZ; to move it you snapshot and create a new volume from the snapshot in the target AZ.
3. Destroy: stop/start, hibernate, terminate, or host failure (any two). Does not destroy: a reboot.
4. Provisioned throughput (fixed throughput independent of size). Elastic is the general recommendation for spiky/unpredictable workloads.
5. FSx for NetApp ONTAP (multi-protocol: NFS, SMB, and iSCSI).

Exercise

Take an application you know that currently writes everything to a single instance’s local disk. Produce a one-page storage design that: (a) puts the OS on a gp3 root volume and application data on a separate encrypted gp3 data volume with DeleteOnTermination = false; (b) defines a snapshot schedule (frequency, retention, cross-Region copy) using DLM or AWS Backup; © decides whether any part of the workload needs shared storage and, if so, picks EFS or the right FSx variant with a one-sentence justification; (d) identifies anything that belongs in S3 instead; and (e) lists the IOPS/throughput you would provision and how you would confirm the instance can actually deliver it. Keep it to choices and one-line justifications — the goal is to practise the decision framework.

Certification mapping

This lesson maps to storage domains across the AWS certification path. For AWS Certified Solutions Architect – Associate (SAA-C03), expect questions on choosing EBS volume types, EBS vs instance store persistence, snapshots and cross-Region copy, EFS for shared Linux storage, and selecting the right FSx variant (especially Windows File Server for SMB and Lustre for HPC/S3-integrated workloads). For AWS Certified Developer – Associate (DVA-C02), the emphasis is on attaching EFS to Lambda via access points and understanding ephemeral vs durable storage for application data. For SysOps Administrator (SOA-C02), expect operational items: Elastic Volumes modifications, Data Lifecycle Manager, encrypt-by-default, and troubleshooting mount/permission issues. The “EBS is AZ-scoped, snapshots are Region-scoped” distinction and the “instance store is lost on stop” fact are near-guaranteed.

Glossary

• Block storage — storage presented as raw fixed-size blocks (a disk) that you format and mount; one volume per instance (EBS, instance store).
• File storage — a shared file system mounted over a network protocol (NFS/SMB) by many machines at once (EFS, FSx).
• Object storage — key-addressed objects reached over HTTP, web-scale (S3).
• EBS (Elastic Block Store) — network-attached, persistent block volumes for EC2, scoped to one Availability Zone.
• IOPS — input/output operations per second; matters for small random reads/writes (databases).
• Throughput — megabytes per second the volume can move; matters for sequential workloads.
• Snapshot — incremental point-in-time backup of an EBS volume stored in S3 (Region-wide).
• Fast Snapshot Restore (FSR) — pre-warms a snapshot in chosen AZs so restored volumes deliver full performance immediately.
• Multi-Attach — attaching one io1/io2 volume to up to 16 Nitro instances in the same AZ; requires a cluster-aware file system.
• Elastic Volumes — modifying size/type/IOPS/throughput on a live volume with no downtime (grow-only).
• Instance store — ephemeral block storage on the host disk; fast, free, and lost on stop/terminate/host failure.
• EFS (Elastic File System) — managed, elastic NFS file system for Linux, multi-AZ and serverless.
• Mount target — the IP endpoint EFS places in a VPC subnet so instances can mount it (NFS 2049).
• Performance mode (EFS) — General Purpose (low latency, default) vs Max I/O (higher parallel throughput).
• Throughput mode (EFS) — Elastic (auto-scaling, recommended), Bursting (scales with stored data), Provisioned (fixed).
• Access point (EFS) — an application-specific entry point enforcing a POSIX identity and root directory.
• FSx — managed family of third-party/high-performance file systems: Windows File Server, Lustre, NetApp ONTAP, OpenZFS.
• CMK (customer managed key) — a KMS key you own and control, required for cross-account encrypted sharing.

Next steps

You now know every block and file storage option AWS offers and how to choose between them. The natural next move is performance: read Tuning Block and File Storage on AWS: EBS gp3/io2, EFS Throughput Modes, and Workload-Driven Sizing to decouple IOPS from throughput, match EFS throughput modes to real workloads, and find the instance-level bandwidth ceiling that quietly caps everything. After that, the course continues with databases in Amazon RDS & Aurora, In Depth: Engines, Multi-AZ, Read Replicas, Backups & Every Option, where much of what you learned about EBS volume types and snapshots reappears beneath managed database storage.