Napman's Notes

EBS

Properties1
tagsreview/aws

9 min read

EBS (and AMI, Instance Store, EFS)

Summary: EBS is a network-attached block storage volume you attach to a single EC2 instance so data survives instance termination. This note also covers AMIs (pre-baked instance images), EC2 Instance Store (fast ephemeral local disk), and EFS (a shared file system many instances can mount at once). Knowing when to pick each is a core exam skill.

Key Concepts

  • EBS = a “network USB stick” - a network drive you attach to a running EC2 instance so its data persists even after the instance terminates.
  • It uses the network to talk to the instance (not a physical disk), so expect slightly higher latency. It can be detached from one instance and reattached to another quickly.
  • Locked to one Availability Zone. A volume in us-east-1a cannot attach to an instance in us-east-1b. To move it, snapshot it and restore the snapshot in the other AZ.
  • One instance at a time, except the Multi-Attach feature (io1/io2 only - see below).
  • You can leave a volume unattached and still pay for it.
  • EBS attaches to EC2 instances only - it is not usable by other services. (For shared file storage use EFS; for object storage use S3.)

What is an Availability Zone (AZ)?

A physically separate datacenter inside a Region. us-east-1 is the Region; us-east-1a, 1b, 1c are its AZs. They’re isolated for fault tolerance but linked by low-latency connections. An EBS volume lives in exactly one AZ.

Provisioning & Capacity

  • You provision capacity up front: size in GB and IOPS. You’re billed for everything provisioned, whether or not you use it.
  • You can increase a volume’s size/IOPS over time (not decrease).

IOPS vs Throughput vs Latency

  • IOPS = read/write operations per second - matters for many small random operations (databases).
  • Throughput = data moved per second (MiB/s) - matters for large sequential files (big data, logs).
  • Latency = time for a single operation to complete. Because EBS is network-attached, latency is slightly higher than a local disk.

Delete on Termination

Controls what happens to a volume when its EC2 instance terminates:

  • Root volume: deleted by default (attribute enabled).
  • Any other attached volume: not deleted by default (attribute disabled).

Why is the root deleted by default? The root holds the OS and is treated as disposable - the intended pattern is to rebuild instances from an AMI rather than hand-maintain them. Extra data volumes default to keep because they usually hold data you care about. Both attributes can be flipped.

EBS Snapshots

  • A point-in-time backup of a volume.
  • Not required to detach before snapshotting, but recommended for consistency.
  • Can be copied across AZ or Region (this is how you migrate a volume between AZs).
  • Snapshots are not automatic on their own - a plain snapshot is on-demand. Automate them with Amazon Data Lifecycle Manager (DLM) or AWS Backup on a schedule.

Snapshot features:

  • EBS Snapshot Archive - move a snapshot to an archive tier ~75% cheaper; restoring takes 24-72 hours.
  • Recycle Bin for Snapshots - retention rules to recover accidentally deleted snapshots (1 day to 1 year).
  • Fast Snapshot Restore (FSR) - force full initialization so there’s no latency on first use; expensive.

AMI (Amazon Machine Image)

  • A customized image of an EC2 instance - your OS, software, configuration, and monitoring baked in.
  • Gives faster, more consistent boot because software is pre-packaged.
  • Region-specific, but can be copied to other Regions.
  • Launch instances from: a public AMI (AWS-provided), your own AMI, or an AWS Marketplace AMI (made/sold by others).

AMI build process (from an EC2 instance):

  1. Launch an EC2 instance and customize it.
  2. Stop it (for data integrity).
  3. Build the AMI - this also creates EBS snapshots automatically.
  4. Launch new instances from that AMI.

So yes: you use a “template” EC2 instance to bake the AMI. Building the AMI captures EBS snapshots under the hood. New instances launched from it boot pre-configured. It’s region-specific by default - copy it to another Region before launching there.

Why use an AMI over a user-data script (the "golden AMI" pattern)?

Beyond faster boot: consistency (software is baked in, no failed downloads or version drift at launch), no external repo dependency at boot, and repeatable at scale (Auto Scaling won’t re-run installs on every new instance). Often combined: a golden AMI for heavy setup + a small user-data script for last-mile config.

EC2 Instance Store

  • A physical disk local to the host - much higher I/O performance than a network EBS volume.
  • Ephemeral: storage is lost when the instance stops or the hardware fails.
  • Good for buffer / cache / scratch / temporary data only.

EBS Volume Types

For the exam, map workload → type (you won’t be asked exact IOPS numbers):

