Automated capacity escalation and native Linux file system remediation for AWS EC2, run and verified with Sia.

It's 3 a.m. Somewhere, a production server's logs have eaten through the disk, and the volume just crossed 98% full.

You know what happens next. Open the AWS console. Find the instance. Click into the volume tab. Modify the size. Then SSH into the machine itself, because the console only fixed half the problem, and manually resize the partition before anything can actually use the extra space.

None of that is complicated. It just all has to happen, in order, by someone awake enough to remember every step, at the exact hour nobody wants to be awake for it.

Here is the part that actually causes outages. An EBS volume can grow from 50 GB to 100 GB in the AWS console, and the operating system will not see a single extra byte until someone SSHs in, extends the partition, and grows the file system on top of it. Skip that step, and the console shows a bigger disk while the instance itself still reports the same old ceiling, and the logs keep filling it back up.

A resize that is actually four jobs

Watching the threshold. Somebody, or something, has to notice the volume crossed 98% before the disk fills completely and the application stops writing, or worse.

Modifying the EBS volume: A few clicks in the AWS console, but only if whoever is on call has the console workflow memorized at 3 a.m. and picks the right instance.

SSHing into the machine: The console step only resizes the block device. Somebody still has to log into the operating system directly to do anything with the extra space.

Extending the partition and growing the file system: This is the step with no visible symptom when it gets skipped. The volume looks resized everywhere except where the application actually reads and writes.

Verifying it actually worked, at both layers. A resize that looks right in the AWS console and wrong inside the instance, or the other way around, is not finished.

None of this is hard on its own. Doing all five correctly, in order, half asleep, at 3 a.m., is where it goes wrong. And the step most likely to get skipped, extending the partition and growing the file system, is the one that decides whether the extra space is usable or just a bigger number in a dashboard.

What we asked Sia to do

Here is that same 3 a.m. escalation, handed to Sia as one plain-English instruction, typed into the Sia CLI against Car App 3, an instance already running with 50 GB of storage from an earlier demo:

"Please execute an urgent storage upgrade on my instance Car App 3. Modify the EBS volume from 50 GB to 100 GB. Then SSH into the machine, handle the partition extension, and mount the volume. Lastly, please verify it."

Sia broke that into four steps and ran them in order. It found Car App 3 and its running IP address. It modified the EBS volume from 50 GB to 100 GB. Once the volume modification was confirmed, it SSH'd into the machine, extended the partition, and grew the file system on top of it. No reboot needed at any point.

Then it checked its own work at both layers. In the AWS console, Car App 3's storage now read 100 GB. Inside the instance, lsblk showed the volume at 100 GB and mounted. df -h confirmed the file system itself had the full 100 GB to work with, not just the block device underneath it.

The same pattern holds for the requests that never made it into this demo. "Grow the data volume on the reporting server before tonight's batch job." Done. "Same fix, every instance behind the load balancer, not just one." Done. No verification screenshot needed for those, just the same short loop every time. Instruction in, state changed, checked.

Watch it happen

The full sequence above, run and verified live against AWS and the instance itself. 

Before Sia, with Sia

Before Sia: notice the volume crossed 98%, open the AWS console, resize the EBS volume, then SSH in separately to extend the partition and grow the file system, hoping that last step does not get skipped under pressure.
With Sia: one sentence, and both layers get handled in order.

Before Sia: confirming a resize actually worked means logging into the instance and running lsblk, then df -h, and cross-checking both against the console by hand.
With Sia: ask, and get both numbers back in the same response.

Before Sia: a storage escalation at 3 a.m. means someone gets paged, wakes up, and works through the AWS console half asleep.
With Sia: the same request, typed or asked, with nobody standing at a keyboard clicking through tabs.

Before Sia: growing a disk on a live production server usually means scheduling downtime or at least holding your breath through a reboot.
With Sia: the resize, the partition extension, and the file system growth all happen with zero downtime.

Before Sia: knowing which instances got resized last month, and by whom, means digging through console history and old SSH sessions.
With Sia: the answer is a query against a signed record.

What Sia actually touches

Sia works directly against AWS: EC2 instances, EBS volumes, and the block storage layer underneath them. And it works directly against the operating system itself over SSH: partition tables, file systems, and mount points. Car App 3 and its EBS volume are what this walkthrough used to show it. The same instruction pattern holds for any instance and any volume in the account.

The interaction is conversational. The execution is not a guess. Every change runs through the same governance that lets Sia act on production infrastructure: a mutation gate with three verdicts, allow, require approval, or block, sensitive changes queued for a human, destructive operations blocked outright, and every action written to an append-only, HMAC-signed audit log that exports with its signatures intact. When someone asks which instances got resized, when, and by whom, the answer is a query against a signed record, not a scroll through console history.

This is not only a cloud administrator's job anymore

None of this needs a cloud administrator awake and clicking through the console for every alert. A developer who owns the service running on Car App 3 can ask Sia to add the storage themselves, scoped to exactly that instance, without needing standing access to the rest of the account. Ask Sia to touch a different team's instance from outside that scope, and it will not. Access control did not disappear. Sia runs inside the role-based scope you set, so the permission model moves from "a human with console access clicking through tabs at 3 a.m." to "an agent acting within a policy you defined, at any hour."

It is the same Sia whether the request comes in through the command line, the web, or the desktop app. The surface is just the door.

What this actually changes

Capacity escalations get handled the moment they are needed, not the moment someone wakes up. The step that used to get skipped under pressure, extending the partition and growing the file system, runs every time, not just the times someone remembers. Nobody has to be paged for a fix that takes seconds to describe and seconds to run. And when someone asks which instances got resized and when, the record is already there.

The disk still fills up at 3 a.m. It just does not need to wake anyone to fix it.

Availability

Automated capacity escalation runs on the AWS integration that is in Sia now, across the Sia CLI, the Sia Desktop App, and the web. We deliver Sia as part of the Scogo platform to enterprise customers, so there is no public download.

If your team is still getting paged to resize volumes and extend partitions by hand, we want to put Sia in front of your infrastructure. Start with a pilot at scogo.ai/request-demo.

Autonomous where it is safe, governed where it matters, on the record everywhere.