Attach EBS Volumes to EC2

You’ve launched an EC2 instance, configured security groups, and maybe even deployed a web server. But what happens when your application needs more storage than the default root volume provides? Or when you need a persistent, high-performance disk that you can move between instances? The answer is Amazon Elastic Block Store (EBS) — and knowing how to create and attach EBS volumes to EC2 instances is a core skill for any AWS developer. Without it, you’re stuck with the disk you launched with, unable to scale storage independently of compute. This hands-on lesson will guide you from zero to a fully mounted extra volume, ready for production workloads.

The problem this lesson solves

Imagine your EC2 instance runs out of disk space because your logs are growing faster than you expected. Or you want to use a high-throughput database but the root volume is a modest gp2. The default root volume is tied to the instance’s lifecycle — terminate the instance and you lose the disk (unless you explicitly set delete-on-termination to false). You also can’t easily resize or change performance characteristics without downtime. The pain is real: you need a way to add storage on demand, independently of the instance, and with the freedom to attach the same disk to another instance later. That’s exactly what EBS volumes solve. They are network-attached block storage that you create separately from your instance, then attach and detach as needed. This decouples storage from compute, giving you flexibility, durability, and performance control.

Core concept / mental model

Think of an EBS volume as a detachable hard drive for your cloud computer. Just like you can plug a USB drive into a laptop, format it, store files, and later plug it into another laptop, an EBS volume is a block device that you attach to an EC2 instance via the AWS network (not a physical cable). The volume appears as a device like /dev/xvdf or /dev/sdf inside your Linux instance. You format it with a filesystem (e.g., ext4), mount it to a directory (e.g., /data), and use it like any local disk.

Key characteristics:

• Independent lifecycle: You create and manage volumes separately from instances.
• Persistence: Data persists until you delete the volume — it’s not deleted automatically when you terminate an instance (unless you check the "Delete on termination" box during launch, which is for root volumes typically).
• Flexibility: Attach to any instance in the same Availability Zone (AZ). Volumes are AZ-scoped, not region-scoped.
• Performance choices: Different volume types (gp2/gp3, io1/io2, st1, sc1) cater to various workloads, balancing IOPS, throughput, and cost.

Pro tip: An EBS volume can only be attached to one instance at a time. If you need shared storage for multiple instances, consider EFS (file storage) instead.

How it works step by step

The process of attaching an EBS volume to an EC2 instance follows a predictable flow. Here’s the big picture:

1. Create a volume in the same AZ as your target instance. You specify size (GB), volume type, and optionally IOPS.
2. Attach the volume to your instance. AWS assigns a device name like /dev/sdf (or /dev/xvdf on some AMIs).
3. Connect to your instance via SSH. The new block device appears as a raw disk — you must format it (if it’s new) and mount it to a directory.
4. Make it persistent across reboots by adding an entry to /etc/fstab so the mount happens automatically.

Under the hood, AWS uses the network to expose the volume as a block-level device. Because it’s network-attached, performance can vary based on network bandwidth, which is why you choose volume types with different performance baselines.

Each step has a clear cause → effect:

• Creating a volume that is not attached has no effect on any instance — it’s just a blob of allocated storage.
• Attaching the volume makes it available as a device, but the OS doesn’t recognize it as a usable filesystem until you format it.
• Formatting without mounting gives you a raw filesystem that’s not accessible — you must mount it.
• Mounting without an fstab entry means the mount disappears after reboot — causing potential data access issues.

Hands-on walkthrough

Let’s get practical. You’ll need an EC2 instance running in a specific AZ, say us-east-1a. We’ll create a 10 GB gp3 volume, attach it, format it, mount it, and configure fstab. You can do this via the AWS Management Console or the AWS CLI — we’ll show both.

Step 1: Create the EBS volume

Console: Navigate to EC2 > Elastic Block Store > Volumes > Create Volume. Fill in:

• Volume type: General Purpose SSD (gp3)
• Size: 10 GiB
• Availability Zone: same as your instance (e.g., us-east-1a)

CLI equivalent:

aws ec2 create-volume \
    --volume-type gp3 \
    --size 10 \
    --availability-zone us-east-1a \
    --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=my-data-volume}]'

Output (abbreviated):

{
    "VolumeId": "vol-0abcdef1234567890",
    "State": "creating",
    "Size": 10,
    "AvailabilityZone": "us-east-1a"
}

