Conversational AWS infrastructure provisioning, run and verified with Sia.

A new environment request lands on your desk. Same story every time. A new app needs its own production stack, and someone has to go build it.

You open the AWS console. Pick the machine image. Pick the instance size. Assign a security group. Assign a key pair. Turn on the public IP. Pick the VPC, pick the subnet, attach the storage, add the tags. One field, one screen, at a time.

None of it is difficult on its own. All of it has to happen in the right order, in the right account, with nothing skipped, and it eats an afternoon that should have taken five minutes.

The console has a step for everything

Picking the machine image and the instance size gets an instance running, but get the size wrong and you are either paying for headroom nobody uses or resizing it under load later. Assigning the right security group comes next, and if it is copied from memory instead of checked, the instance ends up open to more than it should be, or unreachable when it needed to be open. The key pair has to be the one already sitting in the account, not a fresh one nobody else has, or the next SSH session goes nowhere. The public IP is its own toggle, easy to leave off by accident and just as easy to leave on somewhere it should not be. Then comes the network: the right VPC, the right subnet, so the instance lands inside the account's own network and not some default one. Storage has to be sized before launch, not patched on after. And the tag that marks a resource as production, the one line that decides how it gets tracked, costed, and audited later, is the easiest of all of them to skip when a request is one of ten that day.

None of this is hard by itself. Do all of it correctly, every time, across every request, and it adds up to exactly what it looks like on screen: a dozen configuration screens for one server.

What we asked Sia to do

Here is that same request, handed to Sia as one plain-English instruction, typed into the Sia CLI against an AWS account that already had eight resources running:

"Provision an EC2 instance for me. Name it Car App 3. Launch it in Mumbai. Size should be t2.medium. Assign a 50 GB EBS volume to it. Use the key pair already created in my account. Make the instance public so I can SSH into it later, and launch it in the Scogo VPC, in the public subnet. Tag it environment equals production."

Sia parsed that into a full EC2 launch and ran it. It set the instance size to t2.medium. It attached the existing key pair instead of generating a new one. It placed the instance inside the Scogo VPC, in the public subnet, with a public IP so SSH would work. It attached a 50 GB EBS volume. It tagged the resource environment equals production. Then, in the same response that finished the launch, it reported back the instance ID, the running status, the size, the public IP, the key pair, the VPC, the subnet, the storage, and the tag, the same list a cloud administrator would normally click through six screens to confirm by hand.

The resource count backed it up. Eight running resources before the request, nine after. A trip into the AWS console to check the new instance directly showed the same thing Sia had already reported: status running, t2.medium, the right key pair, the right VPC and public subnet, 50 GB of storage, tagged environment production. Exactly what was asked for, exactly what came back.

The same pattern holds for requests that were not part of this run. "Provision a second instance for the staging build, t2.small, no public IP." Done. "Add a 20 GB volume to Car App 3." Done. Same loop every time: instruction in, state changed, checked.

Watch it happen

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

Before Sia, with Sia

Before Sia: open the AWS console, pick the image and size, assign the security group and key pair, turn on the public IP, choose the VPC and subnet, attach storage, add the tags, one screen at a time. With Sia: one sentence, and the instance launches already configured that way.

Before Sia: after launch, click into the instance, the networking tab, the storage tab, the tags tab, to confirm everything actually landed where it was supposed to. With Sia: the same response that finishes the provisioning already lists the instance ID, status, size, IP, key pair, VPC, subnet, storage, and tag, before anyone goes to check.

Before Sia: knowing exactly how many resources are running in an account means opening the console and counting. With Sia: ask, and the number is right there, before and after.

Before Sia: getting the VPC and subnet right depends on someone remembering which one is the account's own and which one is public. With Sia: name it in plain English, and Sia places the instance exactly there.

Before Sia: tagging a new resource environment equals production is a manual step, easy to forget when a request is one of ten that day. With Sia: it is just part of the same sentence, done every time, not only the times someone remembers.

What Sia actually touches

Sia works directly against AWS: EC2 instance provisioning, security groups, key pairs, public IP assignment, VPCs and subnets, EBS volumes, and resource tagging. Car App 3 is what this walkthrough used to show it. The same instruction pattern holds for any EC2 launch 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 are tagged production and who requested them, 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 clicking through the console for every request. A developer standing up a new app's environment can ask Sia for exactly what it needs, sized right, tagged right, in the right VPC, without learning which of a dozen AWS screens sets which field. Access control did not disappear. Sia runs inside the AWS account, VPC, and policy scope set for it, so the permission model moves from someone with console access clicking through settings to an agent acting within the boundaries defined for it.

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

New environments launch correctly the first time, not after a round of checking and fixing. Tags land on every resource that needs them, so cost tracking and audits do not depend on someone remembering. Provisioning stops needing a dozen AWS screens' worth of institutional knowledge in one person's head. And the request that should take one sentence stops sitting in a queue behind everything else that also should have taken one sentence.

The AWS console still has every one of those screens. Sia is just the one that goes through them correctly, every time, so you do not have to.

Availability

Programmatic AWS provisioning 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 spends its days clicking through AWS console screens to stand up infrastructure that a plain English sentence could describe, 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.