This turned out to be relatively painless, with the exception that amazon's documentation is missing a crucial step in the process. If you have already increased your EBS size, and are trying to make your EC2 instance recognize the larger disk, check out this stackoverflow link which details what you need to do on the server.

I will go through this process from start to finish, including what helped me finish the task in the stackoverflow answer I linked above.

Firstly, you should know that storage for your instance and the server you create with the EC2 instance are not directly coupled. Amazon has a service called Amazon EBS (Elastic Block Store) which makes it incredibly easy to increase (or decrease) the storage for a given instance.

Navigate to your EC2 dashboard, click on the EC2 instance that you need to add storage to, and then go to Root devices or Block devices in the Description tab. Click on the disk name (e.g. /dev/sda1), and then click on the EBS ID link in the popup that appears. This will take you to the volume for the instance. Alternatively you can click on "Volumes" in the left hand navigation bar, and select the volume you'd like to update manually.

Click on "Actions", and then "Modify Volume". Change the size to the number of gigabytes you want your volume to have. I changed mine from 8 to 32 here. You'll need to confirm you'll want to change, and then you'll see a success modal and you're done with the AWS online portion.

Now it's time to SSH into your server.

So, SSH into your server.

ssh ubuntu@myserver

Using df -h we can get a human readable size/percentage used of the file system. I've cut out non-related file systems in this output.

ubuntu@ip-172-31-63-42:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.7G  7.0G  752M  91% /

and check the block devices. The one I'm interested in is /dev/xvda1. The size is still at 8 gigs.

ubuntu@ip-172-31-63-42:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 88.5M  1 loop /snap/core/7270
loop1     7:1    0 89.4M  1 loop /snap/core/6818
loop2     7:2    0   18M  1 loop /snap/amazon-ssm-agent/1335
loop3     7:3    0   18M  1 loop /snap/amazon-ssm-agent/1455
xvda    202:0    0   32G  0 disk 
└─xvda1 202:1    0    8G  0 part /

As the stackoverflow answer points out, xvda1 is still a 8G partition on xvda, which is now correctly a 32G device. We can use growpart to tell the partition to grow.

ubuntu@ip-172-31-63-42:~$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=2048 old: size=16775135 end=16777183 new: size=67106783,end=67108831

Checking the blocks again, we can see the partition is now 32G

ubuntu@ip-172-31-63-42:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 88.5M  1 loop /snap/core/7270
loop1     7:1    0 89.4M  1 loop /snap/core/6818
loop2     7:2    0   18M  1 loop /snap/amazon-ssm-agent/1335
loop3     7:3    0   18M  1 loop /snap/amazon-ssm-agent/1455
xvda    202:0    0   32G  0 disk 
└─xvda1 202:1    0   32G  0 part /

Checking df -h again, we see that the filesystem is still the same size, even though the partition has been increased.

ubuntu@ip-172-31-63-42:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.7G  7.0G  752M  91% /

The last and final step is to resize the file system to take up the entire partition. You can use resize2fs to accomplish this.

ubuntu@ip-172-31-63-42:~$ sudo resize2fs /dev/xvda1
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 4
The filesystem on /dev/xvda1 is now 8388347 (4k) blocks long.

ubuntu@ip-172-31-63-42:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       31G  7.0G   24G  23% /

now the file system correctly shows as updated and the storage is available for you to use.