Chapter 13: Amazon EBS (Elastic Block Store)
13.6 Adding a new EBS volume
Chala, aata ek navin disk add karuya (let's add a new disk). Think of it like plugging a new external hard disk into your laptop — but technically, AWS attaches a network block device that appears as an NVMe disk, and you must format and mount it yourself.
Goal: add a 10 GiB gp3 disk to an instance and mount it permanently at /data.
Step 1 — Find the instance's Availability Zone
EC2 → Instances → select instance → Networking tab → Availability zone (e.g. ap-south-1a). Or on the instance:
TOKEN=$(curl -s -X PUT http://169.254.169.254/latest/api/token -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone; echo
Step 2 — Create the volume (same AZ!)
EC2 → Elastic Block Store → Volumes → Create volume → Volume type gp3 → Size 10 GiB → Availability Zone same as the instance → (optional) tick Encrypt this volume → add tag Name=data-vol → Create volume. Wait until state is Available.
Step 3 — Attach it
Select the volume → Actions → Attach volume → choose your instance → Device name /dev/sdf → Attach volume. State becomes In-use.
Step 4 — Identify the new disk
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 20G 0 disk
└─nvme0n1p1 259:1 0 20G 0 part /
nvme1n1 259:4 0 10G 0 disk ← new, no filesystem, not mounted
Make sure it is empty (a brand-new volume shows data or nothing, not a filesystem):
sudo file -s /dev/nvme1n1 # "/dev/nvme1n1: data" means empty
lsblk -f /dev/nvme1n1
mkfs erases everything
Formatting a disk that already contains data (for example a volume restored from a snapshot) destroys that data. Only run mkfs on a new empty volume, and double-check the device name.
Step 5 — Create a filesystem
# XFS (recommended on Amazon Linux / CentOS; install xfsprogs on Ubuntu if you prefer XFS)
sudo mkfs -t xfs /dev/nvme1n1
# OR ext4 (common on Ubuntu)
# sudo mkfs -t ext4 /dev/nvme1n1
Step 6 — Create a mount point and mount
sudo mkdir -p /data
sudo mount /dev/nvme1n1 /data
df -hT /data
Step 7 — Make the mount permanent with /etc/fstab (UUID + nofail)
A plain mount is forgotten after reboot. Add an entry to /etc/fstab using the UUID:
sudo blkid /dev/nvme1n1
# /dev/nvme1n1: UUID="8a5c6f1e-2b3d-4c5e-9f10-1a2b3c4d5e6f" BLOCK_SIZE="512" TYPE="xfs"
sudo cp /etc/fstab /etc/fstab.bak # always back up first
UUID=$(sudo blkid -s UUID -o value /dev/nvme1n1)
FSTYPE=$(sudo blkid -s TYPE -o value /dev/nvme1n1)
echo "UUID=$UUID /data $FSTYPE defaults,nofail 0 2" | sudo tee -a /etc/fstab
cat /etc/fstab
Test the fstab entry before rebooting:
sudo umount /data
sudo mount -a # mounts everything in fstab; any error here means fix fstab NOW
sudo systemctl daemon-reload
df -hT /data
| fstab field | Value | Meaning |
|---|---|---|
| 1 device | UUID=... |
Stable identifier — survives NVMe renaming |
| 2 mount point | /data |
Folder where the disk appears |
| 3 type | xfs / ext4 |
Filesystem type |
| 4 options | defaults,nofail |
nofail = boot continues even if the volume is missing/detached |
| 5 dump | 0 |
Legacy backup flag |
| 6 fsck order | 2 |
Check after root (root = 1; 0 = never check) |
Why nofail matters
Without nofail, if the volume is detached or fails, the instance can hang in emergency mode at boot and you cannot SSH in. A wrong UUID has the same effect — that is why we test with sudo mount -a before rebooting.
Step 8 — Use it
sudo chown $USER:$USER /data
echo "hello EBS" > /data/test.txt
sudo reboot
# after reconnecting:
df -hT /data && cat /data/test.txt
Common uses: move MySQL data (/var/lib/mysql), website files, logs or backups onto a separate volume so they survive root-volume problems and can be snapshotted separately.
Ravindra Bagale's Tip
Treat /etc/fstab with respect: back it up, use the UUID, add nofail, and always run sudo mount -a before rebooting. A single typo in fstab can make an instance unbootable — and then you need a rescue instance to fix it. Lakshat theva!