Amazon EC2 – Instance Storage

1. What an EBS Volume is

An EBS (Elastic Block Store) Volume is storage that lives on the network and plugs into an instance that is already running. Its point is persistence: data on an EBS volume survives the termination of the instance.

Two defining constraints:

• It can be mounted to one instance at a time (at the introductory level — section 7 covers the exception).
• It is bound to a specific Availability Zone.

The analogy the deck uses is a “network USB stick”: something you plug into one machine, unplug, and plug into another.

What “network drive” implies

Because it is a network drive rather than a physical one, several consequences follow:

• It communicates with the instance over the network, so there may be a small amount of latency.
• It can be detached from one EC2 instance and attached to another quickly.
• It is locked to an AZ: a volume in us-east-1a cannot be attached to an instance in us-east-1b. To move it across, you first take a snapshot.
• It has provisioned capacity — a size in GB and an IOPS figure — and you are billed for all the capacity you provision, used or not.
• You can increase the capacity of the drive over time.

An instance can have several volumes attached at once, and a volume can sit unattached, still costing money.

Exam tip

The AZ lock is the most frequently exploited fact here. Any scenario about moving or copying a volume to another AZ or Region goes through a snapshot; there is no direct attach across AZ boundaries.

2. The Delete on Termination attribute

This attribute controls what happens to an EBS volume when the EC2 instance terminates. The defaults are asymmetric and worth memorizing:

Volume	Default
Root EBS volume	Deleted on termination (attribute enabled)
Any other attached EBS volume	Not deleted (attribute disabled)

You can change the setting from the AWS Console or the AWS CLI. The typical use case is the opposite of the default: preserving the root volume when the instance is terminated.

3. EBS Snapshots

A snapshot is a backup of an EBS volume at a point in time.

• It is not necessary to detach the volume to take a snapshot, though it is recommended.
• You can copy snapshots across AZs or Regions — which, as above, is how a volume effectively travels.

Three snapshot features

Feature	What it does
EBS Snapshot Archive	Moves a snapshot to an archive tier that is 75% cheaper, but restoring from the archive takes 24 to 72 hours
Recycle Bin for EBS Snapshots	Rules that hold on to deleted snapshots for a retention window you pick — 1 day up to 1 year — so one deleted by mistake can be brought back
Fast Snapshot Restore (FSR)	Forces full initialisation of a snapshot so there is no latency on first use — and it is expensive

Exam tip

Each feature answers a differently worded question. “Cheaper long-term storage of backups, restore time is not a concern” is Archive; “someone deleted a snapshot by mistake” is the Recycle Bin; “the volume restored from a snapshot is slow the first time each block is read” is Fast Snapshot Restore.

4. AMI – Amazon Machine Image

An AMI is a customization of an EC2 instance: you add your own software, configuration, operating system and monitoring, and bake all of it into an image.

The payoff is faster boot and configuration time, because everything is pre-packaged rather than installed at launch.

AMIs are built for a specific Region, and can be copied across Regions. You can launch an instance from three sources:

• A Public AMI — provided by AWS.
• Your own AMI — you build and maintain it.
• An AWS Marketplace AMI — made by someone else, potentially sold.

Building an AMI from an EC2 instance

1. Start an EC2 instance and customize it — install and configure what you need.
2. Stop the instance, for data integrity.
3. Build the AMI. This also creates EBS snapshots behind the scenes.
4. Launch instances from that AMI, including in other AZs.

Real-world example

Your web server needs a package list, a hardened config and an agent installed. Doing that through EC2 User Data means every launch waits several minutes for downloads. Bake the same setup into a custom AMI once, and each new instance in the Auto Scaling group joins the fleet in seconds — a direct win when you are scaling out under load.

5. EC2 Instance Store

EBS volumes are network drives with good but limited performance. When you need a high-performance hardware disk, you use the EC2 Instance Store — physical storage attached to the host itself, capable of very high IOPS.

The trade-off is severe and is the whole point of the topic:

• Instance stores lose their storage when the instance is stopped — they are ephemeral.
• They are good for buffers, caches, scratch data and temporary content.
• There is a risk of data loss if the hardware fails.
• Backups and replication are your responsibility.

Exam tip

“Better I/O than EBS” and “data disappears on stop” always travel together. If a question wants both high local IOPS and durability, the answer is instance store plus your own replication, or an io1/io2 EBS volume — never instance store alone for data that matters.

6. The six EBS volume types

EBS volumes come in six types, across two technologies. They are characterised by Size | Throughput | IOPS.

Type	Technology	Description
gp2 / gp3	SSD	General purpose SSD, balancing price and performance for a wide variety of workloads
io1 / io2 Block Express	SSD	Highest-performance SSD, for mission-critical low-latency or high-throughput workloads
st1	HDD	Low-cost HDD for frequently accessed, throughput-intensive workloads
sc1	HDD	Lowest-cost HDD for less frequently accessed workloads

