How to Add, Format and Mount an EBS Volume on EC2 (fstab)

By Ravindra Bagale, trainer · LinkedIn · Last updated: 18 October 2026

1. What an EC2 server is made of

Why: When something runs out (CPU, memory, disk or IP), knowing which part of the server holds it tells you what to change.

What: when you launch an instance, AWS puts together three separate parts:

1. The instance itself: CPU and RAM. This is the computer that runs your programs.
2. An EBS volume: the disk. The first one is the root volume; the operating system boots from it. Amazon Linux 2023 gets an 8 GiB root volume by default.
3. An ENI (Elastic Network Interface): the network card. It holds the private IP address, and the public IP if there is one.

Because the disk is separate from the CPU and RAM, it can be resized, detached and attached to another server. What happens to each part on stop and terminate is in The ENI: where your IP addresses live and The EBS bill: real numbers.

2. The disk is full: grow the volume or add one?

Why: A full disk stops uploads, logs and databases. Choosing between growing and adding decides how much work and risk the fix needs.

The situation: a website stores uploaded images, or MySQL keeps growing, and after some months the 8 GiB root volume is full. There are two ways out.

Option A: grow the volume. Select the volume, Actions > Modify volume, and enter a bigger size, for example 8 to 16 GiB.

1. A size can only go up, never down.

2. The server keeps running. Then grow the partition and the file system inside Linux:

   sudo growpart /dev/nvme0n1 1
   sudo xfs_growfs -d /
   df -h /
   

3. After a change, the same volume can be modified again only after six hours.

Option B: add a data volume. Keep the operating system on the root volume, and put the data on a second volume mounted on a folder such as /data. This is what the rest of the chapter does. It has real advantages:

1. The data is kept apart from the operating system. If the OS breaks, the data volume can simply be attached to a new server.
2. Each volume can have its own type and size: a cheap gp3 root and a faster volume for a database.
3. You can back up only the data, with a snapshot of that one volume.

3. EBS volume types and IOPS

Why: The type sets speed and price. The wrong type either makes a database slow or costs you money for speed you never use.

IOPS (input/output operations per second) is how many reads and writes a disk can do each second. Programs and their data are loaded from the disk into RAM, so a slow disk makes a slow server, especially for databases.

The types you see in Create volume > Volume type:

1. General Purpose SSD gp3: the default and the cheapest SSD. Every gp3 volume gets 3,000 IOPS and 125 MiB/s whatever its size, and you can pay for more: up to 80,000 IOPS and 2,000 MiB/s. Size 1 GiB to 64 TiB.
2. General Purpose SSD gp2: the older type. Its IOPS grow with its size: 3 IOPS per GiB, at least 100 and at most 16,000; volumes smaller than 1 TiB can burst to 3,000 IOPS for a while. Use gp3 for new volumes.
3. Provisioned IOPS SSD io2 (Block Express): for big, busy databases. You choose the IOPS yourself: up to 256,000 IOPS (at most 1,000 per GiB) and 4,000 MiB/s, size up to 64 TiB.
4. Provisioned IOPS SSD io1: the older provisioned type, up to 64,000 IOPS.
5. Throughput Optimized HDD st1 and Cold HDD sc1: hard disks for large files read in long runs, such as logs or archives, at a low price per GiB. They start at 125 GiB and can't be a root volume.
6. Magnetic (standard): a previous-generation type; don't use it for new volumes.

Sizes: a root volume can't be smaller than its AMI needs: 8 GiB for Amazon Linux, 30 GiB for Windows Server. A gp3 or gp2 data volume can be as small as 1 GiB, which is plenty for practice.

4. The plan: four steps

1. Create a volume in the same Availability Zone as the server.
2. Attach it to the server.
3. Make a file system on it (only because it is new).
4. Mount it on a folder, /data. Everything written to /data then lands on the new volume.

5. Look at the disks first: lsblk, df -h and du

Why: Looking first shows what is already there, so you never format the wrong disk.

How: connect to the server and run:

lsblk
df -h

lsblk lists every disk and partition attached to the server, mounted or not:

NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0   8G  0 disk
├─nvme0n1p1   259:1    0   8G  0 part /
├─nvme0n1p127 259:2    0   1M  0 part
└─nvme0n1p128 259:3    0  10M  0 part /boot/efi

1. nvme0n1 is the root volume, the whole disk. nvme0n1p1 is its main partition, mounted on /. The two small partitions are used for booting.
2. A partition is a part of a disk, so it can't be bigger than the disk.

df -h lists only the mounted file systems, with their size, used and free space (-h means human-readable sizes such as 8.0G):

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           457M     0  457M   0% /dev/shm
/dev/nvme0n1p1  8.0G  1.7G  6.4G  21% /
/dev/nvme0n1p128 10M  1.3M  8.7M  13% /boot/efi

1. tmpfs and devtmpfs live in RAM, not on a disk.
2. To see how much space a folder uses, use du: sudo du -sh /var/log. Without sudo you get Permission denied for folders that belong to root.

6. Create the volume in the same Availability Zone

Why: A volume can attach only to a server in its own AZ. A volume made in another AZ is useless to this server.

How:

1. Find the server's AZ: select the instance, Networking tab, Availability Zone, for example us-east-1d.
2. Elastic Block Store > Volumes > Create volume.
3. Volume type: General Purpose SSD (gp3). Size: 1 GiB. Leave IOPS at 3000 and throughput at 125.
4. Availability Zone: the server's AZ, us-east-1d. Check this twice; it is the most common mistake.
5. Add a tag Name = data-vol, so you can find it later, and Create volume. Its state goes from Creating to Available.

7. Attach the volume

Why: Until it is attached, the volume is just storage in AWS. Attaching is what makes Linux see it as a new disk.

How:

1. Select data-vol, Actions > Attach volume.
2. Instance: choose your server. Only instances in the volume's AZ are listed.
3. Device name: /dev/sdf. The console recommends /dev/xvda for a root volume and /dev/sdf to /dev/sdp for data volumes.
4. Attach volume. The state changes to In-use, and the instance's Storage tab shows two block devices.

The name inside Linux is different. On current instance types (Nitro, such as t3) every EBS volume is an NVMe device, so /dev/sdf shows up as /dev/nvme1n1; on older types it can be /dev/xvdf. Always check with lsblk:

NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0   8G  0 disk
├─nvme0n1p1   259:1    0   8G  0 part /
├─nvme0n1p127 259:2    0   1M  0 part
└─nvme0n1p128 259:3    0  10M  0 part /boot/efi
nvme1n1       259:4    0   1G  0 disk

nvme1n1 is attached, but it has no partition and no mount point, and df -h doesn't show it yet.

8. Is there a file system? sudo file -s

Why: mkfs erases everything. Checking first that the volume is empty (data) is what keeps you from wiping a disk that already holds files.

How:

sudo file -s /dev/nvme0n1p1
sudo file -s /dev/nvme1n1

1. The root partition answers SGI XFS filesystem data (blksz 4096, inosz 512, v2 dirs): it has an XFS file system.
2. The new volume answers just /dev/nvme1n1: data. That means: no file system, only raw blocks.
3. sudo lsblk -f shows the same thing as a table: the FSTYPE column is empty for the new volume.

What a file system is: a disk is only a long row of blocks of 0s and 1s. A file system keeps a table on the disk: each file's name, its folder, and which blocks hold its content. Without that table, Linux can't store a file by name, so a volume must have a file system before it can be mounted.

Why deleted files can come back:

1. A normal delete (rm, or emptying the Recycle Bin) removes the file's entry from the table and marks its blocks as free. The content stays in those blocks until new data overwrites them.
2. That is why recovery tools can often find deleted content, though usually without the file names. On a test disk, a line written to a file, then deleted with rm, could still be found on the raw device afterwards.
3. To really erase a disk, overwrite it, for example with shred or a full dd from /dev/zero, or use the drive's secure-erase command.
4. AWS wipes the storage of a deleted EBS volume before anyone else gets it. That is why a brand-new volume is all zeros and file -s says data.

9. Make a file system: mkfs -t xfs

