Title: How to Resize an AWS EBS Volume Without Downtime
Author: Immanuel Raj
Published: May 26, 2026

---

![AWS EBS volume resize diagram showing server expansion without downtime using 
growpart and resize2fs](https://immanuelraj.dev/wp-content/uploads/2026/05/ebs-resize-
featured.avif)

# How to Resize an AWS EBS Volume Without Downtime

[May 26, 2026](https://immanuelraj.dev/resize-aws-ebs-volume/)

—

by

[Immanuel Raj](https://immanuelraj.dev/author/iamimmanuelraj/)

in [Linux](https://immanuelraj.dev/category/linux/), [Self Hosting](https://immanuelraj.dev/category/self-hosting/)

Read Time

3–5 minutes

## Why Resize an AWS EBS Volume Without Downtime?

When you first provision a cloud server, you make your best guess at how much storage
you will need. But production environments are unpredictable. Logs accumulate. Databases
grow. A sudden spike in traffic can push disk utilisation from a comfortable 40%
to a worrying 85% in a matter of days.

The good news: modern cloud providers like AWS let you expand an EBS (Elastic Block
Store) volume while the instance is fully running. No scheduled maintenance window.
No SSH session drop. No service interruption.

This post walks through exactly how to do it — and more importantly, explains _why_
each step is necessary.

## When Should You Resize?

Here are common real-world triggers that signal it is time to expand your volume:

 * Disk utilisation crosses **75–80%** — a good early-warning threshold
 * Your monitoring or observability stack starts throwing **low disk space alerts**
 * A **database optimisation or vacuum job** is about to run and needs temporary
   headroom
 * You are **enabling a new service** (logging agent, APM tool, backup daemon) that
   will write to disk
 * A **large deployment or migration** is planned and you want a safety buffer
 * Automated disk-usage reports show a steady upward trend — **growth is inevitable**

💡 **Pro tip:** Do not wait until you are at 90%+. Resize proactively when you hit
75–80%. Emergency resizes under pressure lead to mistakes.

## Understanding the Three Layers

Before running any commands, it helps to understand that a disk has three distinct
layers — and you need to expand all three in sequence:

| Layer | What It Is | How You Expand It | 
| **1. The Disk** | The raw EBS volume — just a block of storage AWS allocates | AWS Console / CLI | 
| **2. The Partition** | A defined slice of the disk with a start and end sector | `growpart` | 
| **3. The Filesystem** | The structure (ext4/xfs) that actually stores your files | `resize2fs` or `xfs_growfs` |

Think of it like this: expanding the EBS volume is like buying a bigger plot of 
land. `growpart` moves the fence to claim the new land. `resize2fs` builds on it
so you can actually use it.

New to these Linux tools? Our [Linux Saviours](https://immanuelraj.dev/linux-saviours/)
guide covers the command-line essentials every server admin needs.

## Step 1 — Expand the EBS Volume in AWS

Log into the AWS Console and navigate to **EC2 → Elastic Block Store → Volumes**.
Select the volume attached to your instance, click **Actions → Modify Volume**, 
and enter the new size. Click **Modify** to confirm.

The change is applied within seconds to a few minutes. The instance keeps running
throughout. You can verify the new size is visible at the OS level by running:

    ```wp-block-code
    lsblk
    ```

A sample output after the AWS-side resize might look like this:

    ```wp-block-code
    NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
    nvme0n1      259:0    0  300G  0 disk
    ├─nvme0n1p1  259:1    0   99G  0 part /
    ├─nvme0n1p15 259:3    0  106M  0 part /boot/efi
    └─nvme0n1p16 259:4    0  913M  0 part /boot
    ```

Notice: the **disk** (`nvme0n1`) shows the new size, but the **partition** (`nvme0n1p1`)
still shows the old size. This is expected — you have not run `growpart` yet.

## Step 2 — Grow the Partition

Now tell the OS to extend the partition boundary to fill the new disk space. The
command takes the disk name and partition number as separate arguments:

    ```wp-block-code
    sudo growpart /dev/nvme0n1 1
    ```

If successful, you will see output like `CHANGED: partition=1 start=... old: size
=... end=... new: size=... end=...` confirming the partition boundary was moved.

## Step 3 — Extend the Filesystem

First, check your filesystem type:

    ```wp-block-code
    df -T /
    ```

Then run the appropriate command based on the result:

### growpart resize2fs — Expand ext4 on AWS EBS (Ubuntu, Debian)

    ```wp-block-code
    sudo resize2fs /dev/nvme0n1p1
    ```

### xfs_growfs — Resize AWS EBS Volume on XFS (Amazon Linux, RHEL)

    ```wp-block-code
    sudo xfs_growfs -d /
    ```

## Step 4 — Verify

Run the final check to confirm the OS now sees and can use the full expanded space:

    ```wp-block-code
    df -h /
    ```

Expected output (example):

    ```wp-block-code
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/root        295G   47G  248G  16% /
    ```

If the **Size** column reflects your new target size, you are done. No reboot required.

## Important Constraints to Know

 * You can only **increase** EBS volume size — shrinking is not supported
 * After a modification, AWS enforces a **6-hour cooldown** before you can modify
   the same volume again
 * The OS-level steps (`growpart` + `resize2fs`) must be run manually — AWS does
   not do this automatically
 * Always verify with `lsblk` and `df -h` before and after to confirm each layer
   expanded correctly

## Summary

Resizing an EBS volume live is straightforward once you understand the three-layer
model. AWS handles the disk. You handle the partition and filesystem. The whole 
process takes under five minutes and your application never knows it happened.

Do it proactively, do it calmly, and your servers will never run out of space at
the worst possible moment. For more on keeping Linux servers healthy, see how we
[audited 41 Ubuntu servers for a critical CVE](https://immanuelraj.dev/copy-fail-cve-2026-31431-ubuntu-audit/)—
the same discipline applies here.

[AWS](https://immanuelraj.dev/tags/aws/) [cloud storage](https://immanuelraj.dev/tags/cloud-storage/)
[disk management](https://immanuelraj.dev/tags/disk-management/) [EBS](https://immanuelraj.dev/tags/ebs/)
[EC2](https://immanuelraj.dev/tags/ec2/) [growpart](https://immanuelraj.dev/tags/growpart/)
[linux](https://immanuelraj.dev/tags/linux/) [resize2fs](https://immanuelraj.dev/tags/resize2fs/)

---

[Previous:  How I Audited 41 Ubuntu Servers for CVE-2026-31431 “Copy Fail” — and What I Found](https://immanuelraj.dev/copy-fail-cve-2026-31431-ubuntu-audit/)