AWS Notes: EC2 - Storage

Posted Nov 29, 2025

By Emre BERBER

14 min read

This is my EC2 storage notes. I’m covering EBS volumes, instance store, and other storage options for EC2 instances.

EBS (Elastic Block Store)

EBS is persistent block storage for EC2 instances. Think of it as a virtual hard drive that you can attach to your instances. Unlike instance store, EBS volumes persist even after you stop or terminate the instance.

Persistent storage (survives instance stop/terminate)
Can only attach to instances in the same Availability Zone (AZ-specific)
Can detach and attach to different instances (same AZ only)
Can create snapshots for backup
Can encrypt volumes
Can resize volumes (increase size, change type)
Can create multiple volumes and attach to one instance

EBS Volume Types

For detailed information, check the AWS documentation on EBS volume types.

Volume Type	Use Case	IOPS	Throughput	Min Size	Max Size	Boot Volume
gp3	General purpose (most workloads)	3,000 (up to 16,000)	125 MB/s (up to 1,000 MB/s)	1 GB	16 TB	Yes
gp2	General purpose (legacy)	3 IOPS/GB (up to 16,000)	250 MB/s	1 GB	16 TB	Yes
io2 Block Express	High performance, mission-critical	Up to 256,000	Up to 4,000 MB/s	4 GB	64 TB	Yes
io2	High performance, mission-critical	Up to 64,000	Up to 1,000 MB/s	4 GB	16 TB	Yes
io1	High performance (legacy)	Up to 64,000	Up to 1,000 MB/s	4 GB	16 TB	Yes
st1	Throughput optimized (sequential workloads)	500	500 MB/s	125 GB	16 TB	No
sc1	Cold HDD (infrequently accessed)	250	250 MB/s	125 GB	16 TB	No

Key differences:

gp3/gp2: General purpose, default choice. gp3 is newer and 20% cheaper.
io2 Block Express/io2/io1: High IOPS, guaranteed performance. Use when you need guaranteed high IOPS (databases, mission-critical apps).
st1: High throughput for sequential workloads. Cannot be boot volume.
sc1: Lowest cost, lowest performance. For rarely accessed data. Cannot be boot volume.

Delete on Termination

Controls whether the EBS volume is deleted when the instance terminates.

Default behavior:

Root volume: Delete on Termination = YES (OS disk usually not needed after termination)
Additional volumes: Delete on Termination = NO (data should be preserved)

Can configure per volume when launching instance or attaching volume.

EBS Multi-Attach

Multi-Attach allows you to attach the same EBS volume to multiple EC2 instances in the same Availability Zone.

Supported volume types:

io1 and io2 only (not gp3, gp2, st1, sc1)
io2 Block Express does not support multi-attach

When to use:

Clustered applications
Applications that need shared storage across multiple instances
High availability setups where multiple instances need access to same data

Important requirements:

All instances must be in the same Availability Zone
Volume must be io1 or io2 type
File system must support concurrent access (e.g., cluster file systems)
All instances can read and write simultaneously

Limitations:

Max 16 instances per volume
Only io1/io2 volumes (not io2 Block Express)
Same AZ only

How to use:

Create an io1 or io2 volume
Attach it to first instance (normal attachment)
Attach same volume to additional instances (up to 16 total)
Format and mount with cluster file system (e.g., GFS2, OCFS2)

Using regular file systems (ext4, xfs) with multi-attach can cause data corruption. Use cluster file systems that support concurrent access. Alternatively, consider using EFS (managed file system) for shared storage across multiple instances.

EBS Encryption

Encrypts data on disk and data moving between instance and volume. Uses KMS keys (AWS managed or your own).

How to encrypt new volume:

When creating volume or launching instance, just check Encrypt this volume. That’s it. No performance hit.

How to encrypt existing unencrypted volume:

Can’t encrypt it directly. Here’s what I do:

Create snapshot of the unencrypted volume
Copy snapshot → Check Encrypt this snapshot → Choose KMS key
Create new volume from the encrypted snapshot
Attach new encrypted volume to instance (replace the old one)
Delete old unencrypted volume and snapshot

Bit of a hassle, but that’s the only way.