One rule cuts across all of them: a volume can boot an instance only if it is gp2/gp3 or io1/io2 Block Express.

General Purpose SSD (gp2 / gp3)

Cost-effective, low-latency storage for system boot volumes, virtual desktops, development and test environments. Size range 1 GiB to 16 TiB.

• gp3: a baseline of 3,000 IOPS and 125 MiB/s throughput. You can raise IOPS to 16,000 and throughput to 1,000 MiB/s independently of each other and of size.
• gp2: small volumes can burst to 3,000 IOPS. Size and IOPS are linked at 3 IOPS per GB, with a maximum of 16,000 IOPS — which you reach at 5,334 GB.

Provisioned IOPS (PIOPS) SSD (io1 / io2 Block Express)

For critical business applications needing sustained IOPS performance, or any application that needs more than 16,000 IOPS. It is the natural fit for database workloads, which are sensitive to storage performance and consistency.

• io1 (4 GiB to 16 TiB): maximum 64,000 PIOPS on Nitro EC2 instances, 32,000 on others. PIOPS can be increased independently of storage size.
• io2 Block Express (4 GiB to 64 TiB): sub-millisecond latency, maximum 256,000 PIOPS with an IOPS:GiB ratio of 1,000:1, and support for EBS Multi-Attach.

Hard Disk Drives (st1 / sc1)

Both HDD types cannot be boot volumes, and both span 125 GiB to 16 TiB.

• Throughput Optimized HDD (st1): for Big Data, data warehouses and log processing. Max throughput 500 MiB/s, max IOPS 500.
• Cold HDD (sc1): for infrequently accessed data and scenarios where lowest cost matters most. Max throughput 250 MiB/s, max IOPS 250.

Exam tip

The numbers that decide questions: 16,000 IOPS is the gp2/gp3 ceiling, so anything above it needs io1/io2. gp3 decouples IOPS from size, gp2 does not. HDD cannot boot. And io2 Block Express is the only one with sub-millisecond latency, 256,000 IOPS and Multi-Attach.

7. EBS Multi-Attach (io1/io2 family)

Multi-Attach puts one EBS volume on several EC2 instances at once, as long as they all sit in the same AZ, and every one of them gets full read and write access to that high-performance volume.

The constraints:

• Up to 16 EC2 instances at a time.
• All instances must be in the same Availability Zone.
• Applications must manage concurrent write operations themselves.
• You must use a cluster-aware file system — not XFS, EXT4 and the like.

The use case is achieving higher application availability in clustered Linux applications, Teradata being the deck’s example.

Exam tip

Multi-Attach is io1/io2 only, same AZ only, 16 instances maximum, cluster-aware file system required. If a question wants many instances across several AZs sharing files, that is EFS, not Multi-Attach.

8. EBS Encryption

When you create an encrypted EBS volume, you get all of the following:

• Data at rest is encrypted inside the volume.
• All data in flight between the instance and the volume is encrypted.
• All snapshots are encrypted.
• All volumes created from those snapshots are encrypted.

The operational properties matter as much as the guarantees:

• Encryption and decryption are handled transparently — there is nothing for you to do.
• Encryption has minimal impact on latency.
• EBS encryption uses keys from KMS (AES-256).
• Copying an unencrypted snapshot allows you to encrypt it during the copy.
• Snapshots of encrypted volumes are encrypted.

Encrypting an unencrypted EBS volume

There is no in-place switch. The procedure is:

1. Create an EBS snapshot of the volume.
2. Encrypt the snapshot, using the copy operation.
3. Create a new EBS volume from that snapshot — it will be encrypted.
4. Attach the encrypted volume to the original instance.

9. Amazon EFS – Elastic File System

EFS is a managed NFS (network file system): a large number of EC2 instances can mount it simultaneously, and — crucially — those instances may sit in different AZs. It is highly available and scalable, but expensive, around 3x the price of gp2, and billed pay per use.

Use cases: content management, web serving, data sharing, WordPress.

Characteristics and limits

• Uses the NFSv4.1 protocol.
• Uses a security group to control access to the file system.
• Compatible with Linux-based AMIs only — not Windows.
• Encryption at rest using KMS.
• It is a POSIX file system with a standard file API.
• The file system scales automatically, is pay-per-use, and needs no capacity planning.

Performance and modes

At scale, EFS handles thousands of concurrent NFS clients and 10 GB+/s of throughput, growing automatically to a petabyte-scale file system.

Performance Mode — set at EFS creation time:

• General Purpose (default): for latency-sensitive use cases such as web servers and CMSs.
• Max I/O: higher latency but higher throughput, for highly parallel work such as big data and media processing.

Throughput Mode:

• Bursting: 1 TB gives 50 MiB/s, with bursts up to 100 MiB/s.
• Provisioned: set your throughput regardless of storage size — for example 1 GiB/s with only 1 TB stored.
• Elastic: scales throughput automatically up and down with the workload, up to 3 GiB/s for reads and 1 GiB/s for writes; for unpredictable workloads.

EFS storage classes