Why: A raw volume has no table of file names, so Linux cannot store files on it. mkfs creates that table.

What: making a file system, also called formatting, writes that empty table onto the volume. It is not installing a driver; it only prepares the disk to store files.

How:

sudo mkfs -t xfs /dev/nvme1n1

1. mkfs prints a summary that starts with meta-data=/dev/nvme1n1 and lists the block size and sections. sudo file -s /dev/nvme1n1 now says SGI XFS filesystem data.
2. XFS is the default file system on Amazon Linux 2023. Ubuntu usually uses ext4 (sudo mkfs -t ext4 /dev/nvme1n1). Windows uses NTFS.
3. NFS is not a disk format: it is a protocol for sharing folders over the network. On AWS that is Amazon EFS.

Only on a new, empty volume. mkfs writes a new, empty table: every file on the volume is lost. If the volume already has a file system, mkfs.xfs refuses with appears to contain an existing filesystem (xfs) and asks for -f. That message means the volume has data: stop, and mount it instead.

10. Mount the volume on /data

Why: Linux reaches a disk only through a folder. Mounting connects the volume to /data, so files written there land on it.

What: mounting connects a folder to a file system. After the mount, whatever you write into the folder is stored on that volume.

How:

sudo mkdir /data
sudo mount /dev/nvme1n1 /data
df -h

1. df -h now has a new line: /dev/nvme1n1 960M 40M 921M 5% /data. The 1 GiB volume shows a little less, because the file system itself takes some space.

2. Create a few files and folders:

   cd /data
   sudo touch a b c
   sudo mkdir x y z
   ls
   

3. /data belongs to root, so plain touch gives Permission denied. To let ec2-user write there without sudo, run sudo chown ec2-user:ec2-user /data once.

11. Prove that the files live on the volume

Why: Seeing the files disappear on unmount and come back on mount proves they are on the volume, not on the root disk.

The test: unmount the volume and look into the folder.

1. Leave the folder first: cd ~. You can't unmount a folder you are standing in; umount answers target is busy.

2. Unmount and look:

   sudo umount /data
   ls /data
   

3. /data is empty. The files were never in the folder; they are on the volume.

4. Mount it again, and they are back:

   sudo mount /dev/nvme1n1 /data
   ls /data
   

12. Make the mount permanent: /etc/fstab

Why: mount is temporary. After a reboot, or a stop and start, /data is an empty folder again until someone mounts the volume.

What: /etc/fstab (file system table) is a configuration file that Linux reads at boot. Each line names a file system and the folder it is mounted on.

How:

1. Get the volume's UUID, a unique ID stored in the file system:

   sudo blkid /dev/nvme1n1
   

2. It prints /dev/nvme1n1: UUID="af9001ed-20fb-42b7-b0b7-f2d8de17df67" BLOCK_SIZE="512" TYPE="xfs". Copy the UUID without the quotes.

3. Back up the file, then open it:

   sudo cp /etc/fstab /etc/fstab.bak
   sudo nano /etc/fstab
   

4. Leave the existing lines alone, and add one line at the end with your own UUID:

   UUID=af9001ed-20fb-42b7-b0b7-f2d8de17df67  /data  xfs  defaults,nofail  0  2
   

5. Test it before any reboot:

   sudo umount /data
   sudo mount -a
   df -h
   

6. mount -a mounts everything in /etc/fstab that isn't mounted yet. If /data is back in df -h with no error, the line is right. If mount prints a hint to run systemctl daemon-reload, run sudo systemctl daemon-reload.

7. Then sudo reboot, connect again, and check df -h: /data is mounted without you doing anything.

Each field of the line:

1. UUID=...: which file system. Device names such as /dev/nvme1n1 can change between boots or instance types; the UUID never does.
2. /data: the mount point, an existing folder.
3. xfs: the file system type.
4. defaults,nofail: normal options, plus nofail: if the volume is missing, for example detached, the server still boots. Without nofail the boot can stop and wait, and you can't connect with SSH.
5. 0: the dump field, for the old dump backup tool; always 0.
6. 2: the order for the file system check at boot: 1 for the root, 2 for other disks, 0 for never.