Account-level default encryption:

Can enable this so all new volumes are encrypted automatically. Still can create unencrypted ones manually if you want.

Things to remember:

Once encrypted, can’t disable it
Encrypted volumes create encrypted snapshots (and vice versa)
EC2 Hibernate needs encrypted root volume
Can share encrypted volumes/snapshots with other accounts (they need KMS key access)

Creating and Attaching EBS Volume to Existing Instance

Let’s create a new EBS volume and attach it to an existing EC2 instance.

Step 1: Check Instance Availability Zone

First, we need to know which AZ our instance is in:

Go to EC2 → Instances
Select your instance
Check the Availability Zone in the instance details (e.g., eu-central-1a)

The EBS volume must be in the same Availability Zone as the instance. You can’t attach a volume from a different AZ.

Step 2: Create EBS Volume

Go to EC2 → Elastic Block Store → Volumes → Create volume
Availability Zone: Select the same AZ as your instance
Volume type: Choose your type (e.g., gp3 for general purpose)
Size: Enter size in GiB (e.g., 10)
Encryption: Choose if you want encryption (optional)
Snapshot ID: Leave empty (we’re creating a new empty volume)
Click Create volume

Step 3: Attach Volume to Instance

Select the volume you just created
Click Actions → Attach volume
Instance: Select your instance from the dropdown (only instances in the same AZ will appear)
Device name: AWS will suggest a device name (e.g., /dev/sdf). You can change it if needed, but the default is usually fine.
Click Attach

If you don’t see your instance in the dropdown, it means the instance is in a different AZ. You’ll need to create the volume in the correct AZ.

Step 4: Verify Attachment

Go to EC2 → Instances
Select your instance
Go to Storage tab
You should see your new volume listed

The volume is now attached, but you still need to format and mount it in the operating system (if it’s a new empty volume).

Summary

Always check instance AZ before creating volume
Volume and instance must be in the same AZ
Can attach while instance is running (no need to stop)
Device name is assigned automatically (can customize)

EBS Snapshots

Snapshots are point-in-time backups of your EBS volumes. They’re stored in S3 (you don’t see them in S3 console, but they’re there).

Incremental backups (only changed blocks since last snapshot)
Can create snapshots of attached volumes (no need to detach)
Can create AMI from snapshot
Can copy snapshots across regions
Can share snapshots with other AWS accounts
Encrypted volumes create encrypted snapshots

How snapshots work:

First snapshot: Full backup
Subsequent snapshots: Only changed blocks (incremental)
When you delete a snapshot, only blocks unique to that snapshot are deleted
To restore: Create new volume from snapshot

How to create a snapshot:

Go to EC2 → Elastic Block Store → Volumes
Select the volume you want to snapshot
Click Actions → Create snapshot
Add description and tags (optional)
Click Create snapshot

Note: You can create snapshots of attached volumes while the instance is running. No need to detach or stop the instance.

How to create volume from snapshot:

Go to EC2 → Elastic Block Store → Snapshots
Select the snapshot you want to restore
Click Actions → Create volume from snapshot
Availability Zone: Choose any AZ you want (unlike original volume, you can pick different AZ)
Size: Can increase size (must be at least snapshot size, can’t decrease)
Volume type: Can change type (e.g., gp2 to gp3)
Encryption: Can enable encryption even if snapshot wasn’t encrypted
Click Create volume

Important: When creating volume from snapshot, you can choose any Availability Zone (not limited to original volume’s AZ). This is how you move volumes between AZs.

Archive Tier

For long-term retention. 75% cheaper than standard, but restore takes 24-72 hours.

When to use: Compliance requirements, rarely accessed snapshots, cost optimization.

How to use: Select snapshot → Actions → Archive snapshot. To restore: Actions → Restore snapshot → Wait 24-72 hours.

Fast Snapshot Restore (FSR)

Eliminates initialization delay when restoring snapshots. Volumes are instantly ready with full performance.

When to use: Critical applications, production databases needing instant restore.

Must enable per availability zone
Costs extra (hourly fee)
Works with io1, io2, gp3 volumes
Max 50 snapshots per AZ

