I have been experimenting with the Kiro IDE for quite a while now. Recently I've been using the new KiroCrew, AWS' answer to OpenClaw, Hermes, and other persistent local/cloud multi-agent meta harnesses.
I've been paying for it on my own while I experimented (as well as having some credits from being an AWS Community Builder and having had beta access). My experiments have made me feel comfortable enough with KiroCrew to start using it for stuff at work in my role as Chief Architect and Head of Platform Engineering. Most of my work is with AWS, so using KiroCrew with AWS is potentially a great combo. Though I must say KiroCrew, like all agent harnesses, is great for non-AWS and even non-technical projects.
So of course I wanted to switch the billing to my company's AWS account. This post is the story of that short journey and some of the minor bumps that I experienced. There are three non-obvious gotchas the docs skip. Hopefully this will help others to avoid those gotchas and get to enjoying KiroCrew sooner.
One meta note before the steps: I did not know most of these console paths or CLI flags going in. I worked them out by talking through the switch with KiroCrew itself, which is a fitting way to set up the tool you are setting up. I have called that out at the end for anyone curious how the sausage got made.
Assumptions
-
macOS or Linux. I did this on my MacBook Pro; the steps assume some form of
*nix. -
kiro-cli2.16.2, already working with my personal (Builder ID / social) login. - KiroCrew driving
kiro-clias its agentic backend (agent.provider: "acp"). If you run Kiro directly, the login logic is identical. - Access to your company's AWS IAM Identity Center: the org management account, or a delegated admin who can assign you a subscription.
The model: billing follows the login identity
A key fact: KiroCrew bills to whatever identity kiro-cli is logged in as. There is no per-request "charge this account" flag; billing follows the login. Because KiroCrew drives kiro-cli, its usage rides the same login.
So the task reduces to changing which identity kiro-cli uses. Two classes:
| Login | CLI --license
|
Billed to |
|---|---|---|
| AWS Builder ID / Google / GitHub | free |
personal (card on your Builder ID / kiro.dev account) |
| AWS IAM Identity Center (SSO) | pro |
the AWS account that owns your org's Kiro subscription |
Moving to company billing means switching from the first row to the second.
Gotcha #1: "free" does not mean unpaid
kiro-cli whoami reported a free license while I was on a paid personal plan:
Logged in with Builder ID
Email: me@personal.example
In kiro-cli, "license" refers to the identity-provider class, not the payment tier. From kiro-cli login --help:
--license <LICENSE>License type (pro for Identity Center, free for Builder ID, Google and Github)
A paid personal plan sits on top of the "free" (Builder ID / social) login class, so free describes how you authenticate, not what you pay.
Gotcha #2: the subscription may be filed under "Amazon Q Developer"
Before you can log in pro, an admin has to assign you a Kiro subscription in the org's IAM Identity Center. It lives once in the management account (or a delegated-admin account) and is assigned per user; it is identity-based, not per sub-account, so nothing needs configuring in individual workload accounts.
Which path you take depends on your org's history with AWS's AI dev tooling. The clean case first, then the Q Developer wrinkle that names this gotcha.
Clean Case: Creating a Kiro Subscription from scratch
If your org has never touched Amazon Q Developer, you create a Kiro subscription directly, with no migration involved.
One prerequisite before you start: do this from the org management account, or an account explicitly registered as a delegated administrator for IAM Identity Center. You will need enough administrator access to create subscriptions. If you run it from a plain member account, you will get an AccessDeniedException. You also need an IAM Identity Center instance in the account (organization instance recommended) with the users or groups you intend to subscribe.
1. Open the Kiro console and sign up. In the management account, switch to the Kiro console (search for kiro in the console search bar) and confirm you're in a supported Region. The profile and its user data are Region-scoped, so this is the one place a wrong Region bites you later. Choose Sign up for Kiro:
2. Pick your identity source. Kiro asks how you'll manage user identities. IAM Identity Center creates or syncs users through your IdC instance; External Identity Provider is for wiring in Okta / Entra directly. For the org-billing setup this post is about, choose IAM Identity Center and Next:
3. Enable Kiro. The Welcome to Kiro! dialog is the actual create step. Choosing Enable provisions the Kiro profile in this account (it also opts you into aggregated usage metrics, which you can disable later under Settings):
The profile is created. This is the object that ties your Identity Center users to their Kiro subscriptions and settings. You land on Users & Groups with an empty roster:
4. Subscribe your users or groups. Choose Add user (or the Groups tab → Add group). In general, it's best to use a group and give all the users in the group access to Kiro. It can be a group dedicated to this, or an existing group if that makes sense in your environment. Otherwise, if it's just for you, or your company is experimenting with it, you can set up individual users. You will then want to pick a price tier. If you do use groups, you would assign one tier to a group. You could have a group per tier if you want. The four plans and their monthly credit allotments:
| Tier | Price | Credits/mo |
|---|---|---|
| Kiro Pro | $20 | 1,000 |
| Kiro Pro+ | $40 | 2,000 |
| Kiro Pro Max | $100 | 5,000 |
| Kiro Power | $200 | 10,000 |
All paid plans support pay-per-use overage ($0.04/credit) if you enable it; prices exclude tax.
Choose the tier, Continue, then search for the Identity Center user or group and Assign. The subscription is live immediately, and the Dashboard's Total counter ticks up to 1.
If you already have an Amazon Q Developer subscription
This was my situation, and it adds a wrinkle: we'd enabled Q Developer months earlier. In our management account, IAM Identity Center → Applications already had a Kiro service profile (QDefaultProfile, created months earlier). But the Subscriptions page showed zero Kiro subscriptions. What existed was an Amazon Q Developer Pro subscription on a group, alongside an "Upgrade to Kiro" button:
The Kiro Dashboard confirmed the gap: Q Developer Pro existed, but Kiro subscriptions read Pending 0 / Active 0 / Total 0:
kiro-cli is the rebranded Amazon Q Developer CLI, so depending on your setup an existing Q Developer Pro entitlement may already cover the CLI. The way to confirm is to attempt the login and read the result.
Note on that button: "Upgrade to Kiro" is a product migration, not a model upgrade. It moves an entire group from Amazon Q Developer to Kiro. If teammates depend on Q Developer, it migrates them too, so check the group membership before clicking it. In my case I was the only group member, so the blast radius was zero. After clicking Upgrade to Kiro (and bumping the tier to Pro+), the same dashboard flipped to Total: 1:
Either way (fresh subscription or migrated from Q Developer), the end state is the same: a Kiro subscription bound to your Identity Center identity, which is what --license pro authenticates against below.
Doing the switch
Get your Identity Center start URL and region (the SSO portal you use for the console; also in ~/.aws/config under the [sso-session ...] block). Define them as shell variables first so the block pastes through without hand-editing:
start_url="https://<your-idc-start-url>.awsapps.com/start"
region="<your-idc-region>"
# 1. Drop the personal login
kiro-cli logout
# 2. Log in via Identity Center (routes billing to the company account)
kiro-cli login --license pro \
--identity-provider "${start_url}" \
--region "${region}"
# 3. Confirm
kiro-cli whoami
--license pro is required. It forces the AWS SSO device-authorization flow. Without it, the CLI defaults to Builder ID / social auth.
The device flow opens a browser. It presents a menu of sign-in methods rather than going straight to the org SSO page:
Choose Your organization, not Google or Builder ID, which returns you to personal billing. On the next screen, don't type your work email. Click "Sign in via IAM Identity Center instead" (arrowed below); that's the path that uses your org's start URL and routes billing to the company account:
That reaches the Identity Center prompt for Start URL and Region, pre-filled from the command-line flags:
Approve the access request:
The browser confirms authorization:
A successful whoami now shows Identity Center rather than Builder ID:
Logged in with IAM Identity Center (https://d-xxxxxxxxx.awsapps.com/start)
Profile:
QDefaultProfile
arn:aws:codewhisperer:<region>:<account-id>:profile/XXXXXXXXXX
If you drive Kiro through a long-running gateway (as KiroCrew does), restart it so it re-reads the token:
kirocrew restart
Gotcha #3: a tier change needs a re-login, not a restart
The first command after the switch failed:
❌ Your account does not have access to model '<newer-model>'.
Available to you: ...
The company tier was lower than my personal plan, so the model roster was smaller, as expected. I upgraded the tier (Pro → Pro+) in the console, but the new models still did not appear after a gateway restart.
The fix: log out and log back in (a variant of the old "turn it off and on again"). IAM Identity Center tokens cache entitlements at login time, so a subscription or tier change is not visible until you re-mint the token. A restart alone is insufficient:
start_url="https://<your-idc-start-url>.awsapps.com/start"
region="<your-idc-region>"
kiro-cli logout
kiro-cli login --license pro \
--identity-provider "${start_url}" \
--region "${region}"
kirocrew restart
After re-login, the upgraded model set was available.
Fallback
Switching to Identity Center does not cancel your personal subscription; it only changes the active identity.
- If company auth breaks,
kiro-cli login --license freereturns you to Builder ID / social. - Cancel the paid personal plan and that login still works on the free tier, a $0 fallback.
kiro-cli holds one active login at a time, and billing follows whichever is active. Switch to a personal login for a side project and that usage is on your card until you switch back.
How I actually figured this out
I did not walk into the AWS console knowing where any of this lived. The Kiro and Q Developer subscription pages are buried under Amazon Q Developer in the console, the kiro-cli login flags are barely documented, and the interactions between them (the naming, the caching) are exactly the parts the docs skip.
So instead of scouring the InterTubes, I worked the whole thing out in conversation with KiroCrew, the same agent this post is about. Setting up the agent by asking the agent is a little recursive, but in practice it just meant I described what I wanted, and it pointed me at the right screens and commands. KiroCrew also helped me put together this blog post, but it's my words and thoughts (I am one with KiroCrew 😅).
Three moments where that actually mattered map onto the three gotchas above. When I found the "Upgrade to Kiro" button, KiroCrew flagged that it was a group-wide product migration rather than a per-user model upgrade, and told me to check the group membership before clicking (I turned out to be the only member of the group, so the blast radius was zero).
On the org sign-in screen, it steered me away from typing my work email into the field and over to the Sign in via IAM Identity Center link, which is the path that actually routes billing to the company account.
And when the newer models still would not appear after I bumped the tier to Pro+, it diagnosed the entitlement caching and had me re-mint the token with a fresh login rather than chasing a restart that was never going to help. None of these are in a single doc. Having something that had read all of them and could reason across them is what turned an afternoon of trial and error into ten minutes.
Wrap up
Ten minutes of work, three gotchas, and Kiro (plus the KiroCrew agent) now bills to the company AWS org on the tier I want. The sharp edges are all naming and caching: "free" that is not unpaid, an "Upgrade to Kiro" button that is a group migration, and entitlements frozen at login time.
Next I want to look at attributing Kiro spend per team with cost-allocation tags, and at reusing the same IAM Identity Center login across the rest of the toolchain.
Top comments (0)