Kiro をエンタープライズで利用する場合、IAM Identity Center などを利用しユーザーやグループ単位で Kiro をサブスクライブする方法が一般的です。また、昨今では AWS Organizations を使ってマルチアカウントで AWS を利用するケースも一般的になってきています。今回 Kiro を IAM Identity Center を利用してサブスクライブするパターンをまとめる機会がありましたので、記録として残しておきたいと思います。

前提知識

はじめに、企業で Kiro を IAM Identity Center を利用して導入する場合に前提として知っておくと良い知識を整理しておきます。

Kiro プロファイル

Kiro を IAM Identity Center を利用して導入する場合、“Kiro プロファイル” というものを作ります。

ドキュメントに定義はあるのですが、"管理設定" と ”サブスクリプション" を管理する概念で、リージョンあたり、AWS アカウントあたり 1つのプロファイルを作成することができます。言い換えると 1つの AWS アカウント内に同じリージョンの Kiro プロファイルは複数作成することはできません。

  • “管理設定” はプロンプトのロギングや、クレジット上限に達した場合の超過使用許可などの設定を指します。詳細はドキュメントを参照ください。
  • “サブスクリプション” は Kiro を利用するユーザーを単位とした登録になります。その際、プランレベルとして Pro、Pro+、Power をユーザーもしくはグループ単位で指定します。

図にするほどでないですが以下のイメージになります。

Kiro Profile

IAM Identity Center の “組織インスタンス” と “アカウントインスタンス”

AWS Organizations の管理アカウントに作成される IAM Identity Center を “組織インスタンス“の IAM Identity Center と呼び、IAM Identity Center の全ての機能をサポートしています。

一方、単一のアカウント、リージョン内でのみ利用できる、組織に紐付かない “アカウントインスタンス” の IAM Identity Center というものも存在します。アカウントインスタンスの IAM Identity Center は全ての機能がサポートされておらず、代表的な違いとしてアカウントインスタンスは AWS (マネジメントコンソール) へのログイン、クレデンシャル発行には利用できません。このアカウントインスタンスの主な用途としては “AWS マネージドアプリケーション” へのシングルサインオンや OAuth 2.0、OIDC によるアプリケーションへのシングルサインオンなどになり、今回のケースでは Kiro が “AWS マネージドアプリケーション” に該当します。

このアカウントインスタンスの IAM Identity Center を作成できるのは AWS Organizations の管理アカウント以外のアカウント (すなわちメンバーアカウント)か、Organizations で管理されていないスタンドアロンのアカウントになります。

組織インスタンスとアカウントインスタンスの機能差の詳細についてはドキュメントを参照ください。

IAM Identity Center を使用した Kiro の利用パターンは 4つ

前提知識を得たところで利用方法パターンについてみていきたいと思います。と言いつつ、いきなり Amazon Q Developer のドキュメントになってしまいますが、IAM Identity Center を利用したデプロイパターンは 4つ示されています。

Kiro においてもこれに倣うことができ、以下のようになります。1.がスタンドアロンアカウント (シングルアカウント) 構成、2 - 4. が AWS Organizations を利用したマルチアカウント構成のパターンになります。

これらを順番にもう少し詳細に見ていきます。

パターン1. スタンドアロンアカウントで IAM Identity Center を作成し、Kiro プロファイルを作成

AWS Organizations を構成せず、スタンドアロンアカウントで小規模に利用しているケースです。図にすると以下のようになります。

Pattern 1: Onboarding on a standalone account

Kiro を利用開始するまでの大まかな流れは以下のようになります。

前提 : 準備として IAM Identity Center を作成しておきます。AWS Organizations を構成する必要はありません。ただしこの場合の IAM Identity Center はアカウントインスタンスとなり、AWS のマネジメントコンソールへのログインなどには利用できません。

