Right, let’s get our hands dirty with the actual mechanics of EBS volumes. This is where the rubber meets the road, or more accurately, where your data meets the virtualized spinning rust (or gloriously fast silicon, if you’ve sprung for the good stuff). Attaching, detaching, and resizing these things is mostly straightforward, but the cloud gods, in their infinite wisdom, have sprinkled in a few quirks just to keep you on your toes.

The Art of the Attachment

You’ve created a shiny new volume. Now you need to make it useful by attaching it to an instance. The attach-volume command is your friend here, but it demands three key pieces of information: the volume ID, the instance ID, and the device name.

aws ec2 attach-volume \
  --volume-id vol-1234567890abcdef0 \
  --instance-id i-09987654321fedcba \
  --device /dev/sdf

Now, about that device name (/dev/sdf). This is where AWS lives in a state of delightful fiction. You’re suggesting a name to the instance’s OS. The OS, being a cantankerous beast, might just rename it on you. Modern Linux kernels using the nvme driver will rename an attached /dev/sdf to something like /dev/nvme1n1. You must check what the OS decided to call it using lsblk after attachment. Don’t assume. This is a classic “it worked in the AWS console, why isn’t it mounting?!” pitfall.

# After attaching, always always always run this:
lsblk
# Look for the disk size to find your new volume. It won't have a mountpoint yet.
NAME        MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0  10G  0 disk
├─nvme0n1p1 259:1    0  10G  0 part /
nvme1n1     259:2    0  100G  0 disk  # <-- Ah-ha! There's my new 100GB volume.

The Perilous Detach

Detaching is the easy part, right? aws ec2 detach-volume --volume-id vol-1234567890abcdef0. Not so fast. The crucial, absolutely non-negotiable step here is to unmount the filesystem inside the OS first. If you don’t, you’re yanking the virtual cable out. You risk data corruption, and the OS will likely throw a fit, placing the volume in an in-use -> detaching state for a frustratingly long timeout period before AWS forces it. Do it right:

# Inside the instance, for a volume mounted at /data
sudo umount /data

# Then, and only then, from your client
aws ec2 detach-volume --volume-id vol-1234567890abcdef0

Also, a pro tip: if you’re detaching a volume to attach it to another instance for some forensic work, make damn sure you set the --no-force flag. If you don’t, and the original instance is still running, you’re forcing the detach, which is the equivalent of pulling the fire alarm instead of using the stairs—it works, but it’s messy and everyone gets upset.

Resizing: The Grow-Now-Trim-Later Paradox

Need more space? Resizing an EBS volume is a two-act play, and most people forget the second act until it’s too late. First, you modify the volume itself in AWS. This is an API call and can usually be done live, without stopping your instance.

aws ec2 modify-volume --volume-id vol-1234567890abcdef0 --size 200

The volume’s physical storage is now 200 GB. But your OS and file system are still blissfully unaware of this change. They’re still living in a 100 GB world. This is Act Two: you need to extend the partition and then the filesystem to use that new space.

For a common scenario: an MBR partition on /dev/nvme1n1 mounted as /data.

# Grow the partition (assuming it's the first partition, p1)
sudo growpart /dev/nvme1n1 1

# Then grow the filesystem (for xfs)
sudo xfs_growfs /data

# Or for ext4
sudo resize2fs /dev/nvme1n1p1

Here’s the absurd part everyone gets tripped up by: you can increase the size of a volume live, but you absolutely cannot decrease it. The AWS API will literally stop you. The logic is sound—decreasing size would almost certainly require moving data and would be a data-loss nightmare. But it’s a stark reminder that in the cloud, the only direction to go is up. Plan your storage accordingly.

The final gotcha? If your volume is the root volume of an instance, you often have to restart the instance for the OS to see the new size. It’s a weird, legacy quirk. So for root volumes, do the modification, then do a quick reboot. For everything else, the growpart and resize2fs/xfs_growfs dance should be all you need.