A production EC2 instance's Amazon EBS data volume is nearly full. How do you grow it without downtime, and what are the limits of an EBS volume modification?

## The operation has two halves The single most common mistake is doing only the AWS half and wondering why `df` is unchanged. Growing storage under a running instance is always two steps: **AWS resizes the block device**, then **the guest OS grows the structures on top of it**. ### Half one: Elastic Volumes EBS Elastic Volumes lets you change a volume's size, type, IOPS and throughput **while it is attached and in use**, on current-generation (Nitro) instances, with no detach, stop, or reboot. One API call carries all the dials you want to change: ```bash aws ec2 modify-volume --volume-id vol-0abc \ --size 500 --volume-type gp3 --iops 6000 --throughput 250 ``` The volume then reports a modification state you can poll with `DescribeVolumesModifications`: - `modifying` — the change has been accepted and is being applied. - `optimizing` — the new configuration is live but the volume is still being rebalanced in the background; it is fully usable, at performance somewhere between the old and new settings. - `completed` — done. This works on the **root volume** too, which surprises people; you do not need to stop the instance to grow it on modern instance types. ### Half two: partition and filesystem Until you act inside the instance, the operating system still sees the old geometry. If the volume is partitioned, the partition table must be updated to claim the new space, and then the filesystem grown into the enlarged partition. Both are standard Linux operations that work on a mounted, live filesystem for the common filesystem types; the specifics belong to the OS, not to EBS. What matters for the AWS answer is that **the step exists and is yours to run** — nothing about `ModifyVolume` reaches inside the guest. ## The limits that actually bite **You can only grow.** There is no shrink operation, and no way to restore a snapshot into a smaller volume. If you genuinely need a smaller disk, you create a new, smaller volume, copy the data across at the filesystem level, and swap the attachment — which is real downtime and real risk. This is the reason to think about growth before you provision, not after. **There is a modification cooldown.** After a successful modification, the same volume cannot be modified again for a waiting period — six hours at the time of writing. Teams that automate "add 10 GiB when 90% full" discover this the first time the volume fills twice in an afternoon and the second call is rejected. Grow in meaningful increments, and alarm early enough that you are not resizing under pressure. **Throughput during optimisation is not the new number yet.** Do not schedule a modification as the fix for a load spike already in progress and expect instant relief. **The instance has its own ceiling.** Enlarging a volume or raising its provisioned IOPS does nothing if the instance type's EBS bandwidth is already the bottleneck. Check both sides. ## Doing it safely A sensible production sequence: 1. Take a snapshot first. It is incremental and cheap, and it is your undo button if the partition step goes wrong. 2. `ModifyVolume` with the new size — and size for the next twelve months, not the next week, because of the cooldown. 3. Poll until the state leaves `modifying`; the OS can already see the larger device. 4. Extend the partition, then grow the filesystem, and confirm with the OS's own free-space reporting. 5. Check monitoring afterwards: free space, volume queue length and latency. ## Where this fits in an interview It is usually asked as a capacity incident — "the disk is 95% full at 2am, what do you do?" — and the interviewer is listening for three things: that you know the resize is online, that you remember the in-guest step, and that you know it is one-directional so the sizing decision deserves thought. A candidate who answers "stop the instance and swap volumes" has described a decade-old procedure.