手順 :

  1. マネジメントコンソールの Kiro (https://console.aws.amazon.com/amazonq/developer/home) から “Kiro にサインアップ” します。これによりこのアカウントで Kiro プロファイルが作成され、IAM Identity Center の “アプリケーション” に Kiro プロファイルが登録されます
  2. Kiro を利用するユーザーもしくはグループをサブスクリプションとして追加します (予め IAM Identity Center にユーザーやグループは作成しておきます)
  3. Kiro を利用するユーザーは Kiro IDE もしくは CLI から IAM Identity Center の “AWS access portal URL” (IPv4 の方) (https://xxx.awsapps.com/start) を使ってサインインします

パターン1の特徴・注意点など

特徴

  • AWS Organizations の構成をとっていないスタンドアロンアカウントで IAM Identity Center を使った Kiro をサブスクライブする唯一の方法 (Organizations をすでに構成している場合は選択できないパターンでもある)

ユースケース

  • 小規模な AWS アカウントの利用で、Organizations への移行も計画されていない場合

注意点

  • 作成される IAM Identity Center はアカウントインスタンスとなるが、将来 Organizations に移行した際、組織インスタンスの IAM Identity Center に移行はできないため、将来 Organizations に移行する予定がある場合は、先に Organizations を構成することも検討した方が良い

パターン2. 管理アカウントの IAM Identity Center を利用し、メンバーアカウントで Kiro プロファイルを作成

ここからは AWS Organizations によるマルチアカウント構成になります。

管理アカウントの IAM Identity Center、すなわち組織インスタンスの IAM Identity Center を利用し、Kiro のサインアップ、プロファイル作成をメンバーアカウントから実行するパターンになります。

図にすると以下のようになります。

Pattern 2: Onboarding on a member account with Organizations instance

Kiro を利用開始するまでの大まかな流れは以下のようになります。

前提 : AWS Organizations、組織インスタンスの IAM Identity Center はすでに構築済みであるとします

手順 :

  1. メンバーアカウントのマネジメントコンソールから Kiro を開き、“Kiro にサインアップ” します。これによりこのメンバーアカウントで Kiro プロファイルが作成され、組織インスタンスの IAM Identity Center の “アプリケーション” に Kiro プロファイルが登録されます
    • この組織インスタンスの “アプリケーション” に登録される Kiro プロファイルの個数には制限があります (後述)
  2. Kiro を利用するユーザーもしくはグループをサブスクリプションとして追加します。ユーザーやグループが組織インスタンスの IAM Identity Center に存在している必要があります
  3. Kiro を利用するユーザーは Kiro IDE もしくは CLI から IAM Identity Center の “AWS access portal URL” (IPv4 の方) (https://xxx.awsapps.com/start) を使ってサインインします

パターン2の特徴・注意点など

特徴

  • Kiro サブスクリプションの管理 (ユーザーやグループの登録、解除) がメンバーアカウント側でコントロールできる
  • Kiro サブスクリプションの費用はメンバーアカウント側に計上される (請求・支払いはもちろん管理アカウント (支払いアカウント))

ユースケース

  • プロジェクトや部署ごとにサブスクリプション費用を明確に按分したい場合
  • Kiro プロファイルごとにプロンプトロギングなどの管理設定をカスタマイズすることができるため、ポリシーを分けたいケースがあれば Kiro プロファイルを分けるのが良い (例: 部署ごとに Kiro プロファイル用のアカウントを作るなど)

Kiro profile each department

注意点

  • 組織インスタンスの IAM Identity Center に登録できる Kiro プロファイル数に制限があり、Organizations あたり、リージョンあたりの上限値が設定されている (詳細は後述)
  • 複数の Kiro プロファイルに同一ユーザーがサブスクライブするとそれぞれのアカウントの Kiro プロファイルで課金が発生するので重複サブスクリプションに注意 (重複課金となるケースについてのドキュメント)

大規模な組織などではプロジェクトごとに予算が割り当てられ、AWS の利用料もプロジェクトごとに費用配賦されるケースが多いかと思います。実際の支払いは管理アカウント (支払いアカウント) ではあるのですが、その費用をメンバーアカウントを所有する各プロジェクトに配賦する必要がある場合、Kiro のサブスクリプション費用が最初からメンバーアカウント側に計上されているので手続き等が楽になる利点があります。

パターン3. メンバーアカウントでアカウントインスタンスの IAM Identity Center を作成し、Kiro プロファイルを作成

パターン2 と同様に、AWS Organizations によるマルチアカウント構成ですが、IAM Identity Center はメンバーアカウントで作成したもの、すなわちアカウントインスタンスの IAM Identity Center を利用し、メンバーアカウントで Kiro のサインアップ、プロファイル作成をする方式になります。

図にすると以下のようになります。

Pattern 3: Onboarding on a member account with an account instance

前提 : メンバーアカウントでアカウントインスタンスの IAM Identity Center を作成します

  • 2023年 11月 15日以前に組織インスタンスの IAM Identity Center を有効にしている場合、メンバーアカウントがアカウントインスタンスを作成できるように有効化する必要があります。詳細はドキュメントを参照してください。

手順 :

  1. メンバーアカウントのマネジメントコンソールから Kiro を開き、“Kiro にサインアップ” します。これによりこのメンバーアカウントで Kiro プロファイルが作成され、アカウントインスタンスの IAM Identity Center の “アプリケーション” に Kiro プロファイルが登録されます
    • 有効化時のユーザーが組織インスタンス、アカウントインスタンス両方に登録されている場合、以下のようにどちらを利用するか確認が入ります。メールアドレスが同じだと見分けがつかないですが、2枚目のように “この AWS アカウントの Kiro にのみサインインできます” の方を選択すると、アカウントインスタンスに Kiro プロファイルが登録されます
      Select an account instance
  2. Kiro を利用するユーザーもしくはグループをサブスクリプションとして追加します。ユーザーやグループがアカウントインスタンスの IAM Identity Center に存在している必要があります
  3. Kiro を利用するユーザーは Kiro IDE もしくは CLI から IAM Identity Center の “AWS access portal URL” (IPv4 の方) (https://yyy.awsapps.com/start) を使ってサインインします

パターン3の特徴・注意点など

特徴

  • 一連の作業はメンバーアカウントで完結する (IAM Identity Center の作成権限などがメンバーアカウントに付与されている場合)
  • Kiro サブスクリプションの管理 (ユーザーやグループの登録、解除) がメンバーアカウント側でコントロールできる
  • Kiro サブスクリプションの費用はメンバーアカウント側に計上される (請求・支払いはもちろん管理アカウント (支払いアカウント))
  • パターン2 であった組織インスタンス IAM Identity Center の Kiro プロファイル数の制限を回避できる

ユースケース

  • プロジェクトや部署ごとにサブスクリプション費用を明確に按分したい場合
  • パターン2 同様、Kiro プロファイルごとにプロンプトロギングなどの管理設定をカスタマイズすることができるため、部署ごと、プロジェクトごとなどポリシーを分けたいケースで有効
  • パターン2 の Kiro プロファイル数の制限を回避できるので、より細かくポリシーを分けたり、費用按分をする必要がある場合はパターン3 の方が良さそう

注意点

  • ユーザーやグループを “組織インスタンス” と “アカウントインスタンス” の両方の IAM Identity Center で管理することになる
  • 複数の Kiro プロファイルに同一ユーザーがサブスクライブするとそれぞれのアカウントの Kiro プロファイルで課金が発生するので重複サブスクリプションに注意 (重複課金となるケースについてのドキュメント)
  • 利用者目線では AWS を利用する時の認証情報と Kiro にサインインする時の認証情報が異なるものになる
    • 認証情報: IAM Identity Center の URL およびユーザー ID などです (ユーザー ID やパスワードは同じものを設定できますが同期はできません。MFA はそれぞれ別のものを設定することになります)

パターン4. 管理アカウントの IAM Identity Center を利用し、管理アカウントで Kiro プロファイルを作成

パターン2, 3 と同様に AWS Organizations によるマルチアカウント構成で、IAM Identity Center は管理アカウントのを利用します。また、Kiro のサインアップ、Kiro プロファイル作成も管理アカウントで行います。管理アカウントで Kiro プロファイルが作成済みであればそれを利用することになります (1つのアカウントで同じリージョンの Kiro プロファイルを組織インスタンスの IAM Identity Center に複数登録することはできません)。

図にすると以下のようになります。

Pattern 4: Onboarding on an admin account with an Organizations instance

前提 : AWS Organizations、組織インスタンスの IAM Identity Center はすでに構築済みであるとします

手順 :

  1. 管理アカウントのマネジメントコンソールから Kiro を開き、“Kiro にサインアップ” します。これにより管理アカウントで Kiro プロファイルが作成され、組織インスタンスの IAM Identity Center の “アプリケーション” に Kiro プロファイルが登録されます
    • Kiro プロファイルがすでに作成済みである場合はこの手順はスキップします
  2. Kiro を利用するユーザーもしくはグループをサブスクリプションとして追加します。ユーザーやグループが組織インスタンスの IAM Identity Center に存在している必要があります
  3. Kiro を利用するユーザーは Kiro IDE もしくは CLI から IAM Identity Center の “AWS access portal URL” (IPv4 の方) (https://xxx.awsapps.com/start) を使ってサインインします

パターン4の特徴・注意点など

特徴

  • 一連のセットアップは管理アカウントで完結する
  • Kiro サブスクリプションの管理 (ユーザーやグループの登録、解除) は管理アカウント側で行う
  • Kiro サブスクリプションの費用は全て管理アカウント側に計上される
  • Kiro プロファイルは 1つしかないため、パターン2 であった組織インスタンス IAM Identity Center の Kiro プロファイル数の制限を回避できる

ユースケース

  • プロジェクトや部署ごとにサブスクリプション費用を按分する必要がない場合
  • Kiro サブスクリプションを管理アカウント側でコントロールしたい場合
  • プロンプトロギングなどの管理設定を一律全員に適用させたい場合 (ガバナンスを効かせたい場合)

注意点

  • ガバナンスのためこのパターン4を採用する場合は、“メンバーアカウントでアカウントインスタンスを作成できないようにしておく” か、もしくは “Kiro プロファイルを作成できないようにしておく” 必要がある
    • アカウントインスタンスの作成を防止するにはドキュメントにある通り SCP を利用する
      • メンバーアカウントによるアカウントインスタンスの作成の可否は IAM Identity Center を有効にした時期によって異なり、ドキュメントによると…
        • 2023 年 11 月より前 – メンバーアカウントでアカウントインスタンスの作成を許可する必要があります。これは元に戻すことができないアクションです。
        • 2023 年 11 月 15 日以降 – メンバーアカウントは、デフォルトでアカウントインスタンスを作成できます。
    • Kiro プロファイルの作成を防止する方法は後述

サブスクリプションの重複について

複数の Kiro プロファイルが作成されている場合、課金が重複しないように注意が必要です。ドキュメントでは 2つのケースについて紹介されています。

1.同じ Kiro プロファイル内でグループにより 2回サブスクリプションに登録されている場合

このパターンでは重複課金になりません。ユーザがサブスクライブしている最も高いプランの料金だけがかかります。以下の図の例だと Pro+ プランの料金が適用されます。

Duplicate charge not applied

2.異なる Kiro プロファイルに同一のユーザがそれぞれサブスクリプションに登録されている場合

このケースでは Kiro プロファイルがどの IAM Identity Center に登録されていたとしても重複課金されてしまいます。それぞれのアカウントで Kiro サブスクリプション費用が発生してしまうのでご注意ください。

Duplicate charge applied

組織インスタンスのアプリケーションに作成される Kiro プロファイル数の制限について

各メンバーアカウントから Kiro を有効化すると、組織インスタンスの IAM Identity Center の “アプリケーション” に、所有者がメンバーアカウントである Kiro プロファイルが登録されます。

Q Developer のドキュメントですが確認した範囲では Kiro にも適用されるようで、Kiro プロファイルの数には制限があり、Organizations あたり、リージョンあたりの上限値が 10 に設定されています。

1つの組織インスタンス内に登録できる Kiro プロファイルは 1リージョンあたり、1アカウントあたり 1つになります。ですので Organizations の中でリージョンあたり、10アカウントだけ Kiro プロファイルを作成することができる、ということになります。

現状、いくつ Kiro プロファイルが登録されているかは、管理アカウントの IAM Identity Center の “アプリケーション” から “AWS 管理アプリケーション” で以下のように確認できます (以下は 2つのアカウントで Kiro プロファイルが登録されている、ということになります)。

Kiro profile list in IAM Identity Center applications

AWS CLI だと管理アカウントのプロファイルで aws sso-admin list-applications を実行することで確認できます。

INSTANCE_ARN=arn:aws:sso:::instance/ssoins-xxx

aws sso-admin list-applications \
  --instance-arn ${INSTANCE_ARN} \
  --query 'Applications[?Name != null && starts_with(Name,`KiroProfile`)].{Name:Name, ApplicationAccount:ApplicationAccount}' \
  --output table

実行結果 (例):

-------------------------------------------------
|               ListApplications                |
+---------------------+-------------------------+
| ApplicationAccount  |          Name           |
+---------------------+-------------------------+
|  666666666666       |  KiroProfile-us-east-1  |
|  444444444444       |  KiroProfile-us-east-1  |
+---------------------+-------------------------+

メンバーアカウントによる Kiro Profile の作成を拒否する方法

メンバーアカウントで AdministratorAccess 相当の権限があると Kiro プロファイルを作成し、組織インスタンスの IAM Identity Center に Kiro プロファイルをアプリケーションとして登録できてしまいます。大きな組織ではすぐに Kiro プロファイル数の上限に達してしまう可能性があるのでプロファイル作成を制御したいケースがあるかもしれません。その場合は、Organizations の SCP (Service Control Policy) で制御することができます。(※ AWS 公式にガイドされている方法ではないので検証の上、自己責任で適用ください🙇‍♂️)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [ "codewhisperer:CreateProfile" ],
      "Resource": [ "*" ]
    }
  ]
}

このポリシーが適用されている場合、メンバーアカウントで Kiro をサインアップしようとすると以下のエラーダイアログが表示され、Kiro プロファイルの作成ができなくなります。

Deny creating a Kiro profile

Kiro に関する IAM Identity Center での設定等について

IAM Identity Center を利用して Kiro を利用する際に、設定しておくと良さそうなものを簡単に紹介しておきます。

Kiro の開発者セッションタイムアウトの延長

IAM Identity Center に設定されているセッションについて、開発中に頻繁に再認証が要求されると開発体験を大きく損なってしまいます。そこで、Kiro のセッションだけ再認証が必要になる期間を 90日に延長することができます (ドキュメント)。

IAM Identity Center の “設定” から “管理” タブを選択し、“セッション期間” のセクションで変更できます。

Extended sessions for Kiro

ID 強化セッションの有効化

Kiro IDE や CLI を利用する上では必須ではないですが、マネジメントコンソールなど、一部の AWS マネージドアプリケーションでユーザの情報を連携することでパーソナライズされた体験を提供できるようになります (ドキュメント)。組織インスタンスでのみ構成可能です。

Enabling identity-enhanced console sessions

まとめ

IAM Identity Center を利用してチームで Kiro を利用する場合のパターンについてまとめてみました。企業の規模や、ガバナンス、サブスクリプション費用の按分要否などによって採用するパターンが変わってくるかと思いますので、本記事が参考になれば幸いです。

最後に・・・

この投稿は個人的なものであり、所属組織を代表するものではありません。ご了承ください。