Fix AWS EC2 Out of Disk Space: Grow EBS Volume Live Without Downtime

If your EC2 instance just ran out of disk space, here's the direct answer: you can grow the EBS volume without stopping the instance, on almost every current instance type, in two moves — increase the volume's size in the EC2 console or with the AWS CLI, then tell the operating system to use the new space with growpart and xfs_growfs (or resize2fs) on Linux, or Disk Management/PowerShell on Windows. The part almost nobody tells you: as of January 2026, AWS quietly dropped the old six-hour "cooldown" between volume changes, so if your first resize was too small, you don't have to sit there watching the clock — you can resize again the moment the first change finishes, up to four times in a rolling 24 hours.

First, confirm you're actually out of disk — not out of memory, and not out of inodes

Jake called Ethan on a Thursday night, and it wasn't a "quick question." A customer had walked into Jake's phone shop that afternoon wanting a photo backup restored off an old iPhone, the little shop-management app Jake runs on a single EC2 box choked halfway through the job, and now the app wouldn't start at all. The error on screen said something about not being able to write a log file. Jake assumed the server had crashed for good.

"So my server is broken? Do I need a new one?" Jake asked. Ethan didn't even open his laptop yet. "No," he said. "Ninety-five times out of a hundred when someone tells me their EC2 box 'died' overnight, it's not dead — it's full. Those are two completely different problems, and the fix for a full disk is one of the least dramatic things you'll ever do on AWS. Run df -h for me before you do anything else."

If df -h shows a filesystem at 100% (or 99%, which behaves like 100% once reserved blocks are gone), that confirms it — this is a disk-space issue, not a memory or CPU issue. Amazon EC2's built-in monitoring, the graphs you see automatically in the console, tracks CPU utilization and network in/out. Amazon EC2 doesn't provide metrics related to operating system-level memory usage or disk usage metrics out of the box — which is exactly why this problem sneaks up on people. Nothing in the default dashboard would have warned Jake, and nothing in it is going to warn you either, unless you set something up (more on that later).

A quick vocabulary note, because this post is going to use it constantly: an EBS volume (Elastic Block Store) is the virtual hard drive attached to your EC2 server. It isn't physically inside the machine — it's network-attached storage that AWS manages for you, which is exactly why you can grow it without opening a support case and swapping a physical disk. When people say "my EC2 is out of disk," they almost always mean "my EBS volume, or the partition and file system living on it, is full."

There's one more twist worth ruling out before you touch a single setting, because it fools even experienced admins: sometimes df -h shows plenty of free space and you're still getting "No space left on device" errors. That's a different, cheaper problem — a full table of inodes, the little metadata records a filesystem keeps for every file and directory it tracks. A filesystem is created with a fixed number of these records, and if something (a runaway process writing millions of tiny session or cache files, say) burns through every last one, the disk can still have gigabytes of free space and refuse to create a single new file. Check it with:

df -i

If the IUse% column reads at or near 100% while df -h shows free space, growing the EBS volume won't help you at all — a bigger disk doesn't create more inodes on an already-formatted ext4 filesystem. The fix there is finding and deleting the millions of small files (a stray cache directory or an unbounded session store are the usual culprits) or, if it happens repeatedly, reformatting with a higher inode density. This entire guide is about the "genuinely full disk" case; if df -i comes back clean, keep reading.

Step 1: increase the size of the EBS volume itself

This is the feature AWS calls Elastic Volumes. With Amazon EBS Elastic Volumes, you can increase the volume size, change the volume type, or adjust the performance of your EBS volumes, and if your instance supports Elastic Volumes, you can do so without detaching the volume or restarting the instance. That's the whole trick behind "live" resizing — you're not swapping hardware, you're asking AWS to reallocate more capacity to storage that's already attached.

Using the console

1. Sign in to the EC2 console and, in the left navigation pane under Elastic Block Store, choose Volumes.
2. Find the volume attached to your instance — if you're not sure which one, check the instance's Storage tab, which lists every attached volume and its device name.
3. Select the volume, then choose Actions → Modify volume.
4. Enter the new size in GiB. You can only go up — you can't decrease the volume size; you'd have to create a smaller volume and migrate the data with a tool such as rsync or robocopy instead. Type the new total size, not the amount you want to add.
5. Choose Modify, then confirm on the warning dialog.

