DEV Community

Cover image for 💽 AWS 150: Zero-Downtime Storage Scaling - Expanding EBS Volumes
Hritik Raj
Hritik Raj

Posted on

💽 AWS 150: Zero-Downtime Storage Scaling - Expanding EBS Volumes

#aws #ebs #ec2 #100daysofcloud

🚀 Scaling without Stopping: Expanding EBS Volumes on the Fly

Hey Cloud Architects 👋

AWS EBS Storage

Welcome to Day 50 of the #100DaysOfCloud Challenge!

Today, we are solving a common production headache: a server running out of disk space. The datacenter-ec2 instance is hitting its limit, and we need to increase its storage from 8 GiB to 12 GiB. We’ll be performing a "hot" expansion modifying the infrastructure in the AWS Console and then extending the filesystem via the CLI all without a reboot.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which is perfect for mastering Linux storage management.

🎯 Objective

  • Identify the Elastic Block Store (EBS) volume attached to datacenter-ec2.
  • Modify the volume size in the AWS Management Console from 8 GiB to 12 GiB.
  • SSH into the instance using the provided .pem key.
  • Use Linux CLI tools (growpart and resize2fs or xfs_growfs) to reflect the new size in the root partition.

💡 Why Online Expansion?

In a traditional data center, adding storage often meant downtime, mounting new drives, or complex RAID re-configurations. With AWS EBS, the physical hardware change is virtualized. However, increasing the "container" size (the volume) doesn't automatically grow the "room" inside (the partition and filesystem). We must manually tell the OS to use the newly available space.

🔹 Key Concepts

  • Elastic Block Store (EBS): Scalable block-level storage volumes for EC2 instances.
  • Volume Modification: The AWS API action that changes the block device size.
  • Partition vs. Filesystem: The partition is the "slice" of the disk, while the filesystem (like ext4 or XFS) is the actual data structure inside that slice. Both must be expanded.

🛠️ Step-by-Step: Storage Workflow

🔹 Phase A: AWS Console Modification

First, we tell AWS to increase the physical allocation of the block device.

  • Find Volume: Navigate to the EC2 Dashboard, select datacenter-ec2, and click on the "Storage" tab to find the Volume ID.

  • Modify Volume: Go to Volumes, select the ID, click Actions > Modify Volume.

  • New Size: Change the size from 8 to 12 GiB and click Modify.
  • Status: Wait for the volume state to show "in-use - optimized" (though you can proceed while it's optimizing).

🔹 Phase B: Connect to the Instance

Now we move to the command line to finalize the change within the OS.

  • SSH Command: Use the key located at /root/datacenter-keypair.pem. 
  ssh -i /root/datacenter-keypair.pem ubuntu@<EC2_PUBLIC_IP>
Enter fullscreen mode Exit fullscreen mode
  • Verify Block Device: Run lsblk to confirm the OS sees 12GB at the disk level but still shows 8GB at the partition level.

🔹 Phase C: Expanding the Partition (CLI)

We must extend the partition to fill the new 12GB of space.

  • Grow Partition: Use the growpart command on the root disk (usually /dev/xvda or /dev/nvme0n1). 
sudo growpart /dev/xvda 1
Enter fullscreen mode Exit fullscreen mode

  • Verify: Run lsblk again. You should now see the partition size has increased to 12G.

🔹 Phase D: Expanding the Filesystem (CLI)

The final step is to stretch the filesystem into the new partition space.

  • Check Filesystem Type: Run df -hT to see if it is ext4 or xfs.
  • Resize (for ext4): 
sudo resize2fs /dev/xvda1
Enter fullscreen mode Exit fullscreen mode
  • Resize (for XFS): 
sudo xfs_growfs -d /
Enter fullscreen mode Exit fullscreen mode

✅ Verify Success

  • Disk Usage Check: Run df -h and confirm that / now shows a total size of 12 GiB.
  • Service Health: Ensure your application is still running without issues.

📝 Key Takeaways

  • 🚀 No Reboot Needed: Modern Linux kernels and EBS volumes support live resizing, which is critical for 24/7 operations.
  • 🛡️ Snapshot First: In production, always take an EBS Snapshot before modifying a volume, just in case something goes wrong during the partition resize.
  • 📦 Optimization Time: While the size change is immediate, the underlying AWS hardware may take time to "optimize" the performance of the new space.

🚫 Common Mistakes

  • Incorrect Device Name: Running growpart on the wrong disk or forgetting the partition number (the 1 in /dev/xvda 1).
  • Skipping the Filesystem: Many forget the resize2fs step; if you skip this, lsblk will show 12GB but df -h will still show 8GB.
  • Permission Denied: Always use sudo for storage commands as they require root-level access to the block devices.

🌟 Final Thoughts

Storage management is a bread-and-butter skill for DevOps. By mastering the transition from AWS Console changes to Linux CLI execution, you ensure that your team's development environment stays performant and scalable without ever hitting a "Disk Full" wall.

🌟 Practice Like a Pro

Want to master Linux storage and AWS EBS? Practice here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

Top comments (0)