はじめに
IAM Identity Center の組織インスタンス（Organization Instance）とアカウントインスタンス（Account Instance）の2種類の違いをまとめてみました。
前提
IAM Identity Center の「インスタンス」とは、
ユーザーやグループ、権限を管理する単位のことです。
2023年11月のアップデートで、従来からの組織インスタンス（Organization Instance）に加えて、アカウントインスタンス（Account Instance）が追加されました。
両者は似た名前ですが、役割はまったく別物です。
組織インスタンスは AWS Organizations 全体のシングルサインオン基盤として使うもの、
アカウントインスタンスは単一の AWS アカウント内で特定の SaaS 系サービスと連携させるためのものです。
どちらも同じ「IAM Identity Center」のコンソールから操作しますが、
作れる機能と適用範囲がはっきり分かれています。
組織インスタンス（Organization Instance）
組織インスタンスは、AWS Organizations の管理アカウントで有効化するタイプで、
従来からある IAM Identity Center の本来の姿です。
1つの組織につき1つしか作れません。
主な役割は、組織内の複数アカウントに対して
シングルサインオンを提供することです。
管理アカウントで Permission Set を作り、各メンバーアカウントへ「誰がどの権限で入れるか」を割り当てる形で運用します。割り当てを行うと、対象アカウントに AWSReservedSSO_<権限セット名>_<ハッシュ> という IAM ロールが自動で作成され、SSO 経由のログインではこのロールが引き受けられます。
Permission Set、マルチアカウントへの割り当て、委任管理者（Delegated Administrator）、外部 IdP との SAML/SCIM 連携など、Identity Center の機能は基本的にこの組織インスタンスでフル活用できます。普段「Identity Center を使う」と言う場合、ほぼこちらを指していると考えて差し支えありません。
アカウントインスタンス（Account Instance）
アカウントインスタンスは2023年11月に追加された新しいタイプで、
任意の単一 AWS アカウントで有効化できます。
組織インスタンスと違い、AWS Organizations の管理アカウントである必要はなく、
1つの AWS アカウントにつき1つ作れます。
このインスタンスの主な用途は、Amazon Q Developer や Amazon QuickSight、Amazon Connect のような IAM Identity Center を前提にした AWS サービスを、単一アカウント内で利用することです。
組織インスタンスを持っていない場合や、組織とは別管理で試したい場合のために用意された選択肢と考えると分かりやすいです。
ここで特に重要なのが、アカウントインスタンスでは Permission Set を作成できないという制約です。 これは公式ドキュメントでも明記されており、Permission Set 非対応なので AWS アカウントへのコンソールログインや CLI アクセスにも使えません。
アカウントインスタンスで扱えるのは、Identity Center 対応アプリケーション（AWS Managed Application や OIDC 連携のカスタムアプリ）へのユーザー・グループ割り当てのみで、SAML 2.0 のカスタマー管理アプリには対応していません。「自分のアカウント内でひっそり Permission Set を作って使おう」という用途には使えないので注意が必要です。
違いを表で整理
両者の違いを実務で判断しやすい観点でまとめます。
| 項目 | 組織インスタンス | アカウントインスタンス |
|---|---|---|
| 作成場所 | Organizations の管理アカウント | 任意の単一 AWS アカウント |
| 作成できる数 | 組織ごとに1つ | アカウントごとに1つ |
| Permission Set の作成 | できる | できない |
| AWS アカウントへの SSO | できる | できない |
| マルチアカウントへの割り当て | できる | 不可（単一アカウント内のみ） |
| AWS マネージドアプリへの割り当て | できる | できる |
| OIDC カスタマー管理アプリへの連携 | できる | できる |
| SAML 2.0 カスタマー管理アプリへの連携 | できる | できない |
| SCIM によるユーザー同期 | できる | 対応なし |
| 委任管理者（Delegated Administrator） | 指定できる | 概念なし |
| 主な用途 | 組織全体の SSO 基盤 | 単一アカウントでの SaaS 系サービス連携 |
特に押さえておきたいのは、Permission Set と AWS アカウントへの SSO は組織インスタンスでしかできないという点です。
どちらを選ぶか
選び方はシンプルで、やりたいことが「AWS アカウントへの SSO」か「特定の SaaS 系 AWS サービスとの連携」かで分かれます。
組織インスタンスを選ぶケース
- 組織内の複数アカウントに対してシングルサインオン環境を整えたい
- 管理アカウントで作った Permission Set で、開発者ごとのアクセス権を統制したい
- 外部 IdP（Entra ID / Okta 等）と連携して、既存の ID 基盤を AWS に持ち込みたい
アカウントインスタンスを選ぶケース
- Amazon Q Developer など、Identity Center インスタンスを必要とする AWS サービスを単発で使いたい
- AWS Organizations の管理アカウントの操作権限がなく、組織インスタンスを作れない
- 組織の本番 SSO 基盤とは切り離して、検証用途で試したい
まとめ
IAM Identity Center の組織インスタンスとアカウントインスタンスは、
名前が似ていても役割がまったく違います。組織インスタンスはマルチアカウント SSO の本命で Permission Set を扱えるのに対し、アカウントインスタンスは単一アカウント内で SaaS 系サービスと連携するための仕組みで、Permission Set は作成できません。