AWS Cloud Architect & Developer · AWS Cloud Architecture

EBS and EFS Storage

Block storage with EBS and shared file storage with EFS for EC2 workloads.

Six concepts on the block-versus-file fork every EC2 storage question tests. EBS is a virtual disk for one instance in one Availability Zone; EFS is regional NFS when a fleet must share the same directory tree. Snapshots move block data across zones; volume types and provisioned IOPS decide whether a database question wants gp3 or io2.

AWS Cloud Architect & Developer
Medium level
6 concepts
5 practice questions

1Shared storage: EFS, not EBS

Elastic Block Store is network-attached block storage for a single EC2 instance in one Availability Zone. A standard volume attaches to one instance; io1 and io2 Multi-Attach still keeps every attachment in the same AZ. Elastic File System is regional NFS: mount targets in each AZ let many instances — including an Auto Scaling group spread across AZs — read and write the same directory tree at once. When several instances must share the same uploaded content, EBS is the wrong pick, not EFS.

Figure. EFS sits at the centre with NFS mounts into every instance across both AZs. The EBS volume attaches to a single EC2 in one AZ only — the pattern the exam rejects when the fleet must share one directory.

How it works

Count readers and writersOne instance needing a boot or data disk wants block storage. Many instances needing the same files want a shared file system.
Check the AZ spanEBS volumes do not cross Availability Zones. EFS is regional and places a mount target in each AZ you use.
Pick the serviceEFS for concurrent NFS across a fleet; EBS for single-instance block I/O with predictable latency.

EBS block storage against EFS file storage
Access pattern	Service	Why
One EC2, block device	EBS	One volume in one AZ; attach as /dev/xvdf-style block storage
Many EC2, same directory tree	EFS	Regional NFS with mount targets per AZ; thousands of concurrent clients
Move a volume to another AZ	EBS snapshot	Snapshot to S3, restore a new volume in the target AZ — volumes cannot hop AZs directly

A web fleet in two Availability Zones must all read and write the same upload directory. Which storage?

One gp3 EBS volume with Multi-Attach on every instance
One EFS file system with mount targets in each AZ
One EBS snapshot mounted read-write on each instance
One st1 EBS volume exported as NFS from a bastion host

Multi-Attach io volumes still cannot span AZs and only cover the narrow block-device exception within one AZ — not a regional shared directory. Snapshots are restore points, not live shared mounts. A bastion NFS export is a DIY pattern the exam never rewards when EFS exists.

2EBS block storage and persistence

Elastic Block Store presents a raw block device — format it, mount it, treat it like a virtual hard drive. A volume lives in one Availability Zone and attaches to instances in that zone only; it persists independently of the instance lifecycle, so stopping the instance does not erase the disk. EC2 Instance Store is the opposite trap: physically attached host storage that is fast but ephemeral — data vanishes on stop, hibernate, or terminate.

Figure. One EC2 in a single AZ: EBS hangs off the network as persistent block storage; instance store sits on the host and disappears with the instance.

How it works

Block, not filesEBS is a block device the OS formats; the exam pairs it with databases and boot volumes, not shared directories.
One AZ anchorCreate the volume in the same AZ as the instance; cross-zone attachment is impossible without a snapshot restore.
Survives stopEBS data remains when the instance stops; instance store does not — that contrast is a favourite distractor.

Persistent block versus ephemeral local
Storage	Survives instance stop?	Typical use
EBS volume	Yes — independent lifecycle	Boot volume, database files, anything that must survive restarts
Instance Store	No — lost on stop/terminate	Temporary cache, scratch space, rebuildable buffers

An analytics job writes a 500 GiB scratch dataset that can be regenerated overnight. The instance may stop between runs. Which storage fits the scratch space?

A gp3 EBS data volume
Instance Store on the host
Amazon EFS Standard
An EBS snapshot

Regenerable scratch on a stoppable instance is exactly instance store territory — speed without paying for persistent block. gp3 persists and bills when idle; EFS is shared file storage, not local scratch; a snapshot is a backup artefact, not a live mount.

3EBS volume types: gp3, io2, st1, sc1

General Purpose SSD gp3 is the default: 3,000 IOPS and 125 MB/s are included and each scales independently up to 16,000 IOPS and 1,000 MB/s without growing disk size. Provisioned IOPS SSD io1 and io2 target latency-sensitive databases — io2 Block Express reaches 256,000 IOPS and 4,000 MB/s on volumes up to 64 TiB with 99.999% durability. Throughput Optimized HDD st1 and Cold HDD sc1 trade random IOPS for cheap sequential throughput; neither belongs on a transactional database.

Figure. Pick EBS by bottleneck: gp3 default, io2 for IOPS, st1/sc1 for sequential throughput/cold HDD.

How it works

Random IOPS or sequential?Random read-write workloads want SSD — gp3 for general use, io2 when IOPS must be guaranteed.
Provision explicitlyOn gp3, raise IOPS and throughput independently; do not assume size alone buys performance.
HDD for logs and big datast1 for frequently accessed sequential data; sc1 for cold, infrequently read archives at lowest cost.

