Introduction

Attaching an existing Amazon EBS volume to an EC2 instance is usually straightforward, but the filesystem step is where people often get stuck. The most common mistakes are attaching the volume in the wrong Availability Zone, mounting the wrong device name, or formatting a volume that already contains data.

Start with the AWS-Side Requirements

An EBS volume can only be attached to an instance in the same Availability Zone. If the instance is in us-east-1a and the volume is in us-east-1b, the attach operation will fail before Linux ever sees the disk.

Once the volume is attached in the console or through the CLI, the requested name such as /dev/sdf is only a logical attachment hint. On modern Nitro-based instances, the device often appears inside Linux as an NVMe device such as /dev/nvme1n1 instead.

Identify the Actual Device in the Instance

After SSH login, inspect the block devices instead of guessing.

lsblk
sudo fdisk -l
sudo file -s /dev/nvme1n1

lsblk shows the device tree, partitions, and mount points. file -s is useful because it can tell you whether the device already contains a filesystem such as XFS or ext4. That matters a lot for existing EBS volumes.

If the volume already has data, do not run mkfs on it.

Mount an Existing Filesystem Safely

If the volume already contains a valid filesystem, create a mount point and mount it directly.

sudo mkdir -p /data
sudo mount /dev/nvme1n1 /data
ls -la /data

If the volume has a partition table instead of a filesystem on the whole device, mount the partition path such as /dev/nvme1n1p1.

sudo mount /dev/nvme1n1p1 /data

This is one of the easiest places to make a destructive mistake. Mount the detected filesystem. Do not reinitialize the disk unless you are certain the volume is supposed to be empty.

Format Only If the Volume Is Truly Blank

If file -s shows no filesystem and the volume is intentionally new or disposable, then formatting is appropriate.

sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir -p /data
sudo mount /dev/nvme1n1 /data

Formatting an existing volume erases the old filesystem metadata, so it should never be the first troubleshooting step.

Persist the Mount Across Reboots

A manual mount disappears after reboot. To make it persistent, use the volume UUID in /etc/fstab rather than a guessed device name.

sudo blkid /dev/nvme1n1

Then add an entry like this:

UUID=1234-ABCD  /data  xfs  defaults,nofail  0  2

Using UUID is safer because EC2 device names can shift across reboots or reattachments.

Common Reasons the Mount Fails

A few failure patterns show up repeatedly:

• the device path in Linux is not the same as the console attachment name,
• the volume contains partitions and you are mounting the parent disk,
• the filesystem type is wrong for the mount command or /etc/fstab,
• the volume is encrypted or damaged and needs separate handling,
• the instance OS lacks filesystem support for that disk format.

Most filesystem issues become obvious once you check lsblk, blkid, and dmesg instead of trying random mount commands.

Common Pitfalls

• Attaching the volume to an instance in a different Availability Zone.
• Formatting a volume that already contains important data.
• Mounting /dev/sdf from documentation when the actual Linux device is NVMe.
• Mounting the disk device instead of the real partition that contains the filesystem.
• Using raw device names in /etc/fstab instead of UUIDs.

Summary

• Confirm the volume and instance are in the same Availability Zone.
• Identify the real Linux device name with lsblk rather than trusting the attach label.
• Mount existing filesystems directly and format only blank volumes.
• Check for partitions before choosing the mount target.
• Use UUID-based /etc/fstab entries for stable reboot behavior.