That's the entire console-side job. AWS says plainly that there is no charge to modify the configuration of a volume — you're only charged for the new volume configuration after the modification starts, so clicking Modify isn't itself a billing event; it's the resulting larger (or faster) volume that shows up on next month's invoice.

Using the AWS CLI

If you'd rather script it, or you're doing this from a runbook at 2am, the command is:

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

You can change the type and performance in the same call — for example bumping a gp2 volume to gp3 while you're at it:

aws ec2 modify-volume --volume-id vol-0123456789abcdef0 --size 50 --volume-type gp3 --iops 3000 --throughput 125

Find the volume ID either in the console's Storage tab for your instance, or with aws ec2 describe-volumes --filters Name=attachment.instance-id,Values=i-xxxxxxxx if you only know the instance.

Step 2: wait for "optimizing" — you can act sooner than you think

A volume modification goes through three states, and this is where a lot of people wait far longer than they need to.

The official guidance is explicit on this: after you increase the size of an EBS volume you must extend the partition and file system to the new, larger size, and you can do this as soon as the volume enters the optimizing state — you do not need to wait for "completed." Check the state in the console's Storage tab (it shows as volume-state — modification-state) or with:

aws ec2 describe-volumes-modifications --volume-ids vol-0123456789abcdef0

For most gp3 volumes this whole modifying phase takes a couple of minutes for typical sizes; AWS describes modifications as best-effort, taking from a few minutes to a few hours depending on the requested configuration, so a jump from 100 GiB to several TiB, or a large IOPS change, can take noticeably longer than a plain size bump.

Step 3: extend the partition and file system on Linux

This is the part that actually makes the operating system see the extra room. Two commands do it: one for the partition (the labeled slice of the disk your file system lives inside), and one for the file system (the structure that actually tracks your files and folders). Growing the volume, the partition, and the file system are three separate layers, and each one needs telling.

Connect to your instance over SSH, then follow these steps in order. Note that Nitro-based instances name devices nvme0n1-style and older Xen-based instances use xvda-style names — the examples below cover both.

1. Check whether the volume has a partition. Run sudo lsblk. On a Nitro instance, the root volume (nvme0n1) typically has two partitions (nvme0n1p1 and nvme0n1p128), while an additional data volume (nvme1n1) may have no partition at all; on a Xen instance, the root volume (xvda) has a partition (xvda1), while an additional volume (xvdf) may have none. If there's no partition on the volume you're growing (common for a second, dedicated data volume mounted directly), skip straight to step 3.
2. Extend the partition with growpart, giving it the device name and the partition number as two separate arguments. For nvme0n1p1 the partition number is the digits after the "p" — 1; for xvda1 the partition number is the digits after the device name — also 1. So on a Nitro instance: sudo growpart /dev/nvme0n1 1. On a Xen instance: sudo growpart /dev/xvda 1. Mind the space between the device and the number — a common typo is running it as one word, which just errors out.
3. Confirm the file system type and mount point with df -hT. Amazon Linux 2023 and recent RHEL default to XFS; Debian and Ubuntu default to ext4. The output tells you both, so you don't have to guess.
4. Grow the file system. For XFS: sudo xfs_growfs -d / (use the mount point, not the device — XFS is fussy about this). For ext4: sudo resize2fs /dev/xvda1 (use the device path this time — ext4 wants the opposite of XFS, which trips people up if they copy one command style for both).
5. Verify. Run df -hT again. The Size column for that filesystem should now match the new volume size.

If you're on LVM, none of the above applies directly

LVM stands for Logical Volume Manager — think of it as a layer of indirection between your physical disks and the file system, a bit like how a landlord can combine three small apartments into one bigger unit without moving the building. It's common on RHEL-family AMIs and on hand-built servers where someone wanted the flexibility to add disks later. If you're using logical volumes on the EBS volume, you must use LVM's own tools to extend the logical volume — growpart and a plain resize2fs against the raw partition won't get you there on their own.

The short version of the LVM path: grow the EBS volume as in Step 1, extend the underlying partition or physical volume with pvresize, then extend the logical volume itself with lvextend, and only then run resize2fs or xfs_growfs against the logical volume's device path (something like /dev/mapper/ubuntu--vg-ubuntu--lv) rather than the raw partition. If you're not sure whether you're on LVM, run lsblk and look for a device type of lvm in the output — if you see it, stop and go check your distribution's LVM documentation for the exact pvresize/lvextend sequence before you touch anything, because guessing at LVM commands on a live root disk is one of the few ways this whole process can genuinely go wrong.

