Resizing an EBS volume is three separate steps: modify the volume in AWS, extend the partition, then grow the filesystem. It’s easy to stop after the first step, since AWS confirms the volume is resized — but the OS won’t see the extra space until you do the other two. No reboot is required for any of it; Elastic Volumes support live modification while the instance keeps running.
Step 1: Snapshot the Volume First
Before changing anything, take a snapshot as a rollback point. In the AWS console, go to Elastic Block Store > Volumes, select the volume, then Actions > Create Snapshot. This step is cheap insurance and worth doing even though volume modification itself is a low-risk, well-tested AWS operation.
Step 2: Modify the Volume Size
In the console: Elastic Block Store > Volumes, select the volume, Actions > Modify Volume, increase the Size field, and confirm. Two things worth knowing before you do this: Modify Volume only increases size — AWS doesn’t support shrinking a volume this way, so pick a size you’re confident you need. And if you’ve modified this volume recently, AWS may require the previous modification to finish before starting a new one — check the volume’s state in the console if a second modification doesn’t start immediately.
Step 3: Extend the Partition
This is the step most guides skip, and it’s the reason df shows the old size after Step 2. AWS resized the block device, but the partition on it is still the old size — the OS won’t use space outside the partition boundary. Connect via SSH and run lsblk to see your current layout and confirm the device name. Then extend the partition with growpart:
sudo growpart /dev/xvda 1(Device name and partition number depend on your instance — check what lsblk actually shows rather than assuming. Older instance types use /dev/xvdX naming; current-generation Nitro-based instances, which is most instance types running today, use NVMe naming like /dev/nvme0n1 with partitions as /dev/nvme0n1p1.)
Step 4: Extend the File System
Which command you need depends on your filesystem, and using the wrong one just returns an error rather than doing anything harmful. Check with df -T or lsblk -f first.
- ext4 (common on Ubuntu and Debian AMIs):
sudo resize2fs /dev/xvda1— takes the device path. - XFS (the default on Amazon Linux):
sudo xfs_growfs -d /mountpoint— takes the mount point, not the device path. Passing a device path here fails with an error rather than working.
Step 5: Verify
Run df -h and confirm the new size shows up for the correct mount point. If it doesn’t, double check Step 3 actually completed against the right device — a partition extend that targeted the wrong device or partition number is the most common reason this doesn’t work on the first try.
If you’re doing this as part of moving a WordPress install to bigger infrastructure rather than just freeing up space, the WordPress migration guide covers the rest of that process. And if PHP itself needs an upgrade while you’re already on the server, upgrading to PHP 8.5 on Ubuntu walks through that separately.
