Introduction

Attaching an EBS volume to an EC2 instance is only half the job. If you want the volume available after every reboot, the instance also needs a stable mount configuration. On Linux, that usually means identifying the filesystem by UUID and adding a carefully chosen entry to /etc/fstab.

Identify the Correct Device and Filesystem

After attaching the volume in AWS, connect to the instance and inspect the block devices:

lsblk
sudo blkid

lsblk shows which device appeared, and blkid shows the filesystem UUID. The UUID is more stable than a raw device path such as /dev/xvdf, which may not always map the same way across boots or Nitro-based naming conventions.

If the volume is new and has no filesystem yet, create one first:

sudo mkfs.ext4 /dev/nvme1n1

Only do this on a brand-new empty volume, because formatting destroys existing data.

Create a Mount Point and Test a Manual Mount

Before editing /etc/fstab, create the target directory and make sure the mount works manually:

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

If the manual mount fails, fix that problem first. fstab should automate a known-good mount, not debug a broken one.

Add the Volume to /etc/fstab

Use the UUID from blkid rather than the raw device path:

sudo blkid /dev/nvme1n1

Example output:

/dev/nvme1n1: UUID="1234abcd-56ef-7890-abcd-1234567890ef" TYPE="ext4"

Then add an /etc/fstab entry:

UUID=1234abcd-56ef-7890-abcd-1234567890ef /data ext4 defaults,nofail 0 2

Important parts:

• 'UUID=... identifies the volume'
• '/data is the mount point'
• 'ext4 is the filesystem type'
• 'nofail prevents boot from failing hard if the volume is unavailable'

The nofail option is especially useful on cloud instances where attachment timing or operational mistakes could otherwise block boot.

Validate Before Rebooting

Never edit /etc/fstab and reboot immediately without testing:

sudo umount /data
sudo mount -a
df -h /data

mount -a tells Linux to mount everything from fstab that is not already mounted. If that succeeds, your configuration is much safer to trust on the next reboot.

This step is critical because a bad fstab entry can leave a system unbootable or stuck in recovery mode.

On systems that use systemd extensively, you can also inspect boot-time mount failures later with journalctl -b if the volume still does not come up as expected after reboot successfully.

Think About Ownership and Application Access

Mounting the volume is not the whole operational picture. The application also needs correct permissions:

sudo chown ec2-user:ec2-user /data

Use the right owner and group for your workload, whether that is ec2-user, nginx, postgres, or another service account.

If the volume stores application data, document the mount in provisioning scripts or infrastructure code so future instances are configured consistently.

Common Pitfalls

• Using a raw device path instead of a UUID in /etc/fstab.
• Forgetting to test the mount manually before automating it.
• Formatting a volume that already contains data.
• Rebooting after editing /etc/fstab without first running mount -a.
• Ignoring ownership and permissions after the mount succeeds.

Summary

• Automatic EBS mounting on EC2 is usually implemented through /etc/fstab.
• Use lsblk and blkid to identify the device and its filesystem UUID.
• Prefer UUID-based mounts over raw device names.
• Include nofail when appropriate so boot is more resilient.
• Test with mount -a before rebooting the instance.