Which EBS volume type for which workload
Workload signal	Volume type	Why
General boot or app disk	gp3	Balanced SSD; baseline IOPS included; cheaper than legacy gp2
Database needing guaranteed IOPS	io1 / io2	Provisioned IOPS SSD with durability SLA; io2 Block Express for extreme tiers
Big-data logs, sequential scans	st1	Throughput HDD optimised for large sequential reads and writes
Infrequent access, lowest cost	sc1	Cold HDD — not for active databases or boot volumes

A nightly log-processing cluster reads multi-terabyte files sequentially and rarely performs random I/O. Which EBS type minimises cost while matching the access pattern?

io2 Block Express
gp3 with 16,000 provisioned IOPS
st1 Throughput Optimized HDD
sc1 Cold HDD

Sequential log scans are st1 territory — throughput HDD priced for large streaming reads. io2 and maxed gp3 pay for random IOPS the job never uses. sc1 is for cold, rarely touched data, not nightly active processing.

4EBS snapshots and cross-AZ restore

An EBS snapshot is a point-in-time backup stored incrementally in Amazon S3 within the Region. Snapshots are Region-wide — you cannot attach a live volume across Availability Zones, but you can restore snapshot data into a new volume in any AZ in that Region. That restore path is how you migrate a database volume, clone an environment, or recover after an AZ outage without copying raw blocks by hand.

Figure. The live volume stays in AZ-a. A snapshot lands in Region-wide S3 storage, then seeds a brand-new volume in AZ-b — the only supported cross-zone path for block data.

How it works

Snapshot the sourceCreate a snapshot of the volume in AZ-a; the first snapshot is full, later ones are incremental.
Create in target AZFrom the snapshot, create a new EBS volume explicitly in AZ-b — it is a new volume ID, not a move.
Attach and verifyAttach the restored volume to an instance in AZ-b; update mount points or AMIs as needed.

A production EBS volume in us-east-1a must be recreated in us-east-1b with identical data. What is the correct sequence?

Detach the volume and reattach it in us-east-1b
Snapshot the volume, create a new volume from the snapshot in us-east-1b, attach it
Copy the volume with AWS DataSync between AZs
Enable Multi-Attach and add an instance in us-east-1b

Live EBS volumes do not change AZ — only a snapshot restore creates a new volume in another zone. Detach-and-reattach keeps the same AZ. Multi-Attach stays within one AZ. DataSync is file/object migration, not block-volume cloning.

5EFS mount targets, NFS, and lifecycle tiers

Elastic File System is a managed NFSv4 file system scoped to a Region. Each Availability Zone you use gets a mount target in your subnet; instances mount the same file-system ID at a path such as /mnt/efs using the NFS client. Security groups must allow NFS traffic on port 2049 between instances and mount targets. EFS grows and shrinks automatically — you pay for stored bytes, not pre-provisioned capacity. Lifecycle management moves cold files to Infrequent Access tiers, cutting storage cost by up to about 92% for rarely touched data.

Reuse the regional EFS-with-mount-targets topology from the shared-storage figure: one mount target per AZ, NFS from instances in that AZ, and lifecycle tiers moving cold files to Infrequent Access. A second copy of that picture would teach nothing new.

How it works

Create the file systemChoose Regional Standard or One Zone storage class; Standard spans every AZ you mount.
Place mount targetsAdd a mount target per AZ subnet so instances in that AZ reach EFS with low latency.
Open NFS and mountAllow port 2049 in security groups, then mount the file-system ID on each instance.

EFS storage classes and lifecycle
Tier	Scope	When to use
Standard	Regional, multi-AZ	Production shared content that must survive an AZ loss
One Zone	Single AZ	Dev/test or cost-sensitive data that tolerates AZ failure
Infrequent Access (IA)	Lifecycle tier on either class	Automatically offloads cold files; retrieval charge on access

Instances in a private subnet cannot mount a new EFS file system despite correct mount commands. What is the most likely missing network rule?

Allow HTTPS port 443 from the instances to the EFS API
Allow NFS port 2049 between the instance security group and the mount-target security group
Open SSH port 22 to the mount target ENI
Enable an internet gateway on the subnet

EFS mounts over NFS on port 2049 — security groups on both sides must permit it. HTTPS reaches the control plane, not the data path. SSH and an IGW are unrelated to NFS file access.

6Right-sizing a high-IOPS database volume

Transactional databases on a single EC2 instance need predictable random I/O — that steers you to SSD, never st1 or sc1. gp3 includes 3,000 IOPS baseline and lets you provision up to 16,000 IOPS independently of disk size, which often beats legacy gp2 on cost. When the stem names sustained tens of thousands of IOPS, sub-millisecond latency, or a 99.999% durability SLA, Provisioned IOPS io2 — including Block Express tiers above 64,000 IOPS — is the exam's explicit answer.

