AWS Builder Center

Builder Center

Understanding and playing with Kiro Crew

Getting started coming from a Hermes on Discord. This article explores a Kiro Crew quickstart for private instances, the components with in and the cost implications.

Series: Kiro Crew (1 article)

  1. 1
    Understanding and playing with Kiro Crew This article

Vincent De Smet

What is Kiro Crew
One gateway with several entry points. Either integrate it into your favorite messaging platform (Slack/Discord/...) or use the very capable web dashboard or cli.
Kiro Crew is first and foremost a framework that lets you run multi-step tasks unattended, set up scheduled cron jobs and it comes bundled with a powerful memory system and plenty more features I had to manually find and set up for my Hermes Agent.
First, some terminology:
  • Backend: Python package  kiro_crew , gateway binds on loopback
  • Frontend: React+TS+Vite SPA, backend serves the bundle
  • Data:  ~/.kiro/crew  by default
  • Model Access: leverages Agent Client Protocol (ACP), currently with  KiroACP  as the main provider. This is the area I will explore most in my follow up posts.
channels (slack,discord) / dashboard / Agents / MCP tools all interact via the kiro_crew Gateway


Components

MacOS App

An Electron shell that bundles internal python backend. This provides a very easy way to run the gateway, no terminal required. Through this local gateway you also get the capability to connect to remote gateway dashboards:
Remote crew configuration screen showing a VM connection

This is where it gets exciting, under the hood the capability is simple: manage a tunnel (either over  ssh  or  ssm  (reverse tunnel via AWS Session Manager).

The CLI

 kirocrew  CLI allows you to control your gateways, it offers  doctor  and  token  commands as well as the cloud launcher.
 kirocrew cloud  launch (provision and configure a remote instance), as well as manage (list, status, connect, ...)
kirocrew cloud -h
usage: kirocrew cloud [-h] {launch,list,status,connect,tunnel,login,stop,start,destroy,iam-policy,iam-boundary,doctor} ...

positional arguments:
  {launch,list,status,connect,tunnel,login,stop,start,destroy,iam-policy,iam-boundary,doctor}
    launch              Provision + configure an instance
    list                List your Kiro Crew cloud instances
    status              Show one instance's state
    connect             Open the dashboard over an SSM tunnel
    tunnel              Open the dashboard SSM tunnel (standalone; alias of connect)
    ...
    start               Start a stopped instance
    destroy             Remove the instance and ALL its AWS resources
    iam-policy          Print the least-privilege IAM policy to apply
    ...
    doctor              Check cloud prerequisites + AWS reachability

options:
  -h, --help            show this help message and exit

Examples:
  kirocrew cloud launch                  # interactive: provision + configure + open dashboard
  kirocrew cloud launch --size power     # non-interactive size
  kirocrew cloud launch --new            # create a separate new instance
  kirocrew cloud list                    # list your cloud instances

Cloud considerations

Running a cloud instance without inbound SSH, no public IP, no key-pair to manage
See:  guide SSH vs SSM 
Note: requirements to run a private remote crew -
  • provision VPC with public and private subnets (this requires a NAT solution).
  • Use the Private-Subnet deploy via the  --subnet  flag
  • Access control is IAM ( ssm:StartSession ) - centrally revocable and cloudtrail-audited!
This sets the scene for a security first approach towards agentic workloads. The default posture is a box with zero inbound ports. This differentiates Kiro Crew from hobby-tier deployments!
I provide a sample IaC for the full solution I built out below:  so0k/kirocrew-network 

Caveat: Cost

Currently, the cloud sizes available at the time of writing are as below (with an illustrative on-demand  approx_usd_per_hr  indicator):
Tier
Instance
vCPU
RAM
Disk
~$/hr
Light
 t4g.large 
2
8 GB
30 GB
0.067
Balanced (default)
 t4g.xlarge 
4
16 GB
40 GB
0.134
Power
 m7g.2xlarge 
8
32 GB
60 GB
0.326
Balanced (x86)
 t3.xlarge 
4
16 GB
40 GB
0.166
Power (x86)
 m7i.2xlarge 
8
32 GB
60 GB
0.403
that table is compute only! For the true secure posture be mindful of overhead costs (fine if the infrastructure exists, important to take note if this is your hobby playground!

My observations ( ap-southeast-1 )

Item
Rate
Monthly
NAT gateway (hourly)
$0.059/hr × 730h
~$43.07
NAT data processing
$0.059/GB
$0 while stopped
Public IPv4 (the NAT's EIP)
$0.005/hr × 730h
~$3.65
EBS 40 GB gp3 (baseline 3000 IOPS — no surcharge)
$0.096/GB-mo
~$3.84
EventBridge rules, Lambda (1 no-op invoke/day), SSM, CloudFormation
free tier
~$0
S3 launcher bundle + CloudWatch logs
a few MB
~$0.01
Total with the instance stopped: ≈ $50–51/month.
~85% of that is the NAT gateway. A stopped instance costs nothing (its auto-assigned public IP is released on stop), but the NAT bills regardless.
Running  t4g.xlarge  on top: ~$97/mo at 24/7, or ~$65/mo on an 08:00–01:00 SGT schedule (no overnight work).

Controlling costs with scheduled scaling

My first attempt to control costs was to set up scheduled scaling, but counterintuitively the savings weren't that amazing:
State
~Monthly
24/7
~$147
EventBridge schedule (08:00–01:00 SGT)
~$115
Instance stopped, VPC intact
~$50
Network stack destroyed, EBS kept
~$4
Everything destroyed — what I actually did, 2026-08-07
$0
The EventBridge  ScaleUpMorning  /  ScaleDownNightly  rules save ~$32/mo
but the NAT gateway is a floor the scheduler cannot touch. Turning the agent off at night attacks the smaller cost.
Region is an another option, here is its impact compared to the scheduler:  us-east-1  NAT is ~$33/mo vs  ap-southeast-1 's ~$43/mo
Roughly a third of what the whole nightly schedule saves, for a one-line change and some latency
We will explore self-hosted options in Part 2!

Part 1: IaC Repository

 so0k/kirocrew-network  - this repository provides:
  1. Single AZ VPC: The NAT and instance share the AZ (there's no failover and replication in this set up, and that makes sense). This saves costs not only on compute but also on cross-AZ data costs.
  1. ARM/Graviton: The default lane, and  t4g  is burstable, cheap at idle, bursts for tool calls. Kiro Crew Cloud  --size  set to  power  switches this over to  m7g  for sustained load.
  1. The scheduler: Terraform IaC (but generated via  cdktn.io  and  terraconstructs.dev  - the code is currently  ScaleUpMorning: false  - as my next blog post lays out what I switched to

Conclusion

The  kirocrew  CLI gives us a great first user experience, fast to get started and evaluate it. This allowed me to move forward and plan how this will replace my Hermes VM. The biggest first impressions were:
  • Kiro Crew is a security first approach to Agents
  • Kiro Crew packs a bunch of features built-in (auto-mode with local LLM, whispr voice, local embedding model for semantic knowledge graph, session management, Artifacts, ... lots to unpack).
In my next blog post I will first dive deeper in my existing Hermes VM set up and how Kiro Crew is replacing it.
Cleaning up
There's an option to easily export your remote crew. In my case, I had nothing to export so I simply ran  kirocrew cloud destroy  followed by  tofu destroy  and nothing was left behind, no surprise bills for me!
Kiro Crew Screenshot showing an Artifact created in a chat session

# kiro# terraform# getting-started

Series: Kiro Crew (1 article)

  1. 1
    Understanding and playing with Kiro Crew This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article