Day 50: Expanding EC2 Instance Storage for Development Needs

Running out of disk space on an EC2 instance is a common problem in development and production environments. As applications, logs, packages, Docker images, and other data grow, the underlying storage may need to be expanded without replacing the EC2 instance.

As part of 100 Days of Cloud (AWS) on KodeKloud, Day 50 focuses on expanding the storage of an existing EC2 instance.

In this lab, the devops-ec2 instance had an 8 GiB EBS root volume, and the requirement was to increase it to 12 GiB while making the additional storage immediately available to the root filesystem.

Step 1: Identify the EC2 Instance

First, locate the devops-ec2 instance from the AWS EC2 console.

Navigate to:

AWS Console
   ↓
EC2
   ↓
Instances
   ↓
devops-ec2

Open the instance details and check the Storage section.

The root device was attached to an EBS volume with an initial size of:

8 GiB

The root device inside the Linux instance was:

/dev/xvda

with the root partition:

/dev/xvda1

Step 2: Modify the EBS Volume

Navigate to:

EC2
   ↓
Volumes

Locate the 8 GiB EBS volume attached to devops-ec2.

Select the volume and choose:

Actions → Modify volume

Change the size from:

8 GiB

to:

12 GiB

Then select Modify.

The important point here is that we are modifying the existing root volume, not creating a new EBS volume.

After the modification, AWS increases the underlying EBS block device.

However, the operating system may still report the original partition size.

Step 3: SSH Into the EC2 Instance

The task provides the SSH key on the aws-client host:

/root/devops-keypair.pem

First, make sure the private key has the correct permissions:

chmod 400 /root/devops-keypair.pem

Then connect to the EC2 instance:

ssh -i /root/devops-keypair.pem ec2-user@<EC2-PUBLIC-IP>

Once connected, verify that you are working on the correct instance.

Step 4: Check the Existing Disk and Partition

Before changing anything inside Linux, check the block devices:

lsblk

Initially, the output showed an 8 GiB root disk similar to:

NAME        SIZE TYPE MOUNTPOINTS
xvda          8G disk
├─xvda1       8G part /
├─xvda127     1M part
└─xvda128    10M part /boot/efi

This is important because it establishes the original state.

The structure is:

/dev/xvda       → EBS disk
/dev/xvda1      → root partition
/               → root filesystem

After modifying the EBS volume, the underlying disk becomes 12 GiB, but the partition can still remain 8 GiB.

Step 5: Verify the Filesystem Type

Before expanding the filesystem, determine which filesystem is being used.

For example:

df -Th

In this environment, the root filesystem was XFS.

The root filesystem was mounted at:

/

This matters because different filesystems use different expansion commands.

For XFS, we use:

xfs_growfs

Step 6: Verify the Final Storage Size

Now verify the root filesystem:

df -h /

The final output showed:

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       12G  1.6G   11G  13% /

The most important value is:

/dev/xvda1       12G

This confirms that the root filesystem is now using the expanded 12 GiB capacity.

You can also run:

lsblk

to confirm the disk and partition sizes.

Conclusion

Day 50 of the 100 Days of Cloud (AWS) challenge demonstrated a practical storage-management scenario that frequently occurs in real DevOps environments.

The devops-ec2 instance originally had an 8 GiB root EBS volume. I expanded the existing EBS volume to 12 GiB, expanded the root partition using growpart, and then expanded the XFS filesystem using xfs_growfs.

The final verification confirmed:

/dev/xvda1 → 12 GiB → /

This lab reinforced an important operational principle: expanding cloud storage is a multi-layer process. The cloud provider's block device, the operating-system partition, and the filesystem must all be considered when increasing available disk capacity.