Extending the volume on a Windows Server instance

Ethan's own EC2 fleet is almost all Linux, but he handles enough client Windows boxes to know the drill cold. "Windows makes you click one extra button, that's the whole difference," he told Jake. "The concept is identical — grow the disk in AWS first, then tell the OS about it second. Windows just calls its second step Disk Management instead of a terminal command." Step 1 (growing the EBS volume in the console or CLI) is identical on both operating systems — they both sit on the same underlying Elastic Volumes feature. What changes is how you tell the OS to use the extra space.

Disk Management (point-and-click)

1. Log in to the instance with Remote Desktop.
2. Open the Run dialog (Win + R), type diskmgmt.msc, and press Enter.
3. On the menu, choose Action → Rescan Disks so Windows notices the volume is bigger.
4. Right-click the drive you want to grow and choose Extend Volume. Extend Volume can appear grayed out if the unallocated space isn't adjacent to the drive, or if the volume uses the older MBR partition style and is already at the 2 TB limit that MBR volumes can't exceed — that second one is a hard wall, not a glitch; MBR-formatted disks simply cannot grow past 2 TB no matter what you do in Disk Management.
5. Follow the wizard, accepting the maximum available space unless you have a specific reason to leave some unallocated.

If you increased the size of an NVMe volume on an instance that doesn't have the AWS NVMe driver installed, you'll need to reboot the instance before Windows can see the new volume size — on current Windows Server AMIs the driver is preinstalled, so this mostly bites older, hand-rolled images. Jake's server happened to be running an image someone else built two years earlier, and sure enough it wanted that one reboot — which he did, grumbling, on a Sunday morning, joking that the server was "acting like his shop's ancient receipt printer, which only jams on Mondays but somehow still finds a way to be difficult about it."

PowerShell (scriptable)

If you'd rather not click through a wizard, or you're doing this across a fleet:

Get-Partition
"rescan" | diskpart
Get-PartitionSupportedSize -DriveLetter D
Resize-Partition -DriveLetter D -Size $(Get-PartitionSupportedSize -DriveLetter D).SizeMax

Get-Partition returns the corresponding partition number, drive letter, offset, size, and type for each partition; Get-PartitionSupportedSize returns the minimum and maximum size the partition can be resized to; and Resize-Partition takes either a specific size in KB, MB, or GB, or the SizeMax value from the previous command to extend to the maximum available space. Run PowerShell as Administrator or every one of these commands will fail silently or with an access-denied error that doesn't obviously point back to permissions.

The rule almost every older tutorial gets wrong now

This is the counterintuitive part almost nobody has caught up on yet, because so much existing documentation and so many older forum answers were written when the six-hour wait was gospel. Trip the new limit and you'll see an error that spells out exactly when you can try again: "An error occurred (VolumeModificationRateExceeded) when calling the ModifyVolume operation: You've reached the maximum modification rate per volume limit. Wait until [timestamp] before you can issue the next modification request for this volume." That timestamp is precise down to the millisecond — copy it, and you know exactly when to retry.

"So I could just bump it 10 GB at a time and see what sticks?" Jake asked, already reaching for his keyboard. "You could," Ethan said, "but don't. Each of those four modifications still takes real time to complete before the next one is allowed to start, and each one shows up as a separate entry in the volume's history. Take one honest guess at the size you actually need, with headroom for logs and updates, and use one modification well instead of four small ones badly. I've watched people burn all four slots in a morning chasing the 'right' number one gigabyte at a time, and by the third attempt they've lost more time than the resize itself would ever have cost them."

Root volume vs. a second data volume — and the instance types where "live" isn't live

Everything above assumes your instance runs on the Nitro System — AWS's current hardware platform, which is what almost every instance type launched in the last several years uses. Nitro instances support Elastic Volumes fully live: no stop, no reboot, no detach. Ethan's rule of thumb: if you launched the instance any time recently on a mainstream family (M, C, T, R series and newer), assume it's Nitro-based and this whole process is genuinely zero-downtime.