A typing mistake shows up in the test: a misspelt option such as nofial makes mount -a fail with Unknown parameter 'nofial'. Fix it before you reboot.

That is a common interview task, and it is exactly sections 6 to 12.

13. Move a data volume to another server

Why: the data lives on the volume, not in the server. If a server breaks or is replaced, the data volume moves to a new server with all its files.

How:

1. On the old server: cd ~, then sudo umount /data, and delete or comment out (#) the /data line in /etc/fstab.
2. In the console: select data-vol, Actions > Detach volume. Its state becomes Available.
3. The new server must be in the same AZ. When you launch it, use Network settings > Edit > Subnet and pick the subnet in that AZ.
4. Actions > Attach volume to the new server, device /dev/sdf.
5. On the new server: lsblk shows nvme1n1, and sudo file -s /dev/nvme1n1 says SGI XFS filesystem data: the file system is already there. Don't run mkfs.

6. Mount it and look:

   sudo mkdir /data
   sudo mount /dev/nvme1n1 /data
   ls /data
   

7. a b c x y z are all there. Add the fstab line on this server too (section 12), with the same UUID.

Unmount first, then detach. Detaching a mounted volume can lose data that was still being written. Force detach exists for a volume that is stuck in Detaching, but it can corrupt the file system, so use it only as the last resort.

The root volume can be moved too, by swapping it on a stopped server: see Recover data by swapping the root volume.

14. Clean up

Why: Volumes and snapshots keep costing money until you delete them, even with no server attached.

1. sudo umount /data and remove the /data line from /etc/fstab.
2. Volumes: select data-vol, Actions > Detach volume, wait for Available, then Actions > Delete volume. An Available volume is still billed.
3. Instances: terminate the practice servers.

15. When something goes wrong

Why: Each error names one step: AZ, attach, file system, mount or fstab. Matching the error to the step saves you from starting over.

1. The server isn't in the Attach volume list: the volume is in another AZ. Create the volume in the server's AZ.
2. mount: /data: wrong fs type, bad option, bad superblock: the volume has no file system yet (file -s says data), or you named the wrong device. Check with lsblk and sudo file -s; run mkfs only if the volume is new.
3. mount point /data does not exist: create the folder first with sudo mkdir /data. mkdir makes a folder; mkfs makes a file system. Don't mix them up.
4. /dev/sdf: No such file or directory: inside Linux the volume is /dev/nvme1n1 (or /dev/xvdf). Use the name from lsblk.
5. umount: /data: target is busy: you, or a program, are inside /data. Run cd ~ and try again.
6. mkfs.xfs: ... appears to contain an existing filesystem: the volume has data. Don't add -f; mount it.
7. touch: cannot touch ... Permission denied in /data: use sudo, or sudo chown ec2-user:ec2-user /data.
8. /data is empty after a reboot: there is no fstab line, or it has a mistake. Run sudo mount -a and read the error.
9. The server doesn't come back after an fstab change: a wrong line without nofail. Stop the server, attach its root volume to another server as a second disk, fix the line, and attach it back; see the root volume chapter linked above.

16. The whole class on one page

1. An EC2 server is the instance (CPU and RAM), an EBS root volume (the disk) and an ENI (the network card with the IPs).
2. A full disk: grow the volume (Modify volume, then growpart and xfs_growfs), or add a data volume and mount it on /data.
3. IOPS = reads and writes per second. gp3 includes 3,000 IOPS at any size (up to 80,000); gp2 gives 3 IOPS per GiB; io2 up to 256,000; st1 and sc1 are hard disks that can't boot.
4. Four steps: create in the same AZ, attach as /dev/sdf (Linux shows nvme1n1), mkfs -t xfs (new volumes only), mount.
5. lsblk shows attached disks; df -h shows mounted file systems; sudo file -s says data when there is no file system.
6. A delete removes the table entry, not the content; AWS wipes deleted volumes, so a new volume is empty.
7. sudo mkdir /data, sudo mount /dev/nvme1n1 /data; after sudo umount /data the folder is empty: the files live on the volume.
8. /etc/fstab: UUID=... /data xfs defaults,nofail 0 2, from sudo blkid; test with sudo umount /data and sudo mount -a before a reboot.
9. Move a data volume: umount, detach, attach in the same AZ, mount; never mkfs. Force detach only as the last resort.
10. Clean up: unmount, detach, delete the volume, terminate the servers.

17. Hands-on lab: add a 1 GiB data volume and mount it at boot

Why this lab. This lab adds a second disk to a running server, stores files on it, and makes it mount by itself after a reboot, checking each step before the next.

1. Look at the disks
   • Command: lsblk
   • You should see: One disk, nvme0n1, with its partitions.
   • Check: df -h / shows the 8 GiB root file system.
   • Why: You need the "before" picture to spot the new disk later.
2. Create the volume
   • Do: Volumes → Create volume: gp3, 1 GiB, and the same AZ as the server (see the server's Networking tab).
   • Check: The new volume is Available.
   • Why: 1 GiB gp3 is enough to practise and costs very little. Another AZ would make the attach impossible.
3. Attach it
   • Do: Actions → Attach volume → your server → device /dev/sdf.
   • Check: lsblk now also shows nvme1n1, 1G, with no partitions.
   • Why: Linux names the disk nvme1n1, not sdf. Use the name lsblk shows.
4. Check that it is empty
   • Command: sudo file -s /dev/nvme1n1
   • You should see: /dev/nvme1n1: data
   • Check: If it says XFS filesystem data instead, stop: the disk already holds a file system.
   • Why: data means no file system, so formatting it loses nothing.
5. Make the file system
   • Command: sudo mkfs -t xfs /dev/nvme1n1
   • You should see: A summary with meta-data=/dev/nvme1n1.
   • Check: sudo file -s /dev/nvme1n1 now says SGI XFS filesystem data.
   • Why: XFS is the default on Amazon Linux. Run mkfs only on a new volume: it erases everything.
6. Mount it on /data
   • Command: sudo mkdir /data && sudo mount /dev/nvme1n1 /data
   • You should see: Nothing.
   • Check: df -h /data shows /dev/nvme1n1, about 1.0G.
   • Why: Linux reaches a disk only through a folder, so the volume needs one to be mounted on.
7. Prove the files live on the volume
   • Command: cd /data && sudo touch a b c && cd ~ && sudo umount /data
   • You should see: Nothing.
   • Check: ls /data is now empty; sudo mount /dev/nvme1n1 /data and ls /data shows a b c again.
   • Why: Leave /data before unmounting, or you get target is busy.
8. Get the UUID
   • Command: sudo blkid /dev/nvme1n1
   • You should see: /dev/nvme1n1: UUID="..." BLOCK_SIZE="512" TYPE="xfs"
   • Check: Copy the UUID without the quotes.
   • Why: The UUID belongs to the file system and never changes, while the device name can change after a reboot.
9. Add the fstab line
   • Command: sudo cp /etc/fstab /etc/fstab.bak && sudo nano /etc/fstab
   • You should see: The existing root line. Add at the end: UUID=YOUR_UUID /data xfs defaults,nofail 0 2.
   • Check: tail -1 /etc/fstab shows your new line.
   • Why: The backup lets you undo a bad edit. nofail lets the server boot even if the volume is missing.
10. Test before rebooting
    • Command: sudo umount /data && sudo mount -a
    • You should see: No output. If it suggests systemctl daemon-reload, run sudo systemctl daemon-reload.
    • Check: df -h shows /data again. Then sudo reboot, reconnect, and df -h still shows it.
    • Why: mount -a reads fstab exactly as boot does, so a typo shows up now, while you can still fix it.
11. Clean up
    • Do: sudo umount /data, delete the line from /etc/fstab, then detach and delete the volume in Volumes.
    • Check: Volumes shows no available volume left.
    • Why: Remove the fstab line before detaching, so the next boot doesn't look for a missing disk. A detached volume keeps costing money.

18. Try at home

Recap

Quick revision cards

Revise this lesson in two minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens its lesson.

More cards: Ravi Sir's Cards.