Storage tiers, driven by the lifecycle management feature that moves a file after N days of no access:

• Standard: for frequently accessed files.
• Infrequent Access (EFS-IA): lower price to store, but you pay to retrieve files.
• Archive: for rarely accessed data — a few times a year — and 50% cheaper.

Availability and durability come as a separate choice:

• Standard: Multi-AZ, the right answer for production.
• One Zone: a single AZ, good for dev, with backup enabled by default and compatible with IA (EFS One Zone-IA). Over 90% cost savings.

Exam tip

Two EFS dimensions are easy to conflate: the storage tier (Standard / IA / Archive, chosen by access frequency and moved by lifecycle policy) and the availability class (Standard Multi-AZ versus One Zone). A question about cost for dev environments points at One Zone; a question about files nobody has touched in 60 days points at a lifecycle policy moving them to IA.

10. EBS versus EFS versus Instance Store

What EBS is

• Serves one instance at a time — except Multi-Attach on io1/io2.
• Locked at the Availability Zone level.
• gp2: IOPS increases as the disk size increases. gp3 and io1: IOPS can be increased independently.
• To migrate a volume across AZs you take a snapshot and restore it in the other AZ.
• EBS backups use IO, so you should not run them while the application is handling heavy traffic.
• Root EBS volumes are terminated by default when the instance terminates — you can disable that.

What EFS is

• For mounting hundreds of instances across AZs.
• For sharing website files — WordPress is the standard example.
• Linux instances only (POSIX).
• A higher price point than EBS, which you can offset with storage tiers.

Side by side

	EBS	EFS	Instance Store
Shape	Network block volume	Managed NFS file system	Physical disk on the host
Attach	One instance (16 with io1/io2 Multi-Attach, same AZ)	Many instances, across AZs	The one host instance
Scope	One AZ	Multi-AZ (or One Zone)	One instance
Persistence	Survives instance termination	Fully managed and durable	Ephemeral — lost on stop
OS	Any	Linux only	Any
Performance	gp2/gp3 up to 16,000 IOPS; io2 Block Express up to 256,000	Scales to 10 GB+/s	Highest local IOPS
Cost	Provisioned capacity	~3x gp2, pay per use	Included with the instance

Real-world example

A WordPress site on three instances across three AZs has to serve the same uploaded media from all of them. EBS cannot do it — the volume is stuck in one AZ and one instance. EFS can: every instance mounts the same file system through a mount target in its own AZ, and an uploaded image is instantly visible to all three.

Quick recap

Item	What to remember for the exam
EBS Volume	Network drive, “network USB stick”, persists past termination, one instance at a time, locked to one AZ, provisioned size and IOPS, billed for what you provision
Moving a volume	Snapshot, then restore in the other AZ or Region
Delete on Termination	Root volume deleted by default; other volumes kept by default; changeable via Console or CLI
Snapshots	Point-in-time backup, no detach required (but recommended), copyable across AZ and Region
Snapshot features	Archive (75% cheaper, 24–72 h restore), Recycle Bin (retain 1 day to 1 year), Fast Snapshot Restore (no first-use latency, expensive)
AMI	Pre-baked instance customization, faster boot, built per Region and copyable; Public, your own, or Marketplace; build = launch, customize, stop, create AMI
Instance Store	Physical disk, best I/O, ephemeral — lost on stop; for buffer, cache, scratch; backups are your job
Volume types	gp2/gp3 and io1/io2 Block Express (SSD, bootable); st1 and sc1 (HDD, not bootable)
gp3 vs gp2	gp3: baseline 3,000 IOPS / 125 MiB/s, up to 16,000 IOPS and 1,000 MiB/s independently. gp2: 3 IOPS per GB, max 16,000 at 5,334 GB
io1 / io2	io1 max 64,000 PIOPS on Nitro (32,000 otherwise), 4 GiB–16 TiB; io2 Block Express sub-ms latency, 256,000 PIOPS, 1,000:1 IOPS:GiB, 4 GiB–64 TiB, Multi-Attach
st1 / sc1	st1 500 MiB/s and 500 IOPS (big data, logs); sc1 250 MiB/s and 250 IOPS (lowest cost); both 125 GiB–16 TiB
Multi-Attach	io1/io2 only, same AZ, up to 16 instances, cluster-aware file system, app handles concurrent writes
EBS Encryption	KMS AES-256; at rest, in flight, snapshots and derived volumes; transparent, minimal latency; encrypt an existing volume via snapshot, encrypted copy, new volume
EFS	Managed NFSv4.1, many instances multi-AZ, security-group controlled, Linux only, KMS encryption at rest, auto-scaling, ~3x gp2
EFS modes	Performance: General Purpose or Max I/O. Throughput: Bursting, Provisioned, Elastic (up to 3 GiB/s read, 1 GiB/s write)
EFS classes	Standard, IA, Archive (50% cheaper) via lifecycle policy; Standard Multi-AZ for prod, One Zone for dev (90%+ savings)