How to enable: Snapshot → Actions → Enable fast snapshot restore → Select AZs.

Recycle Bin

Protects snapshots from accidental deletion. Deleted snapshots go to Recycle Bin for retention period (1-365 days).

How it works:

Must enable before deletion
Free during retention period
Can restore during retention period
Permanently deleted after retention period

How to enable: EC2 → Lifecycle Manager → Recycle Bin → Create retention rule → Set period (1-365 days).

AMI (Amazon Machine Image)

AMI is a template for creating EC2 instances. It contains the operating system, applications, and configuration needed to launch an instance.

What’s in an AMI:

Operating system (Linux, Windows)
Application software
Configuration settings
Data volumes

AMI features:

Root device is EBS volume (EBS-backed AMI)
Can stop/start instances (data persists)
Can create AMI from running/stopped instance
Faster instance launch
Can modify instance attributes (instance type, etc.) after launch

AMI lifecycle:

Create AMI from running/stopped instance
Launch instances from AMI
Deregister AMI when no longer needed (snapshots remain, must delete separately)
Copy AMI to different regions/accounts

How to create AMI:

Go to EC2 → Instances
Select your instance (running or stopped)
Click Actions → Image and templates → Create image
Image name: Give it a name
No reboot: Check if you want to create AMI without stopping instance (recommended for running instances)
Click Create image

What happens:

Creates snapshot of root volume (and any additional volumes if selected)
Snapshots are stored in S3 (you don’t see them in S3 console)

Important notes about snapshots:

If you delete snapshots: AMI becomes unusable (can’t launch instances from it)
If you delete AMI: Snapshots remain (must delete separately to stop charges)
Copying AMI to another region: Snapshots are automatically copied with the AMI
Cost: You pay for snapshot storage even after deregistering AMI

How to launch instance from AMI:

Go to EC2 → AMIs
Select your AMI
Click Launch instance from AMI
Configure instance (type, storage, networking, etc.)
Launch

AMI sharing:

Can share AMI with other AWS accounts
Can make AMI public (anyone can use it)
Shared AMIs appear in recipient’s AMI list
Recipient pays for instances launched from shared AMI

Important notes:

AMI is region-specific (must copy to use in different region)
EBS-backed AMI creates snapshots (you pay for snapshot storage)
Deregistering AMI doesn’t delete snapshots (must delete separately)
Can’t modify AMI after creation (must create new AMI)
AMI includes root volume snapshot (and additional volumes if selected during creation)

EC2 Instance Store

Instance Store is the physical NVMe/SATA SSD on the EC2 instance’s physical host machine.

Physical disk (not network-attached like EBS)
Super fast (very high IOPS and low latency)
Ephemeral - data is lost when instance stops, terminates, or host changes
Free (included with instance)
Fixed size (depends on instance type)

When to use:

Temporary data (cache, buffers, scratch space)
High-performance temporary storage
Data that can be rebuilt quickly
Applications that don’t need persistence

When NOT to use:

Boot volumes (use EBS instead)
Databases (data must persist)
Any data that needs to survive instance stop/terminate

Important notes:

Cannot stop instance (only terminate) - stopping loses all data
Cannot detach/attach to different instances
Cannot create snapshots
Data survives reboot, but not stop/terminate
Some instance types have no instance store (check before launching)

How to use Instance Store:

When launching instance:

Select an instance type that supports instance store (e.g., c5d, m5d, r5d)
Instance store is automatically available (no need to configure)
Check instance type details to see instance store size

After instance is running:

SSH into your instance
Instance store appears as block devices (e.g., /dev/nvme1n1 on Linux)

Format and mount it like any other block device:

  
# Check available instance store devices
lsblk
     
# Format (example for /dev/nvme1n1)
sudo mkfs -t ext4 /dev/nvme1n1
     
# Create mount point
sudo mkdir /mnt/instance-store
     
# Mount
sudo mount /dev/nvme1n1 /mnt/instance-store

Use it for:

Temporary files, cache, logs
High-performance temporary storage
Scratch space for processing

Instance store devices vary by instance type. Check AWS documentation for your specific instance type to see device names and sizes.

Instance Store vs EBS:

Feature	Instance Store	EBS
Persistence	Lost on stop/terminate	Survives stop/terminate
Performance	Very high (local NVMe)	Good to excellent
Cost	Free (included)	Pay per GB
Resize	Fixed size	Can resize
Backup	No snapshots	Snapshots available
Use case	Temporary data	Persistent data

EFS (Elastic File System)

EFS is a managed NFS file system. Multiple EC2 instances can mount and access it at the same time. Think of it as a shared network drive that scales automatically.

EFS vs EBS:

Feature	EFS	EBS
Type	File system (NFS)	Block storage
Multiple instances	Yes (simultaneous access)	No (one instance, unless multi-attach)
Availability Zones	Cross-AZ (multi-AZ)	Single AZ only
Protocol	NFS v4.1	Block device
Performance	Lower latency, shared access	Higher IOPS, dedicated
Use case	Shared storage, web content	Databases, boot volumes
Pricing	Pay per GB stored	Pay per GB provisioned
Scaling	Auto-scales	Fixed size (can resize)
Multi-attach	Built-in (multiple instances)	Only io1/io2, same AZ

When to use EFS:

Need shared storage for multiple instances
Web servers sharing content
Content management systems
Container storage (ECS, EKS)
Data analytics with shared datasets

Performance modes:

Mode	When to use
General Purpose	Most workloads (default)
Max I/O	High throughput, lots of parallel access

Throughput modes:

Mode	How it works
Bursting	Throughput scales with size (default)
Provisioned	Set specific throughput (pay extra)
Elastic	Auto-scales based on demand

Storage classes:

Standard: Frequently accessed files
EFS-IA (Infrequent Access): Rarely accessed files - 90% cheaper storage, but retrieval fee

Lifecycle policies: Move files to EFS-IA automatically after X days of no access. Saves money, but watch out for retrieval fees if you access those files later.

How to create EFS:

When creating EFS, you’ll see these options:

VPC: Choose the VPC where your instances are (or will be)
Availability Zones: Select AZs where you want mount targets. You can select multiple AZs (recommended for high availability). Each AZ gets a mount target.
Security groups:
- Check Automatically create and attach security group (AWS creates security group that allows port 2049 from your instances)
- Or create/select your own security group (must allow NFS traffic - port 2049 from your instances)
Performance mode:
- General Purpose: Default, low latency (use this unless you need Max I/O)
- Max I/O: Higher throughput, more parallel access, slightly higher latency
Throughput mode:
- Bursting: Default, throughput scales with file system size
- Provisioned: Set specific throughput (pay extra, use if you need guaranteed throughput)
- Elastic: Auto-scales based on demand (newer option)
Encryption:
- At rest: Encrypts data on disk (uses KMS)
- In transit: Encrypts data when mounting (TLS)
Lifecycle management: Automatically move files to EFS-IA after X days of no access (saves money)

Mount on instance:

Auto-mount when creating instance:

When launching EC2 instance:

Go to File systems section
Click Add file system
Select your EFS file system
Choose mount point (e.g., /mnt/efs)
Check Automatically mount with user data script
AWS automatically adds the mount script to User Data

That’s it! EFS will be mounted automatically when instance starts.

Important things:

Must be in same VPC (or connected via peering/VPN)
Security groups must allow NFS (port 2049)
Can encrypt at rest and in transit
Can create access points for different mount paths
EFS-IA retrieval fee - only use lifecycle policies if files are truly infrequent

Key Takeaways

EBS: AZ-specific, one instance per volume (unless multi-attach with io1/io2). Root volume deletes on termination by default, additional volumes don’t.
EBS Volume Types: gp3 for general purpose, io2/io1 for high IOPS, st1/sc1 for sequential workloads (can’t be boot volume).
Snapshots: Incremental backups in S3. Delete snapshot = AMI unusable. Delete AMI = snapshots remain (delete separately).
AMI: Region-specific, creates snapshots, depends on snapshots (don’t delete them).
Instance Store: Ephemeral, super fast, free, but data lost on stop/terminate.
EFS: Shared file system, multiple instances, cross-AZ, NFS protocol, auto-scales.