We gave Kiro a brain for AWS, locally, for free

We built MiniStack (a local AWS emulator) when LocalStack moved its core services behind a paywall. It runs on a single port at http://localhost:4566, emulates around 60 AWS services, and costs nothing. Day to day, we use it for testing AWS code and for prototyping new services without spending a cent on a real account.

The piece that was missing was the editor side of the loop. We work in Kiro. Kiro is a strong agentic IDE. But every new AWS workflow inside the editor started with the same overhead: telling Kiro where to point the SDK clients, reminding it of the testing patterns we use, walking it through which service does what for the case at hand. Repetitive context we'd already written down somewhere else.

So we pulled all of it into a Kiro Power. The Power ships steering files for the services we use most, a testing workflow file, and a manifest that activates the moment you mention MiniStack or AWS in chat. Kiro picks it up automatically, no manual prompting.

That's what this post is about. It's called MiniStack × Kiro, it's open source, and it's about removing the repetitive context-loading step from every AWS session.

What changes once you install it

Kiro picks up specific behaviors the moment you mention AWS or MiniStack in chat:

1. It configures your boto3, AWS CLI, Terraform, and CDK setups against localhost:4566 with the right test credentials, without asking you for them.
2. It writes service-specific code that actually runs against MiniStack. Not pseudocode. Real S3 calls. Real DynamoDB conditional updates. Real Step Functions ASL.
3. It walks you through services you don't know yet. There are steering files for S3, SQS, SNS, DynamoDB, Lambda, IAM, Step Functions, EventBridge, API Gateway, Cognito, and CloudWatch. Each one is a hands-on guide written for the local-first workflow.
4. It knows the reset endpoint, so when you ask it to run a test scenario from scratch, it resets the right state instead of polluting it.
5. It handles multi-tenancy properly. MiniStack scopes resources by your access-key-as-account-ID. The Power knows this and reuses it when you want isolated environments per developer or per CI lane.

The steering files were extracted from real workflows we run every week, not synthesised.

Installing it

Two paths, both take under a minute.

From the GitHub repo:

1. Open Kiro, click the Powers icon in the sidebar.
2. Add Custom Power, then GitHub Repository.
3. Paste https://github.com/ministackorg/ministack-power.
4. Click Add.

From a local folder, if you cloned it:

1. Open Kiro, click the Powers icon.
2. Add Custom Power, then Local Directory.
3. Paste the absolute path to the folder you cloned.
4. Click Add.

That's it. The Power activates automatically when you talk to Kiro about AWS or MiniStack.

You'll also want MiniStack itself running. One line:

pip install ministack && ministack

It boots in around two seconds and uses around 30 MB of RAM at idle. Health check:

curl http://localhost:4566/_ministack/health

What it looks like in practice

A few examples from real sessions, since "Kiro plus a Power" sounds abstract until you see it doing work.

S3 presigned URLs.
A Python script that uploads a file via presigned PUT, downloads it via presigned GET, then verifies the round-trip. The Power pulls in the S3 steering file, the script gets generated pointed at localhost:4566 with the right SigV4 settings, runs, and you see the output. No clarifying questions about endpoint configuration. No "let me check the AWS docs first."

DynamoDB conditional writes.
Three test cases against the local DynamoDB exercising ConditionExpression plus ReturnValuesOnConditionCheckFailure=ALL_OLD. The case where the condition fails and the API returns the existing item in the error body is the one most emulators get wrong; MiniStack handles it correctly, and the Power knows to test for it.

Step Functions ASL.
A state machine with a Map iterator over 100 items, executed locally, with the per-iteration results inspected via GetExecutionHistory. The whole loop happens on the laptop. No AWS bill. No clean-up.

Serverless REST API.
API Gateway plus Lambda plus DynamoDB, CRUD endpoints, end-to-end. The Power has a dedicated steering file for this pattern. Kiro scaffolds the project, writes the Lambda handlers, wires the API Gateway integrations, creates the DynamoDB table, and runs the end-to-end test against MiniStack. The whole thing takes minutes instead of the hour you'd burn on real AWS worrying about IAM roles and accidentally provisioning something you forgot to tear down.

Why this matters more than "Kiro got smarter"

What this combination removes from the loop is the interesting part.

When you're learning AWS, the cost of an experiment is friction. Spinning up a real account, creating a sandbox, watching for forgotten resources, dealing with permissions. Even if the dollar amount is small, the cognitive load isn't. A lot of people give up on learning new AWS services not because the services are hard, but because the friction of trying things is high.

When you're testing existing AWS code, the cost is reliability. If your CI pipeline depends on LocalStack's free tier (no longer free) or on shared sandbox accounts, you're at the mercy of something outside your control. MiniStack runs on the laptop. The Power makes it talk fluently with Kiro. The whole loop becomes a closed system you own.

That's the value. It's not "AI plus AWS." It's the removal of friction from both sides.

Some things to know

MiniStack is MIT licensed. The Power is MIT licensed. There's no upsell, no paid tier, no telemetry. It runs entirely on your machine.

You can use the Power without MiniStack. Kiro will still pick up the steering content and apply it. But the loop only closes when both are running.

The Power doesn't ship steering for every AWS service yet. It covers the 10 services we use daily plus the serverless-REST-API pattern. Pull requests welcome at github.com/ministackorg/ministack-power. If you want a service added, opening an issue is enough.

State persistence is opt-in. Set PERSIST_STATE=1 when you start MiniStack and it survives restarts. The Power knows about this and will mention it when you're building anything that needs durability across runs.

What's next

Two Power variants on the backlog:

1. A Terraform-first variant. Same steering, but every example is terraform apply against the local endpoint instead of boto3 or CLI. Useful for infra teams who think in HCL.
2. A CDK-first variant. Same idea, but using cdk synth and cdk deploy --endpoint-url. Useful for application teams who already use CDK.

If either sounds useful, open an issue on the repo so we know to prioritise it.

Try it

pip install ministack && ministack

Then install the Power in Kiro using https://github.com/ministackorg/ministack-power. Talk to Kiro about anything AWS. You'll feel the difference within a few prompts.

If something breaks, file an issue at github.com/ministackorg/ministack-power/issues. If something works well, tell people. That's how this stuff spreads.

Links:

• MiniStack: github.com/ministackorg/ministack
• The Power: github.com/ministackorg/ministack-power
• PyPI: pypi.org/project/ministack/
• Docker Hub: hub.docker.com/r/ministackorg/ministack