Bulk EC2 and EBS decommissioning in one instruction, run and verified with Sia.

Testing wraps up. Three EC2 instances, spun up for one job, are done. Time to clean up.

You open the console. You find the first instance. Terminate.

You find the second. Terminate.

You find the third. Terminate.

Three down, and the job feels finished. It isn't. In AWS, unless a volume was flagged "delete on termination" when the instance was launched, terminating the instance does nothing to the volume attached to it. It just sits there, unattached, still provisioned, still billed, in a different part of the console than the one you were just in.

The cleanup that never really finishes

Every test cycle ends the same way: spin up instances for a job, run the job, and now someone has to put everything back down. Underneath that one task is a handful of separate steps, and each one is its own chance to leave something running.

Terminating the instance: Found in the console, one at a time, three separate lookups for three separate instances, in a list that also shows everything else currently running that you don't mean to touch.

Finding the volume that belonged to it: Not shown next to the instance. A separate screen, a separate list, matched up by name or by guesswork about which volume went with which app.

Terminating that volume too: A second action, after the first one already felt like it closed the ticket.

Checking that any of it actually finished: A terminate request isn't the same as terminated, and a detach isn't the same as deleted. Someone has to go back and refresh the console to confirm each of the six or so actions actually landed.

Doing it again next sprint. Car App 1, 2, 3 today. A different set of names next time. The same manual pass, repeated by whoever remembers to run it.

None of this is hard. All of it is repetitive. And the step most likely to get skipped, going back for the volume once the instance already looks gone, is the one that keeps quietly costing money after everyone has moved on to the next test.

What we asked Sia to do

Here is that same cleanup, handed to Sia as one instruction, typed once into the Sia CLI:

"Hi Sia. My Car App testing is done. Please decommission these three EC2 instances that start with Car App 1, Car App 2, and Car App 3, and also decommission and delete all the volumes attached to these three instances."

Sia built a decommissioning plan and ran it: terminate all three instances, wait for each one to actually reach the terminated state, then verify each attached volume is deleted, not just detached.

It terminated Car App 1, Car App 2, and Car App 3, and waited for AWS to confirm each had actually terminated rather than just requested. Then it checked the volumes one at a time. The first came back already gone, not found, confirmed, deleted. It checked the second, then the third.

The summary that came back: all three Car App instances deleted, all three of their volumes deleted, nothing left running or provisioned from that test cycle.

The console backed it up without being asked to. A refresh of the volumes page showed the count had dropped by three. A refresh of the instance dashboard showed the running count back down to six.

The same pattern covers requests that never made it into this walkthrough. "Just decommission Car App 2 and its volume, leave the other two running a bit longer." Done. No fresh verification screenshot needed for that one, just the same short loop: instruction in, resources gone, checked.

Watch it happen

The full sequence above, run and verified live in the AWS console. 

Before Sia, with Sia

Before Sia: open the console, find each of three instances one at a time, terminate them one at a time.
With Sia: one instruction naming all three, decommissioned together.

Before Sia: once the instance is gone, go hunt down its volume on a separate screen and terminate that too, or forget and let it keep billing.
With Sia: the volumes are named in the same instruction and deleted in the same run.

Before Sia: refresh the console repeatedly to check whether termination and deletion actually finished.
With Sia: it waits for each instance to terminate, confirms each volume is actually deleted, and reports back once it has verified, not once it has requested.

Before Sia: find out months later that a stray volume from a finished test cycle has been billing quietly the whole time.
With Sia: decommissioning happens the same day testing wraps, in the instruction that ends the test cycle.

What Sia actually touches

Sia works directly against AWS: EC2 instances, their lifecycle state, and the EBS volumes attached to them. This walkthrough used EC2 and EBS. The same pattern extends to the other resource types AWS exposes through its API.

Every change runs through the same governance that lets Sia act on infrastructure at all: a mutation gate with three verdicts, allow, require approval, or block, destructive operations like terminating an instance or deleting a volume routed for that check, and every action written to an append-only, HMAC-signed audit log that exports with its signatures intact. When someone asks what was decommissioned and when, the answer is a query against a signed record, not a search through console history.

This is not only a cloud team's job anymore

None of this needs someone from the cloud team at the keyboard for every teardown. The engineer who ran the test can ask Sia to decommission their own instances and volumes directly, scoped to exactly the resources they own, not the whole account. Access control did not disappear. Sia runs inside the role-based scope you set, so the permission model moves from "a person with console access clicking through it" to "an agent acting within a policy you defined."

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

Test environments get torn down the day the job ends, not whenever someone gets around to it. Orphaned volumes stop quietly adding to the bill after everyone has moved on. Anyone authorized can decommission their own resources without opening a ticket to the cloud team. And there's a record of exactly what was terminated, what was deleted, and when.

Testing finishes in an afternoon. Cleanup should too.

Availability

Bulk AWS decommissioning 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 running test environments on AWS and cleanup is a manual pass through the console every time, we want to put Sia in front of your account. Start with a pilot at scogo.ai/request-demo.

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