みなさん、こんにちは。
AWS CLI が好きなテクニカルサポート課の市野です。
IAM Identity Center において新たにアカウントインスタンスの提供が開始されていますが、その違いと、お客様からのお問い合わせを受けて認識した注意点についてまとめました。
私にしては珍しく GUI 多めです。
先に結論
- IAM Identity Center のアカウントインスタンスは、「AWS Organizations のメンバーアカウント」か「AWS Organizations 組織に組み込まれていない単独（スタンドアロン）のアカウント」でのみ作成が可能。
- IAM Identity Center のアカウントインスタンスを持っている状態の AWS Organizations 組織のメンバーアカウントに対し、AWS Organizations 管理アカウントから組織のインスタンスの権限委任を行った場合、委任を受けたメンバーアカウント側で複数の SSO インスタンスを認識することとなり、結果的に元から存在していたアカウントインスタンス側しか操作できない状況に陥る。
- マルチアカウント構成で、AWS Organizations 組織の管理アカウントを直接操作させず、権限委任を利用しメンバーアカウントごとに機能を割り振ることは、管理上考えられるかと思います。
- そのため、マネージドサービスの利用のために IAM Identity Center の試用目的で一時的にアカウントインスタンスを利用し、本採用時に AWS Organizations での IAM Identity Center を有効化し、かつ、メンバーアカウントに権限委任を行う運用を考える場合、メンバーアカウント側にアカウントインスタンスが存在するかのチェックと、あれば削除する考慮が必要と考えられる。
アカウントインスタンス とは？
従来、IAM Identity Center（旧 AWS SSO） の利用には、AWS Organizations の利用が必要であり、単一のアカウントだけ利用する環境でも AWS Organizations を利用する必要がありました。
昨年、2023年11月17日 の公式発表で、単一のアカウントにのみ適用可能な「アカウントインスタンス」の提供が開始され、東京リージョンを含む全てのリージョンで利用ができるようになりました。
公式発表
考えられる利用用途は？
前述の What's New のポストの表題が「evaluation and adoption of AWS managed applications」となっていることからもわかる通り、IAM Identity Center の利用が前提となっている AWS のマネージドサービスの評価のために、AWS Organizations 組織の SSO インスタンスの作成を行うことなく、マネージドサービスを利用してみたい、といった主に検証用途が考えられます。
公式ページ で記載されている想定ユースケースは以下のとおりです。
- You want to run a temporary trial of a supported AWS managed application to determine if the application suits your business needs.
- You don’t have plans to adopt IAM Identity Center across your organization, but you want to support one or more AWS managed applications.
- You have an organization instance of IAM Identity Center, but you want to deploy a supported AWS managed application to an isolated set of users that are distinct from users in your organization instance.
（当方での和訳）
- サポートされている AWS 管理アプリケーションの一時トライアルを実行して、アプリケーションがビジネス ニーズに適合するかどうかを判断したいケース
- 組織全体に IAM Identity Center を導入する計画がないが、1 つ以上の AWS 管理アプリケーションをサポートしたいケース
- IAM Identity Center の組織インスタンスがすでにあるが、サポートされている AWS マネージド アプリケーションを、組織インスタンス内のユーザーとは異なる分離されたユーザーのセットにデプロイしたいケース
現時点で対応可能な AWS マネージドサービス（執筆時 2024-03-07 時点）
公式ドキュメント Supported AWS managed applications では以下のサービスで利用可能となっています。
- Amazon Athena
- Amazon CodeCatalyst
- Amazon EMR
- AWS Lake Formation
- Amazon Redshift
分岐点
IAM Identity Center の有効化を行う際に、「有効にする」ボタンをクリック後、「AWS Organizations で有効にするのか」、「このアカウントのみで有効にするのか」の選択を行えるようになります。
（なお、AWS Organizations の管理アカウント側では冒頭述べた通りアカウントインスタンスの作成ができないため、本画面の表示はされないことを確認しています。）
2ステップ目の画面からも推察できるように、あくまでも推奨は AWS Organizations での有効化であることを汲み取ることができます。
また、AWS Organizations で有効を選択して進んだ場合は、 AWS Organizations の有効化（組織の作成）と、IAM Identity Center の有効化が一気に行われることを確認しています。
| # | ステップ・画面表示 |
|---|---|
| 1 |  |
| 2 |  |
わかりにくかった点
以下の＜３＞で示す状況となった場合に、アカウント B 側からは 組織の SSO インスタンスにつながっているように見えている のに、実際はアカウントインスタンスにつながっていて、組織の IAM Identity Center であれば使える機能を利用した際に「The operation is not supported for this Identity Center instance」といったようなエラーが発生する、といった状況に遭遇しました。
| # | ステップ・画面表示 |
|---|---|
| 1 | IAM Identity Center のアカウントインスタンスが存在する状況。  |
| 2 | １の状態のまま、アカウント A を管理アカウントとする AWS Organizations のメンバーアカウントとなる。 あるいは AWS Organizations のメンバーアカウントである状態で IAM Identity Center のアカウントインスタンスを作成する、という操作でも同義。  |
| 3 | ２の状態であるときに、アカウント A で、AWS Organizations での IAM Identity Center 有効化をしアカウントB に権限委任する。 要するに、組織のインスタンスと、アカウントインスタンスの両方がある状態となる。  |
状況の再現
| # | ステップ・画面表示 |
|---|---|
| 1 | アカウント B で IAM Identity Center へアクセスし「有効にする」をクリックする。 |
| 2 | 「有効にする IAM Identity Center」ポップアップ画面で「この AWS アカウントでのみ有効にする」を選択し、「続行」ボタンをクリックする。 |
| 3 | タグの設定は任意で。 検証では付与せず、「有効にする」ボタンをクリックする。  |
| 4 | 有効化が実行され、しばしの待ち時間。 |
| 5 | 「IAM Identity Center ${SSO_ACCOUNT_INSTANCE_ID} のアカウントインスタンスが正常に作成されました。」の表示が出ていることを確認し、IAM Identity Center アカウントインスタンスが作成されたことを確認します。 |
| 6 | 「設定」メニューへ遷移し、インスタンス ID が ＜5＞で表示されていた SSO インスタンスの ID を持つアカウントインスタンスが作成されたことを確認します。 また、組織 ID 欄が「AWS Organizations が有効になっていません」という表示であることを確認しました。  |
| 7 | 管理アカウントであるアカウント A へログインし直し、AWS Organizations 管理画面へ移動し、「AWS アカウントを追加」ボタンをクリックします。 |
| 8 | 「AWS アカウントを追加」画面で招待する AWS アカウント（アカウント B）の アカウント ID を入力し、「招待を送信」ボタンをクリックします。 |
| 9 | 目的の AWS アカウントを正しく招待できていることを確認します。 |
| 10 | アカウント B へログインし直し、AWS Organizations 画面へ移動します。 「１件の招待の表示」ボタンが表示されており、招待を受けていることを確認します。  |
| 11 | 内容を確認し、「招待を承認する」ボタンをクリックします。 |
| 12 | 正しく処理が行われ、「〜招待を承諾しました。」表示が出ていることを確認します。 |
| 13 | 管理アカウント（アカウント A）へログインし直し、AWS Organizations / AWS アカウント画面で、組織構造に目的の AWS アカウントが追加されていることを確認します。 |
| 14 | 引き続き管理アカウント（アカウント A）で IAM Identity Center へ移動し、遷移後の画面で「有効にする」ボタンをクリックします。 |
| 15 | 正常に処理が完了し ${SSO_ACCOUNT_INSTANCE_ID} の組織インスタンスが正常に作成されました。と表示されることを確認します。 |
| 16 | 「設定」メニューへ移動し「管理」タブを選択し「アカウントを登録」ボタンをクリックします。 |
| 17 | アカウント B を選択し「アカウントを登録」ボタンをクリックします。 |
| 18 | 正常に処理が完了し、メンバーアカウント アカウント B のアカウント名 は IAM Identity Center の委任された管理者として正常に登録されました。の表示がされることを確認します。 |
発生した事象
| # | ステップ・画面表示 |
|---|---|
| 1 | アカウント B で IAM Identity Center へアクセスします。 ダッシュボード画面で「同じリージョンで 2 個の IAM Identity Center インスタンスが検出され」たので、「組織インスタンス に自動的にログイン」したと認識できる注釈部分が表示がされていることが確認できます。 ただし、左サイドナビ部分の「インスタンスの管理」部分に記載されている SSO インスタンスの ID が、上記注釈部分にもある「アカウントインスタンス」の ID となっていることがわかります。  |
| 2 | この状態で、組織のインスタンスで行える「マルチアカウント許可」の配下の画面を操作すると「 The operation is not supported for this Identity Center instance 」というアラート表示がされていることが確認できます。 |
| 3 | AWS CLI sso-admin list-instances サブコマンドで確認すると、複数の SSO インスタンスの情報が返却されることが確認できます。なお、返却される値からは、「組織のインスタンス」であるのか「アカウントインスタンス」であるのかを区別する出力はなく、 OwnerAccountId から判断するより他ない状況です。 |
発生原因
実際の挙動を見るまで AWS 公式ドキュメントの内容を正しく理解できていなかったところがありますが、「アカウントインスタンスに関する考慮事項」として、以下のように記載があります。
アカウントインスタンスを組織インスタンスに変換することはできません。
アカウントインスタンスを組織インスタンスにマージすることはできません。
〜中略〜
IAM アイデンティティセンターのインスタンスをオプトインリージョン (デフォルトでは無効の AWS リージョン) の組織にデプロイした場合、組織インスタンスを作成すると、アカウントインスタンスの作成はブロックされます。既存のアカウントインスタンスは引き続き機能します。
アカウントインスタンスは、組織インスタンスに変換されることはなく、マージされることもない ＝ それぞれは別の存在である。
これは、前述までの確認で見ていた通り、複数の SSO インスタンスとして認識できていることからドキュメントの通り受け取れます。
考慮事項の最後の項目の読解が正しくできていなかった部分がありますが、組織インスタンスを作成すると、アカウントインスタンスの作成はブロックされるとあるものの、既存のアカウントインスタンスは引き続き機能するとあるため、今回の状況の再現の手順のように、先にアカウントインスタンスがある状況であれば、引き続き機能し続ける（組織のインスタンスに接続されているように見えるが、引き続きアカウントインスタンスに接続される）状況となると理解しました。
修正方法
この状態に陥った場合、検証の結果、以下いずれかの方法を取り、アカウントインスタンスを削除することで、正しく組織のインスタンスを操作できる状態へ是正できることを確認できています。
- 組織の IAM Identity Center の権限委任を一度解除し、アカウント B に相当する AWS アカウントで、アカウントインスタンスを削除する。
その後、管理アカウントから再度 IAM Identity Center の権限委任をする。 - AWS CLI
sso-admin delete-instanceサブコマンドで、直接アカウントインスタンスを削除する。
冒頭の結論で述べた通り、アカウントインスタンスと組織のインスタンスの力関係、そして、どちらの SSO インスタンスが先に存在しているかの諸条件によっては、メンバーアカウントから接続されている先の SSO インスタンスが、組織のインスタンスなのかアカウントインスタンスなのか、マネジメントコンソール上から直感的に判断できない状況に陥り、組織のインスタンスとしてできるはずの操作が行えない「ように見える」事象が発生する可能性が考えられることがわかりました。
そのため、IAM Identity Center のアカウントインスタンスはあくまで一時利用、正式運用時には削除して、組織のインスタンスを正式に利用する、と考えた方が良さそうです。
管理アカウント、メンバーアカウントと行ったり来たりする記事となり、少々わかりにくい部分もあるかと思いますが、本エントリがどなたかのお役に立てば幸いです。
市野 和明 (記事一覧)
マネージドサービス部・テクニカルサポート課
お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。
情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。
X（Twitter）：@kazzpapa3（AWS Community Builder）