Figure. Databases that need sustained low-latency IOPS provision io1/io2 rather than hoping for gp burst.

How it works

Eliminate HDDRandom database I/O disqualifies st1 and sc1 immediately.
Compare gp3 ceilingIf required IOPS fit within 16,000, gp3 with explicit IOPS provisioning is cost-effective.
Reach for io2Beyond gp3 limits or when the stem demands guaranteed IOPS and durability SLAs, choose io2.

Provisioning 12,000 IOPS on gp3

A single-instance MySQL database needs a sustained 12,000 random IOPS. Can gp3 meet it, and how much must you provision beyond the baseline?

gp3 baseline IOPS included3,000
Shortfall = 12,000 − 3,0009,000 IOPS to provision
gp3 maximum provisioned IOPS16,000 — 12,000 fits

Pro tip. gp3 can satisfy 12,000 IOPS with explicit provisioning, but the moment the question quotes 64,000 IOPS or mission-critical durability language, stop negotiating gp3 — io2 is the trap the distractors hide behind a number you already beat.

A mission-critical Oracle database on one EC2 instance requires guaranteed 64,000 IOPS per volume. Which EBS type?

gp3 with 16,000 provisioned IOPS
io2 Block Express
st1 Throughput Optimized HDD
gp2 sized to 20 TiB for burst credits

64,000 IOPS exceeds gp3's 16,000 ceiling — io2 Block Express is built for that tier. st1 cannot serve random database I/O. gp2 burst credits are unpredictable for sustained production databases.

Notes

EBS Fundamentals: Elastic Block Store provides network-attached block volumes to a single EC2 instance (except io1/io2 Multi-Attach), persisting independently of the instance lifecycle.
EBS Volume Types: gp3/gp2 (general SSD), io1/io2 (provisioned IOPS SSD for high-performance databases), st1 (throughput HDD), and sc1 (cold HDD for infrequent access).
EFS Fundamentals: Elastic File System is a managed NFS file system that can be mounted concurrently by thousands of EC2 instances across multiple AZs and scales automatically.
EBS Snapshots: Incremental, stored in S3, and used to back up volumes or create new volumes, optionally in another AZ or Region.
AZ Scope: An EBS volume is tied to one AZ and can only attach to instances in that AZ, whereas EFS is regional and multi-AZ by design.

Formulas

gp3 baseline: 3,000 IOPS and 125 MB/s included, independently scalable up to 16,000 IOPS and 1,000 MB/s.
io2 Block Express: up to 256,000 IOPS and 4,000 MB/s per volume, with a max size of 64 TiB.
EBS volume size: gp3/gp2/io1/io2 range from 1 GiB up to 16 TiB (io2 Block Express up to 64 TiB).
EFS storage classes: Standard and One Zone, with Infrequent Access (IA) lifecycle tiers that cut storage cost by up to ~92%.
EBS durability: io2 offers 99.999% durability; snapshots are stored redundantly in S3.

Exam traps & shortcuts

If multiple EC2 instances (or an Auto Scaling group) must share the same files, the answer is EFS, not EBS.
For a single high-IOPS database volume, choose io1/io2 Provisioned IOPS; for general workloads, gp3 is more cost-effective than gp2.
To move an EBS volume to another AZ, create a snapshot and restore it in the target AZ - volumes cannot cross AZs directly.
For large sequential throughput (big data, log processing) at low cost, choose st1 HDD, not SSD.

Reference tables

Pin these contrasts before the practice set — every distractor swaps one row.

EBS and EFS at a glance
Dimension	EBS	EFS
Access model	Block device on one instance (Multi-Attach is same-AZ exception)	Shared NFS directory tree for many instances
AZ scope	One Availability Zone per volume	Regional — mount targets per AZ
Capacity	Provision size; gp3 scales IOPS separately	Elastic — grows with stored data
Cross-AZ data move	Snapshot → new volume in target AZ	Built in — same file system ID everywhere
Typical exam trap	Using EBS for a multi-AZ shared upload folder	Using EFS for a single-instance low-latency database

Recap

Ask one disk-or-shared-files question, then match the row.

Fork: One instance block disk → EBS. Many instances, same tree → EFS.
Persistence: EBS survives stop; instance store does not — scratch versus durable.
Volume types: gp3 general SSD; io2 guaranteed IOPS; st1/sc1 sequential or cold HDD only.
Snapshots: Volumes do not hop AZs — snapshot in S3, restore a new volume in the target zone.
EFS ops: Mount target per AZ; security group opens NFS port 2049; IA lifecycle for cold files.
IOPS ceiling: gp3 tops at 16,000 IOPS — above that or at a durability SLA, io2 Block Express.

Practise EBS and EFS Storage

Reading is free and needs no account. Practice, mocks and progress live in the app.

5 exam-style questions on this topic, with explanations
A 4-question practice set that ends the chapter
Timed mocks scored with the real marking scheme
Readiness tracked per topic, kept on your device

Continue with Google — freeNo card, no trial. Works offline once installed.