Wait until State becomes available (usually under a minute).

Step 2: Attach the volume to your instance

Get your instance ID (i-...) and its AZ. Important: the volume and instance must be in the same AZ. Attach with:

aws ec2 attach-volume \
    --volume-id vol-0abcdef1234567890 \
    --instance-id i-0yourinstanceid \
    --device /dev/sdf

Console alternative: Select volume > Actions > Attach Volume, choose the instance, and device name.

Check attachment state:

aws ec2 describe-volumes --volume-ids vol-0abcdef1234567890 --query 'Volumes[0].Attachments'

You should see "State": "attached" and "AttachTime" set.

Step 3: Connect to your instance and prepare the filesystem

SSH into your instance:

ssh -i /path/to/key.pem ec2-user@your-instance-public-dns

Now, verify the new device appears (it might be xvdf, xvdg, etc., depending on your AMI and the device name you specified). Use lsblk:

lsblk

Output example:

NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:16   0  10G  0 disk

Notice xvdf is 10G but not mounted or formatted. Now format it as ext4 (do not format if the volume already has data!):

sudo mkfs -t ext4 /dev/xvdf

Output: lots of Writing inode tables and Creating journal messages — that’s fine.

Step 4: Mount the volume

Create a mount point and mount:

sudo mkdir /data
sudo mount /dev/xvdf /data

Check the mount with df -h:

df -h | grep data

Output: /dev/xvdf 9.8G 24K 9.8G 1% /data

Step 5: Persist the mount across reboots

Get the UUID of the volume (more reliable than device name, which can change):

sudo blkid /dev/xvdf

Output example:

/dev/xvdf: UUID="a1b2c3d4-..." TYPE="ext4"

Add an entry to /etc/fstab:

echo 'UUID=a1b2c3d4-...  /data  ext4  defaults,nofail  0  2' | sudo tee -a /etc/fstab

The nofail option ensures that if the volume isn’t attached (e.g., you removed it), the instance still boots without errors.

Test the fstab entry by remounting all:

sudo umount /data
sudo mount -a

If no error, your setup is persistent.

Compare options / when to choose what

You have several volume types, each optimized for different workloads:

When to choose what?

• Use gp3 as your default for most cases — it’s cost-effective and flexible.
• Use io2 for production databases where latency and IOPS consistency matter.
• Use st1 for large, sequential workloads like ETL.
• Use sc1 only for archival data that you almost never read.

Also, consider snapshots as an alternative for backup and migration — they are point-in-time copies of your volume stored in S3, great for disaster recovery.

Troubleshooting & edge cases

Here are the most common pitfalls and how to handle them:

• Volume attaches but isn’t visible inside the instance. The device name might be remapped by the OS. Check lsblk to see the actual device — it may be /dev/xvdf instead of /dev/sdf. Use lsblk or sudo fdisk -l to find it.
• You see a raw disk but can’t mount — “wrong fs type, bad option, bad superblock.” This means the volume hasn’t been formatted yet. Run sudo mkfs -t ext4 /dev/xvdf (only if you’re sure it’s empty). Double-check you’re not formatting a volume that contains data!
• Instance doesn’t start after adding fstab entry. This often happens if the device isn’t available at boot. Always use the nofail option in fstab, and test with mount -a before rebooting.
• Volume is in a different AZ than the instance. AWS won’t let you attach it — error: “The volume is not in the same AZ as the instance.” You must create the volume in the correct AZ, or take a snapshot and create a new volume in the target AZ.
• You want to attach the same volume to another instance. You must detach it first from the current instance (aws ec2 detach-volume --volume-id vol-...). Then attach to the new instance. Remember to update fstab if the device name changes.

What you learned & what's next

You can now create and attach EBS volumes to EC2 from the console or CLI, format and mount them, and ensure persistence across reboots. You understand the different volume types and how to pick the right one for your workload, and you can troubleshoot common attachment and mounting issues.

This skill unlocks the ability to scale storage independently, move data between instances, and design for durability. Your next step in this AWS Tutorial path is to explore EBS snapshots for backup and disaster recovery, or dive into Elastic File System (EFS) when you need shared storage across multiple instances. Both build on the fundamentals you’ve just mastered.

Now go ahead — create a second volume and try mounting it in a different location. Make it a habit to use volumes for anything that needs to outlive your EC2 instances!