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.

1. 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
2. From the snapshot of the OLDBIG volume create a volume and name it SNAPSHOT or something memorable
3. 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
4. Launch a temporary instance using the same AMI type as the instance you want to shrink name it TEMPINSTANCE
5. Attach the NEWSMALL and SNAPSHOT volumes to the TEMPINSTANCE while it is running
6. 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
7. mkdir /mnt/small
8. mkdir /mnt/snap
9. mount /dev/xvdf1 /mnt/small
10. mount /dev/xvdg1 /mnt/snap
11. rsync -aHAXxSP /mnt/snap/ /mnt/small --delete
12. 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
13. 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/