Background: Created an EC2 instance with a 40GB hard drive, realized that I wouldn’t need that size and seeing that the EBS pricing for my region is $0.12 per GB-month of provisioned storage I was paying for 32GB of unneeded space.
So I thought to myself I should shrink the EBS volume down and reduce the monthly spend until I have need of the extra space.
To do that I was trying to follow https://cloudacademy.com/blog/amazon-ebs-shink-volume/ but found that with the latest Amazon Linux AMI (Amazon Linux AMI 2017.03.1 (HVM), SSD Volume Type – ami-10918173). The shrunken volume just would not boot.
I played with the partitioning by trying to duplicate the GPT paritioning with fdisk and / or parted but I just couldn’t get the right format of partition to get it bootable. I even used e2label to set the root label but there was something missing.
So my work-a-round to “shrink” a volume is as follows.
- Shutdown the Instance that holds the 40GB EBS root volume you want to shrink and take a snapshot. I will refer to this instance and it’s volume as OLDBIG
- From the snapshot of the OLDBIG volume create a volume and name it SNAPSHOT or something memorable
- Launch a new Instance of the same type as the one that contains the volume you want to shrink but provision a smaller EBS root volume. Stop this instance and detach the volume name it something like NEWSMALL
- Launch a temporary instance using the same AMI type as the instance you want to shrink name it TEMPINSTANCE
- Attach the NEWSMALL and SNAPSHOT volumes to the TEMPINSTANCE while it is running
- SSH into TEMPINSTANCE and use lsblk to see where where the NEWSMALL and SNAPSHOT volumes are mounted. Mine were at /dev/xvdf1 and /dev/xvdg1
- mkdir /mnt/small
- mkdir /mnt/snap
- mount /dev/xvdf1 /mnt/small
- mount /dev/xvdg1 /mnt/snap
- rsync –aHAXxSP /mnt/snap/ /mnt/small –delete
- Once the copy is complete shutdown TEMPINSTANCE and detach NEWSMALL and then detach the current EBS volume from the OLDBIG instance and re-attach the NEWSMALL volume to the OLDBIG instance using the correct root device name /dev/xvda
- Start the OLDBIG instance and it should now be running with the new smaller volume
This seems like a better approach to actually perform a shrink because it will pick up the special boot sauce from the larger volume and put it in the new small volume ==> https://matt.berther.io/2015/02/03/how-to-resize-aws-ec2-ebs-volumes/