TypeMediaBest for
gp2 / gp3SSDGeneral purpose, balances price/performance - the default choice
io1 / io2 Block ExpressSSDHighest performance, low-latency/high-throughput, mission-critical databases; only family that supports Multi-Attach
st1HDDThroughput-intensive, frequently accessed - big data, data warehouses, log processing
sc1HDDCheapest, infrequently accessed cold data

Boot volumes must be SSD (gp2/gp3 or io1/io2). HDD types (st1/sc1) cannot be used as boot volumes.

Also remember: gp2 ties IOPS to disk size (bigger disk = more IOPS), while gp3 and io1 let you scale IOPS independently of size.

EBS Multi-Attach

  • io1 / io2 only.
  • Attach the same volume to up to 16 EC2 instances in the same AZ, each with full read/write.
  • Use case: higher availability in clustered Linux apps (e.g. Teradata) - if one node fails, the others still have direct access to the same volume, so the app stays up.
  • The application must manage concurrent writes, and you must use a cluster-aware file system (a normal file system would corrupt data with multiple writers).

EFS (Elastic File System)

  • A managed NFS file system that many EC2 instances can mount at once, across multiple AZs.
  • Highly available, auto-scales to petabytes, pay-per-use (no capacity planning), pricier than EBS.
  • Linux only (POSIX file system); not Windows.
  • Uses security groups to control access; supports encryption at rest via KMS.
  • Use cases: content management, web serving, data sharing across a fleet (e.g. WordPress).

EFS vs EBS - the key distinction

EBS = a raw disk for (usually) one instance in one AZ - like a USB drive for a single machine. EFS = a shared network folder many instances across multiple AZs mount simultaneously. EFS is not stored inside an EBS volume; they’re separate services. Use EBS when one instance needs a disk; use EFS when a fleet must share the same files.

(NFSv4.1 is just the protocol that lets multiple Linux instances mount the same file system - you don’t need its internals for the exam.)

EFS Performance & Throughput (settings you choose)

  • Performance Mode (set at creation, can’t change later):
    • General Purpose (default) - latency-sensitive: web servers, CMS.
    • Max I/O - higher latency but more throughput/parallelism: big data, media processing.
  • Throughput Mode (changeable):
    • Bursting - throughput scales with stored data (more data = more baseline), and small file systems can temporarily burst above baseline using accumulated credits.
    • Provisioned - set a fixed throughput regardless of size.
    • Elastic - auto-scales up/down with the workload (up to ~3 GiB/s reads, 1 GiB/s writes); best for unpredictable workloads.

EFS Storage Classes

  • Storage tiers (moved automatically by lifecycle policies - rules that shift files between tiers based on how recently they were accessed, to save cost):
    • Standard - frequently accessed.
    • Infrequent Access (EFS-IA) - cheaper storage, small retrieval cost.
    • Archive - rarely accessed (a few times a year), ~50% cheaper.
  • Availability/durability:
    • Standard - Multi-AZ, for production.
    • One Zone - single AZ, cheaper, for dev; backup on by default; works with IA (EFS One Zone-IA).

Exam Tips & Gotchas

EBS vs EFS vs Instance Store - the classic comparison

  • EBS - one instance (except Multi-Attach io1/io2), locked to one AZ, persistent. Migrate across AZ via snapshot → restore.
  • EFS - shared across 100s of instances across AZs, Linux only, pay-per-use, higher price, supports storage tiers. Great for shared website files (WordPress).
  • Instance Store - local physical disk, fastest I/O, ephemeral (lost on stop/hardware failure). Cache/scratch only.
  • Root EBS volume is deleted on termination by default; extra volumes are not.
  • Only io1/io2 support Multi-Attach; max 16 instances, same AZ, cluster-aware FS required.
  • gp2 scales IOPS with size; gp3/io1 scale IOPS independently.
  • HDD (st1/sc1) cannot be boot volumes.
  • EBS backups consume I/O - avoid running them while the app is under heavy traffic.

Review Questions

Review Log

  • 2026-07-25 | Good | Gaps: gp2 ties IOPS to size vs gp3/io1 independent IOPS (confused HDD/SSD split), HDD types are throughput-focused not IOPS-focused, EFS Linux-only restriction, boot volume = root volume | Solid: AZ vs Region, EBS AZ locking + snapshot migration, delete-on-termination, Multi-Attach limits, EFS multi-instance use case, Instance Store ephemeral risk, AMI golden image purpose, snapshots on-demand | Next session: probe gp2 vs gp3 IOPS scaling and EFS Linux-only gotcha

Graph View

Backlinks