How do I resize an AWS EBS volume?

Kristina

How do you safely expand an AWS EBS volume using Elastic Volumes without downtime, and why must system administrators resize both the partition and operating system filesystem to utilize all newly allocated storage?

Leonardo

Extending Cloud Block Storage Capacity in Amazon Web Services

Modifying storage capacity on running virtual instances requires understanding the two distinct operational layers involved: the hypervisor allocation layer and the guest operating system filesystem layer. Amazon Elastic Block Store (EBS) supports dynamic resizing without system downtime using the Elastic Volumes feature on current-generation instances. However, expanding the virtual disk on the cloud management plane only increases the raw block capacity. Engineering teams must then expand the partition boundary and resize the resident filesystem from within the virtual machine to make the additional storage usable by the operating system.

Allocating Physical Storage Via The Cloud Control Plane

The initial phase takes place within the AWS infrastructure management layer to allocate raw storage space:

Management Console Configuration: Navigate to the EC2 Dashboard, locate the target volume under the Elastic Block Store menu, select Actions > Modify Volume, and enter the expanded gigabyte threshold.

Command-Line Interface Execution: Engineers utilizing terminal automation can request the expansion by passing the target block identifier and new size:

aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --size 100

State Verification: The volume transitions from modifying to optimizing and finally to in-use. The newly allocated raw bytes become immediately visible to the instance hardware layer while in the optimizing phase.

Expanding Partition Boundaries Within The Guest Environment

Once the hypervisor reports the updated block size, connect to the Linux host via SSH to extend the partition table:

Block Device Inspection: Execute lsblk to identify disk names and partition structures. The root disk (often /dev/xvda or /dev/nvme0n1) will reflect the new total capacity, whereas the underlying partition (e.g., nvme0n1p1 or xvda1) will remain constrained to the previous size.

Partition Expansion: Run the growpart utility to extend the specific partition boundary into the newly available adjacent space:

sudo growpart /dev/nvme0n1 1

(Note the mandatory space separating the device path and the partition index number).

Verification: Re-running lsblk confirms the target partition matches the higher allocation of the parent block device.

Resizing The Filesystem Layer For Operational Consumption

The final stage expands the filesystem to format and index the newly enclosed disk sectors:

Filesystem Type Identification: Check the storage formatting using df -hT to determine whether the target mount runs XFS, Ext4, or another variant.

Ext4 Filesystem Expansion: If using an ext2/ext3/ext4 volume, execute the dynamic resize utility against the target partition:

sudo resize2fs /dev/nvme0n1p1

XFS Filesystem Expansion: If operating on an XFS partition, point the expansion tool directly to the active mount point directory rather than the partition device path:

sudo xfs_growfs -d /

Capacity Confirmation: Run df -h to verify that the root mount point reflects the expanded capacity. The storage is now available for production workloads without requiring a system reboot or service interruption.