It's a different story on older, previous-generation instance types. If you encounter an error attempting to modify an EBS volume attached to a previous-generation instance type, the workaround for a non-root volume is to detach it from the instance, apply the modification, then reattach it; for a root (boot) volume, you must stop the instance, apply the modification, and then restart it. That's the one scenario in this entire guide that genuinely involves downtime, and it's tied to the instance generation, not to anything you're doing wrong.

To check which kind you're on, look at the instance's hypervisor type on its details page in the console, or check whether lsblk shows nvme-prefixed device names (typically Nitro) — though the console's hypervisor field is the reliable source, since naming conventions alone can vary.

"No space left on device" when df -h shows plenty free

Worth repeating in more depth here, because it's the single most common reason someone follows every step above, ends up with a bigger volume, a bigger partition, and a bigger file system, and still gets write errors: the filesystem isn't full — the inode table is. As covered earlier, run df -i alongside df -h. If IUse% is pinned near 100% while the space column has room to spare, resizing the volume changed nothing that matters, because ext4 doesn't add inodes to an existing filesystem just because the underlying disk got bigger.

The usual cause on a small server is something writing enormous numbers of tiny files without ever cleaning them up — a session store, a mail queue, a build tool's cache directory, or a misbehaving cron job. Track it down with:

sudo du --inodes -x -d 2 /var | sort -n | tail -20

That lists directories under /var ranked by how many inodes they're consuming, two levels deep, so you can see at a glance which folder is the actual offender rather than guessing. Once you've found and cleared it, df -i will show IUse% dropping back down, and you can carry on with the resize steps above if the underlying disk really was also short on space. If inodes were the only problem, you may not need to resize anything at all — which is a genuinely good outcome, since it means you just saved yourself a permanent increase to your monthly bill for a problem a cleanup would have solved.

Before you resize anything: find out what actually filled the disk

Jake's instinct, like most people's, was to jump straight to Step 1 and buy more room. Ethan talked him out of skipping this part first. "Growing the disk without checking what ate it is like taking out a bigger wallet because your old one won't close," he said, "instead of noticing it's stuffed with receipts from three years ago you never needed to keep. Sometimes you genuinely need the bigger wallet. Often you just need five minutes with the old one."

Start broad, then narrow in on the exact directory:

sudo du -sh /* 2>/dev/null | sort -rh | head -15

That lists the biggest top-level directories on the box. If a specific one dominates — /var is the usual suspect — repeat the same command one directory level deeper (sudo du -sh /var/* | sort -rh | head -15) until you land on the actual folder responsible. On any server that's been running for a while without maintenance, three things account for the overwhelming majority of unplanned disk growth:

None of this means you should never resize — sometimes the growth is legitimate, a database that's genuinely bigger than it was a year ago, and the volume really does need to be permanently larger. But finding the actual cause first means you're making an informed decision about how much bigger to go, instead of guessing a round number and hoping. Jake found four months of unrotated application logs eating most of his root volume; after clearing them and setting a sane rotation policy, he still resized — just to a smaller, cheaper target than he'd first guessed.

When the commands throw an error instead of a bigger disk

Every one of these has shown up in Ethan's own terminal history at some point, and every one of them is documented behavior, not a mystery bug.

The awkward case: the disk is so full you can't even SSH in

This is the scenario nobody wants to admit to, and Jake wasn't the first person to nearly panic over it: SSH itself can fail to establish a session on a completely full root disk, because the login process sometimes needs to write to disk (session logs, PAM state, a home directory that can't be touched) before it'll let you in.

Here's the order to work through it:

1. Try connecting anyway. A "100% full" reading on df -h almost always still has a sliver of the filesystem's reserved root-only space intact (ext4 reserves a slice of the file system for root specifically for this kind of situation). If you can log in as root or with sudo, you likely have just enough breathing room to delete a log file or two.
2. If SSH refuses outright, grow the volume first, before touching anything else. This is the one time in this whole guide where you do Step 1 without being able to verify Step 3 works — because you literally can't get a terminal to run the extend commands yet. Modify the volume size from the console (this doesn't need SSH access at all), wait for optimizing, then try connecting again — on some systems, simply having the underlying block device grow relieves enough pressure at the driver level, and more importantly it sets you up to extend the partition and file system the moment you do get in.
3. If you still can't connect, use EC2 Instance Connect or Session Manager from the console rather than your regular SSH client — these browser-based paths sometimes succeed where a full PAM/SSH login won't, because the failure path can differ. If neither works, you're into stop-modify-restart territory: stop the instance, extend the volume from the console while it's stopped (which always works regardless of instance generation), then start it again and run the partition/file system extend commands as normal.

While you're in there: is this also the moment to switch volume types?

Since you're already in the Modify Volume dialog, it's worth thirty seconds to check whether you're still on the older gp2 type, because gp3 is very likely a better and cheaper default for the same workload.

You can change type and size in a single API call or console action — it doesn't cost you one of your four modification slots twice, it's still just one modification. One more option worth knowing about if you're consistently hitting a single volume's performance ceiling rather than just its size: AWS documentation on database workloads notes that multiple gp2 or gp3 volumes can be striped together in a RAID 0 configuration to multiply throughput, at the cost of losing all the data on the stripe if any one volume in it fails — a trade-off worth making only when you already have replication or backups covering that risk elsewhere.

Automating this for a fleet, instead of doing it by hand every time

Jake's setup is a single box, so clicking through the console once is genuinely fine for him. If you're managing more than a handful of Linux instances, though, doing this by hand every time doesn't scale, and AWS Systems Manager ships a pre-built automation runbook specifically for it: AWSPremiumSupport-ExtendVolumesOnLinux extends Amazon EBS volumes, their partitions, and file systems on a target Amazon EC2 instance running Linux in one automated pass. Under the hood it walks through effectively the same steps this guide just covered by hand — confirming the instance is managed by Systems Manager, checking it's actually running Linux, and, notably, creating a backup AMI from the target instance before it touches anything, so a botched partition resize on an automated run still leaves you a rollback path.

It's worth flagging one detail from AWS's own documentation on this runbook: during the partition-resizing step you might experience temporary performance impact and potential filesystem-level disruptions while it runs, which is a slightly stronger caution than the manual process carries, since the manual steps you run yourself are typically near-instant on a modern gp3 volume. For a single server responding to an overnight emergency, the manual walkthrough above is faster. For a fleet where this keeps happening across dozens of instances, wiring the runbook into your incident response is the better long-term move.

Stopping this from happening again

The single biggest reason people find out about a full disk from a broken application instead of a warning email is that, as covered above, the metrics you see automatically in the console just don't include disk usage. That's not an oversight — the hypervisor that produces EC2's default metrics genuinely can't see inside the operating system to know how full a file system is. Getting a real warning before you hit 100% means installing the unified CloudWatch agent, a small monitoring program AWS provides that runs inside your instance and reports what the hypervisor can't see.

The bare-minimum config to get disk usage reporting looks like this on Linux:

{
  "metrics": {
    "metrics_collected": {
      "disk": {
        "measurement": ["used_percent"],
        "resources": ["*"]
      }
    },
    "append_dimensions": {
      "InstanceId": "${aws:InstanceId}"
    }
  }
}

Once the agent is installed and this metric is defined, it reports to the CWAgent namespace in CloudWatch, and from there a normal CloudWatch alarm at, say, 80% used can email or page you long before an application starts throwing write errors. On Windows, the equivalent metric is LogicalDisk % Free Space, configured the same way through the agent's JSON config.

What this actually costs

As noted above, requesting a modification itself is free — you're charged for the new configuration starting once the modification begins, not for the act of resizing. What you're actually paying more for going forward is simply "more GiB of the same storage type." AWS's published gp3 price is $0.08 per GiB-month, with the first 3,000 IOPS and 125 MiB/s of throughput included at no extra charge — going from a 20 GiB to a 50 GiB gp3 volume adds roughly $2.40 a month at that rate, region pricing aside. It's genuinely one of the cheapest fixes in AWS, which is exactly why treating a full disk as a crisis rather than a two-minute console click doesn't match the actual stakes.

One thing that does not shrink automatically: once you grow a volume, you cannot shrink it back down later to save money — as covered earlier, the only way to get a smaller volume is to create a new one and migrate the data yourself. So while growing is cheap and low-risk in effect (you just live with the slightly bigger bill), it isn't literally reversible as a volume operation. Size generously enough that you're not doing this again next month, but not so generously that you're paying for terabytes you'll never touch.

Frequently asked questions

Do I need to stop or reboot my EC2 instance to grow an EBS volume?

On current, Nitro-based instance types, no — the volume modification, the partition extend, and the file system extend can all happen while the instance keeps running and serving traffic. Only previous-generation instance types require stopping (for a root volume) or detaching (for a data volume).

How long does it take for a volume resize to actually take effect?

The modification itself typically finishes in a few minutes for a straightforward size increase, though larger jumps or bigger performance changes can take longer since modifications are handled on a best-effort basis. You can extend the partition and file system as soon as the volume reaches the optimizing state — you don't have to wait for completed.

Why does df -h still show the old size after I resized the volume?

Because you've only completed the first of three layers. The volume is bigger, but the partition and file system on top of it are still the old size until you run growpart and then xfs_growfs or resize2fs.

Why do I get "No space left on device" when df -h shows free space?

This usually means the filesystem's inodes, not its data blocks, have run out. Run df -i and check IUse%; if it's near 100% while space looks fine, growing the EBS volume won't help. Track down and clear whatever is creating huge numbers of small files instead.

Can I shrink an EBS volume back down after I've grown it?

No. You can only increase EBS volume size through a modification. To end up on a smaller volume you'd create a new, smaller volume and copy the data over yourself with a tool like rsync or robocopy.

How many times can I resize the same volume in one day?

Up to four modifications within a rolling 24-hour window, as long as each previous modification has finished before you start the next one. Exceeding this returns a VolumeModificationRateExceeded error that tells you exactly when you can try again.

Is there still a six-hour cooldown between EBS volume modifications?

No — that fixed six-hour wait was removed in January 2026. You're now limited only by needing the previous modification to fully complete and by the four-per-rolling-24-hours cap, not by a fixed clock.

What's the difference between growpart and resize2fs or xfs_growfs?

growpart extends the partition — the labeled slice of the disk — to fill the newly available space on the volume. resize2fs (for ext4) or xfs_growfs (for XFS) then extends the actual file system that lives inside that partition. You typically need both, in that order, unless the file system already uses the whole disk with no partition involved.

My instance uses LVM — do the growpart and resize2fs steps still work?

Not directly. With LVM you need to extend the physical volume and then the logical volume with LVM's own commands (pvresize and lvextend) before running resize2fs or xfs_growfs against the logical volume's device path rather than the raw partition.

How do I extend a Windows EBS volume without downtime?

Modify the volume size in the EC2 console or CLI as normal, then inside the instance open Disk Management, rescan disks, and choose Extend Volume — or run the equivalent Resize-Partition command in PowerShell. No reboot is needed on current instance types unless the AWS NVMe driver isn't installed.

What do I do if my disk is so full I can't even SSH in?

Try connecting anyway first, since a small root-reserved buffer often still lets you log in even at "100%." If that fails, grow the EBS volume from the console (which needs no shell access), then retry the connection or use EC2 Instance Connect / Session Manager, which sometimes succeeds where a full SSH/PAM login won't. As a last resort, stop the instance, grow the volume while stopped, and restart it.

How do I find out what actually filled up the disk before I resize?

Run sudo du -sh /* | sort -rh to rank top-level directories by size, then repeat one level deeper into whichever directory dominates. On most small servers, unrotated logs, an unbounded systemd journal, or leftover Docker images and build cache account for most unplanned growth.

Will CloudWatch warn me automatically before my disk fills up?

Not by default. EC2's built-in metrics don't include disk usage because the hypervisor can't see inside your operating system's file system. You need to install the CloudWatch agent and configure it to report a disk usage metric, then attach a CloudWatch alarm to that metric.

Should I switch from gp2 to gp3 while I'm resizing anyway?

For most general-purpose workloads, yes. gp3 gives you 3,000 IOPS and 125 MiB/s of throughput included regardless of volume size, is AWS's current recommended default, and is typically cheaper per GiB than gp2. You can change type and size in the same modification.

What's the maximum size I can grow an EBS volume to?

It depends on the volume type: gp3 and gp2 volumes go up to 16 TiB, while io2 Block Express volumes can go up to 64 TiB. If you need more than a single volume's ceiling, the usual pattern is striping multiple volumes together in RAID 0 rather than trying to push one volume past its type's limit.

Revision note. Written September 2026. If you're reading this at midnight with a full disk and a worried customer in front of you, take a breath — this is one of the fastest, cheapest, least dramatic fixes AWS offers, and you're going to be fine.