On AWS, when an EC2 instance is first launched, its root volume size is determined by the AMI’s backing snapshot.  For example, an Amazon Linux AMI will result in an 8GB root volume being created.  At launch, the root volume size can only be increased, not decreased. Some AMIs have even larger backing snapshots.  This leads to waste in many cases.  Users are forced to pay for the unused space, as EBS volumes are paid on a GB per month basis, regardless of whether the space is in use or not.

There’s really no reason we should overprovision disk space in a cloud environment since it’s become so easy to increase EBS volume size online as described here in these 3 steps:

1. Go to AWS EC2 console, right-click the EBS volume and select "Modify Volume," increase the Size, and click "Modify."

2. Log on to the EC2 instance, use the growpartcommand to grow the partition to fill the available space.

growpart /dev/xvda 1

3. Use the resize2fs command to resize the file system to fill the available partition space.

resize2fs /dev/xvda1

Unfortunately, it is still very difficult to decrease a root EBS volume size, and it can only be done offline.

In this blog, I will demonstrate how to shrink an Amazon Linux EC2 root volume size from 8GB to 4GB by walking through the steps. The actual file system used size is about 2GB.

1. Stop the target EC2 instance.
2. Snapshot the root EBS volume.
3. Create an EBS volume from the snapshot. This will be the source EBS volume.
4. Launch a new EC2 worker instance in the same region as the target instance.
5. Attach the source EBS volume to the worker instance as xvdf.
6. Create a new target EBS volume of smaller size 4GB.  The size needs to be at least slightly larger than the actual filesystem used size.
7. Attach the new target EBS volume to the worker instance as xvdg.
8. Check file system on the source EBS volume. This is required in order to do the resize2fs.

e2fsck -p -f /dev/xvdf1

9. Shrink the file system to the minimal size.

resize2fs -M /dev/xvdf1

10. Get the newly shrunken file system’s total number of blocks.

NEW_FS_BLOCK_COUNT=`tune2fs -l /dev/xvdf1 | grep "Block count:" | awk '{print $3}'`
NEW_FS_BLOCK_SIZE=`tune2fs -l /dev/xvdf1| grep "Block size:" | awk '{print $3}'`
NEW_FS_SECTOR_COUNT=$((NEW_FS_BLOCK_COUNT*NEW_FS_BLOCK_SIZE/512))

11. Copy the entire newly shrunk file system disk blocks from source to the new target EBS volume.

DD_BS_1M=$((1<<20))
DD_COUNT=$((NEW_FS_SECTOR_COUNT*512/DD_BS_1M+1))
dd if=/dev/xvdf of=/dev/xvdg bs=1M count=${DD_COUNT}

12. Re-partition new target EBS volume to cover all usable space.

a. Delete partition 1.

sgdisk -d 1 /dev/xvdg

b. Get the last usable disk sector.

NEW_DISK_LAST_USABLE_SECTOR=`sgdisk -p /dev/xvdg | grep " last usable sector is " | awk '{print $10}'`

c. Recreate partition 1 to cover all usable space.

sgdisk -n 1:4096:${NEW_DISK_LAST_USABLE_SECTOR} /dev/xvdg

13. Grow file system on the new target EBS volume to fill the new partition space.

resize2fs /dev/xvdg1

14. Stop the worker instance.

15. Detach the new target EBS volume xvdg from the worker instance.

16. Detach the source EBS volume xvdf from the worker instance.

17. Attach the new target EBS volume to the target EC2 instance as xvda.

18. Start the target EC2 instance.

Verify everything is good before proceeding with the cleanup.

Cleanup

1. Terminate the EC2 worker instance.
2. Delete the temporary target EBS volume.
3. Delete the snapshot.
4. Delete the source root EBS volume.

As demonstrated above, even though we can reduce the root EBS volume size to a better fit size to save costs the process is complex and error-prone. We at FittedCloud are excited about our recently released Root Volume Resize feature that can help users reduce cost by reducing EBS root volume size with a click of a mouse from our SaaS web user interface.