Skip to main content
In this lesson we demonstrate working with AWS Elastic Block Store (EBS) — creating a volume, formatting and mounting it on an EC2 instance, detaching it, and reattaching it to another instance within the same Availability Zone. This walkthrough focuses on the EBS workflow, device naming, and data persistence when moving a volume between instances. Keywords: AWS EBS, Elastic Block Store, attach/detach EBS, EC2, Availability Zone, XFS, mount, snapshot, cross-region copy Instances prepared for this demo Remember: EBS volumes are created in a specific Availability Zone and can only be attached to EC2 instances in that same Availability Zone. To move a volume between AZs or regions you must use snapshots.

​
Create and attach an EBS volume to server-one

From the EC2 console (Volumes), create a new EBS volume with these settings:
  • Volume type: gp2 (or gp3, depending on your account)
  • Size: 10 GiB
  • Availability Zone: us-east-1a
  • Name: demo-volume (optional)
  • Encryption: Disabled for this demo
Attach the new volume to server-one. The console may display the device name as /dev/sdf. On the instance the kernel may rename it (for example to /dev/xvdf) or present it as an NVMe device (for example /dev/nvme0n1). Use the device name shown on the instance (for example from lsblk) when working with the device.
On Linux, device names shown in the console (e.g. /dev/sdf) may appear as /dev/xvdf (or similar) on the instance. The kernel renames the device; use the device visible on the instance (lsblk) when working with it.
After attaching, SSH into server-one and verify the block device list:
Check whether a filesystem already exists on the new block device:
The output data indicates no filesystem exists yet. Create an XFS filesystem on the volume:
Create a mount point and mount the filesystem. We’ll use /ebsdemo (lowercase) to match the console outputs shown later:
Note: mounting this way is temporary — it will not persist after a reboot. To make the mount persistent, add an entry to /etc/fstab. Retrieve the unique identifier (UUID) for the block device and use it in /etc/fstab:
Add an fstab entry using the UUID, mount point, filesystem type, and mount options. Example /etc/fstab line:
Test fstab entries (or mount everything listed in fstab) with:
Now create a file on the volume to demonstrate that data persists across attachments. Use sudo and tee to safely write as root:

​
Detach and attach the EBS volume to server-two

EBS volumes are independent resources. You can unmount and detach a volume from one EC2 instance and attach it to another instance in the same Availability Zone. On server-one, unmount the filesystem. Make sure you are not inside the mount directory when unmounting:
Then in the EC2 console select the volume and choose Detach Volume. After it becomes available, choose Attach Volume and attach it to server-two (must be in the same AZ).
A screenshot of the AWS EC2 console showing the Volumes list and details; one volume named "demo-volume" (vol-0f300ab1458ce6d48) is selected. A green banner at the top indicates the volume was successfully attached to an instance and the details pane shows it as a 10 GiB gp2 volume in-use.
On server-two, verify the block device, mount it, and read the file we created on server-one:
This confirms the EBS volume (and its data) is independent of any single EC2 instance. You can unmount it from one instance and attach it to another to continue using the same data, provided the instances share the same Availability Zone.

​
Wrap up

This completes the basic EBS attach/detach demo within the same Availability Zone. Key takeaways:
  • EBS volumes are AZ-scoped: attach only to instances in the same Availability Zone.
  • Use lsblk, blkid, and file -s to inspect devices and filesystems.
  • To preserve mounts across reboots, use /etc/fstab with UUIDs.
  • To move a volume across AZs or regions: create a snapshot of the volume, copy the snapshot to the target region (if needed), and create a new volume from that snapshot in the target Availability Zone or region.
Links and references
Tip: For production environments, consider enabling encryption, regular snapshots for backup, and lifecycle policies to manage snapshot retention.

Watch Video