AWS Organizationsが使えなくてもAWS IAM Identity Centerは使える？組織インスタンスとアカウントインスタンスの概念を整理してみた
コンバンハ、千葉（幸）です。
AWS IAM Identity Center（以降、単にIAM Identity Center）は、アプリケーションやAWSアカウントへのアクセスを一元管理できるソリューションです。特にAWSアカウントへのアクセスの用途で意識されることが多いのではないでしょうか。「IAMユーザーを使うのではなくIAM Identity Centerを使ってユーザー管理しましょう」とされることもしばしばあります。
IAM Identity Centerを使う上で気にする機会が多いのはAWS Organizationsです。「IAM Identity Centerを使用するときはAWS Organizationsがセットで必要」と聞く機会もあれば、「IAM Identity Centerを利用する際にAWS Organizationsは必須ではない」という旨がAWSドキュメントに書いてある。結局どっちなんだ？と迷うことがあるかもしれません。
先に結論を言ってしまうと「AWS Organizationsを使わなくてもIAM Identity Centerは利用できるが、多くの人がやりたいAWSアカウントへのシングルサインオンのためにはAWS Organizationsが必要」です。
そこにはIAM Identity Centerの組織インスタンスやアカウントインスタンスという概念が深く関わります。
今回はこのあたりを整理してみます。
AWS Organizationsが使えなくてもIAM Identity Centerは使えるか？（先にまとめ）
-
IAM Identity Centerによるアクセスには大きく以下の2種類がある
- AWSアカウントへのアクセス
- アプリケーションへのアクセス
-
IAM Identity Centerを有効化する際には以下のいずれかを指定する必要がある
- 組織インスタンス
- アカウントインスタンス（2023年11月に登場）
-
アカウント種別ごとの作成できるIAM Identity Centerインスタンスの種別は下記の通り
アカウント種別 組織インスタンス アカウントインスタンス AWS Organizationsの管理アカウント ● ● AWS Organizationsのメンバーアカウント - ● スタンドアロンアカウント - ● -
AWSアカウントへのアクセスには組織インスタンスが必要
まとめると、AWS Organizationsが使えなくてもIAM Identity Centerは使えるが、多くの人がやりたい「AWSアカウントへのアクセス」においてはAWS Organizationsの管理アカウントが必要。
少し遠回りしてAssumeRoleについておさえる
IAM Identity CenterによるAWSアカウントへのアクセスを考える際には、AssumeRoleの概念が強く関連します。簡単に押さえておきましょう。
IAMロールはお面のようなもので、そのお面を被った誰かに一時的な許可を与えてくれます。お面にはあらかじめ「できること（パーミッション）」が定められていますが、お面自体が意思を持って動くわけではなく、誰かが被って初めて効力を発揮することがポイントです。
ここでいう「お面を被る」をもう少しちゃんとした言葉に言い換えると「IAMロールを引き受ける」となり、対応するAPIはAssumeRoleと呼ばれます。
IAMロールを引き受ける主体により、APIはもう少し細分化されます。
sts:AssumeRole: IAMユーザーや別のIAMロール、AWSサービス等が引き受ける場合sts:AssumeRoleWithWebIdentity: OIDCプロバイダー等が引き受ける場合sts:AssumeRoleWithSAML: SAMLプロバイダーが引き受ける場合
今回は特にsts:AssumeRoleWithSAMLを覚えておきましょう。
AWSアカウントの種類についておさえる
さらに遠回りしてAWSアカウントの種類についてもおさえておきます。このあと出てくるIAM Identity Cenerの組織インスタンスやアカウントインスタンスと深く関連します。
AWS Organizationsと呼ばれる複数のAWSアカウントを一元管理するサービスがあります。AWS Organizations では最上位の管理アカウント（親アカウントとも）があり、それ以外のアカウントはメンバーアカウントと呼ばれます。AWS Organizationsによって管理されない単独の状態のAWSアカウントはスタンドアロンアカウントと呼んで区別することがあります。
簡単にまとめ直すと下記の通りです。
- 管理アカウント: AWS Organizationsの最上位アカウント
- メンバーアカウント: AWS Organizationsにおける管理アカウント以外のアカウント
- スタンドアロンアカウント : AWS Organizationsに属さないアカウント
なお、AWS Organizationsでは特定のサービスの管理をメンバーアカウントに委任することもできます。その場合、委任された先は「委任されたメンバーアカウント」「委任アカウント」などと呼ばれます。
IAM Identity Centerでも一部の操作を委任することはできるのですが、少し話がややこしくなるのでこのブログでは委任するケースは取り上げません。
IAM Identity Centerではなにができるのか？
そもそもIAM Identity Centerではなにができるのか？を簡単におさえておきましょう。ものすごく平坦にいうと、IAM Identity Centerは、AWSアカウントやアプリケーションへの単一ポータルを通じたシングルサインオンを実現するソリューションです。
ユーザーはIAM Identity CenterのAWSアクセスポータルに接続することで、AWSアカウントやアプリケーションにアクセスできます。「AWSアクセスポータル」という名前ですが、アクセス先はAWSに限定されていません。
アクセス先は下記に分類できます。
- AWSアカウントへのアクセス
- アプリケーションへのアクセス
- AWS管理アプリケーション
- カスタマー管理アプリケーション
- OAuth 2.0アプリケーション
- SAML 2.0アプリケーション
ここでの「AWSアカウントへのアクセス」は、IAM Identity Centerが有効化されたAWS Organizations組織内の任意のAWSアカウントへのアクセスを指します。詳細は後述しますが、「許可セット」と呼ばれる仕組みが肝になります。
SAML 2.0アプリケーションではZoomやSlack、GitHubなど300以上のアプリケーションが「事前定義されたカタログ」として用意されており、各種サービスプロバイダーが提供する手順に則って簡単にセットアップができるようになっています。
ここでの「ユーザー」やグループは、下記いずれかのIDソース内で定義されたものを使用します。
- Identity Center ディレクトリ（デフォルト）
- Active Directory
- 外部IDプロバイダー
一番シンプルに始めるならIdentity Centerディレクトリに個別にユーザー/グループを作成して管理していく方式が手っ取り早いですし、すでに管理しているActive Directoryや外部IDプロバイダー（Okta、Entra IDなど）があるのであればそのユーザー情報を利用することもできます。
IAM Identity CenterによるAWSアカウントへのアクセスのイメージ
「IAM Identity Centerを使いたい」という文脈で最も意識される機会が多いのは「AWSアカウントへのアクセス」かと思います。
その全体像をおさえるにはこちらのブログがおすすめです。当時は「AWS Single Sign On（AWS SSO）」という名称でしたが、今のIAM Identity Centerのことです。
簡単にいうと、IAM Identity Centerによる「AWSアカウントへのアクセス」は、AWS Organizations組織の各アカウントへのsts:AssumeRoleWithSAMLを簡単に実現するための仕組みと考えることもできます。
IAM Identity Centerの管理アカウント上で「許可セット」を用いて下記の組み合わせを定義します。
- IAM Identity Centerのユーザー/グループ
- AWSアカウント
- 権限（IDベースポリシーなど）
その組み合わせに応じ、AWS Organizations内の各アカウントにはIAMロールやIDプロバイダーが自動作成されます。
例えば自動で作成されたIAMロールはこんな感じ。画像では移っていませんが、このIAMロールにアタッチされているIDベースポリシー（画像でいう「許可」タブから確認できる。）は、許可セットで定義したものになっています。
👆信頼ポリシーではIDプロバイダー（SAML）からのsts:AssumeRoleWithSAMLが許可されています。
そのIDプロバイダーも自動作成されており、このような形で確認できます。
IAMロールもIDプロバイダーもAWS SSO（IAM Identity Centerの旧称）を感じる命名がされていますね。
IDプロバイダーは基本的にはAWSアカウントごとに1つ作成されますが、IAMロールは許可セットの定義に従い複数作成されます。
例外：SAML 2.0アプリケーションとしての外部AWSアカウントへのアクセス
先ほど見た「AWSアカウントへのアクセス」は同一AWS Organizations内のアクセスが前提となっていました。「アプリケーションへのアクセス」を使用して、AWS Organizations外部のアカウントへのアクセスも実現できます。
SAML 2.0アプリケーションではいくつか事前定義されたカタログがあると先ほど取り上げましたが、そのひとつとして「External AWS Account（外部のAWSアカウント）」があります。
詳細は、こちらも旧称のAWS SSO時代のブログですが以下に詳しいです。
こちらの方式では許可セットを使った権限管理には対応していないことに注意してください。
IAM Identity Centerの組織インスタンスとアカウントインスタンス
ようやくこのブログの本筋に近い話をします。先に冒頭のまとめで触れてしまいましたが、IAM Identity Centerを有効化する際には以下のいずれかのインスタンスを指定します。
- 組織インスタンス
- アカウントインスタンス
後者は相対的に新しい概念です。かつてはIAM Identity CenterはAWS Organizationsの利用が必須でしたが、2023年11月に単一のアカウントでも利用可能となりました。その際にアカウントインスタンスという概念が登場し、かつてのインスタンスは組織インスタンスとして区別されるようになりました。
当時のブログはこちら。アカウントインスタンスと組織インスタンスの画面の見え方の違いなども参考になります。
- [アップデート] AWS IAM Identity Center がメンバーアカウント個別の環境が作成出来るようになったので、作成して対応アプリケーションなどを調べてみた | DevelopersIO
AWSアカウントの種別ごとの、作成可能なインスタンスは下記の通りです。
組織インスタンスはAWS Organizationsの管理アカウントでしか作成できません。
組織インスタンスとアカウントインスタンスの違いは下記ページにまとまっています。
組織インスタンスではIAM Identity Centerのすべての機能を利用できます。アカウントインスタンスでできることとできないことをまとめると、下記の通りです。
言い換えると、アカウントインスタンスでできることは下記のみです。
- IDソースを用いたユーザー管理
- 一部のAWS管理アプリケーションへのアクセス
- OAuth 2.0アプリケーションへのアクセス
「AWSアカウントへのアクセス」も、SAML 2.0アプリケーションへのアクセスもアカウントインスタンスでは実施できません。
アカウントインスタンスは、一部のAWS管理アプリケーションへのアクセスのトライアルであったり、限定的なケースでの利用が想定されています。
AWS Organizationsが使えなくてもIAM Identity Centerは使えるか？（まとめの再掲）
-
IAM Identity Centerによるアクセスには大きく以下の2種類がある
- AWSアカウントへのアクセス
- アプリケーションへのアクセス
-
IAM Identity Centerを有効化する際には以下のいずれかを指定する必要がある
- 組織インスタンス
- アカウントインスタンス（2023年11月に登場）
-
アカウント種別ごとの作成できるIAM Identity Centerインスタンスの種別は下記の通り
アカウント種別 組織インスタンス アカウントインスタンス AWS Organizationsの管理アカウント ● ● AWS Organizationsのメンバーアカウント - ● スタンドアロンアカウント - ● -
AWSアカウントへのアクセスには組織インスタンスが必要
まとめると、AWS Organizationsが使えなくてもIAM Identity Centerは使えるが、多くの人がやりたい「AWSアカウントへのアクセス」においてはAWS Organizationsの管理アカウントが必要。
終わりに
AWS Organizationsが使えなくてもAWS IAM Identity Centerは使えるのか？という切り口で各種情報をまとめてみました。
多くの方がIAM Identity Centerでやりたいのは「AWSアカウントへのアクセス」だと思いますので、それはできませんよというのが一番言いたかったところです。
AWS Organizationsの管理アカウントは使えないけど複数AWSアカウントへのアクセスを管理したいときはどうすればいいの？という場合は、下記のブログが参考になるかと思います。
一番取り入れやすいのは「IAMユーザーからスイッチロール」ですが、すでに利用しているIDプロバイダーがあればSAMLアクセスによるシングルサインオンを導入するのも一つの手かと思います。IAM Identity Centerの組織インスタンスが利用できればより簡便なアクセスが実現できますが、それが難しい場合には自前でSAMLアクセスを工夫して用いる、というのもアリです。
以上、チバユキ (@batchicchi)がお送りしました。
