AWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説

AWS IAM Identity Center は、AWS Organizations 配下の複数アカウントとAWSマネージドアプリケーションへのアクセスを、1か所の割り当てで統制する仕組みです。2022年7月26日に AWS Single Sign-On から改称されましたが、API名前空間は sso と identitystore のまま変わっていません。この記事では、権限セットが各アカウントで AWSReservedSSO_ 接頭辞のIAMロールになる仕組み、クォータから逆算した権限設計の上限、AWS CLI v2 の sso-session 設定、サインアウト後も最大12時間残るIAMロールセッションの扱いを整理します。採用条件と見送り条件も条件付きで示します。

まとめ｜AWS IAM Identity Center導入の判断軸と権限設計の要点

採用の分かれ目は「AWSアカウントが複数あるか」と「社内に単一の人事系IDソースがあるか」の2点です。両方が揃っていれば、アカウントごとにIAMユーザーを作り分ける運用より、権限セット1本を複数アカウントへ割り当てる運用のほうが管理コストが下がります。本番1アカウントだけなら初期構築の手間は回収できません。

設計で最初に決めるのは権限セットの粒度とセッション時間です。権限セットは各アカウントでIAMロールになるため、IAM側の「ロールにアタッチできる管理ポリシーは10本」というクォータが実質の天井になります。セッション時間はアクセスポータルが既定8時間、AWSアカウント側のIAMロールセッションが既定1時間で上限12時間。延ばすほど退職・権限剥奪時に権限が残る時間も伸びます。

AWS IAM Identity Centerの役割とAWS SSO改称後に残る名前空間

改称から4年が経ち、コンソールの表記は新名称に切り替わりました。一方でAPIやIaCの識別子は旧名のままです。この非対称が、検索で古い記事に当たったときの混乱の元になっています。

2022年7月26日の改称でsso名前空間が変わらなかった理由

改称日は2022年7月26日です。後方互換のため、次の識別子は改称の対象外とされました。

• API名前空間の sso と identitystore
• CLIコマンドの aws sso、aws sso-admin、aws sso-oidc、aws identitystore
• AWSSSO および AWSIdentitySync 接頭辞のAWS管理ポリシー
• サービスリンクロールの AWSServiceRoleForSSO
• AWS::SSO 接頭辞のCloudFormationリソース
• sso や singlesignon を含むエンドポイント・コンソールURL

改称に追随するコード修正は不要です。社内手順書で「AWS SSO」に出会ったら、現行の IAM Identity Center を指していると読み替えてください。

IAMユーザー・IAMフェデレーションとの役割分担と線引き基準

境界は「誰の入口を作るか」で引きます。IAM はAWSアカウント内部でリソースへの権限を定義するレイヤーで、AWS IAMのユーザー・ロール・ポリシーの使い分けはアカウント単位の話に閉じています。IAM Identity Center が担うのは、その手前にある人（ワークフォース）の認証と、どのアカウントのどのロールを使えるかという割り当てです。

組織インスタンスとアカウントインスタンスの使い分けの判断基準

インスタンスは2種類あり、選択は実質的に一択です。組織インスタンスは AWS Organizations の管理アカウントにデプロイされ、公式にベストプラクティスとされています。複数アカウントへ権限を割り当てる機能が使えるのは組織インスタンスだけです。

アカウントインスタンスは有効化したアカウントに束縛され、用途は一部AWSマネージドアプリの分離配置に限ると公式に書かれています。1アカウントに作れるインスタンスは1つだけ（増加不可）なので、先にアカウントインスタンスを有効化すると手戻りになります。

権限セット・アイデンティティソース・アクセスポータルの構成要素

構成要素は4つです。ユーザーとグループの供給元であるアイデンティティソース、権限のテンプレートである権限セット、両者を結ぶ割り当て、ユーザーの入口となるAWSアクセスポータル。設計はそれぞれの制約から逆算します。

アイデンティティソース3種と切り替え時に失う割り当て情報の扱い

選べるのは、外部IdP（Okta や Microsoft Entra ID など）、オンプレミスまたはAWSマネージドのActive Directory、Identity Center ディレクトリの3種です。初回有効化時は Identity Center ディレクトリが既定で構成されます。制約として、アイデンティティソースは組織あたり1つだけで、部門ごとに別のIdPを繋ぐ設計は成立しません。

ADを繋ぐ場合、同時接続できるディレクトリ数は1で増やせず、SAMBA4ベースの Simple AD は非対応です。切り替えを後から実施すると、識別子がソース側に依存するため割り当ての作り直しを伴います。方式の比較検討が残っている段階なら、シングルサインオンの4つの実現方式とIdP選定を先に読み、AWS内に閉じた話か全社の認証基盤の話かを切り分けてください。

権限セットがAWSReservedSSO_ロールになる仕組みと上限25本

権限セットは1つ以上のIAMポリシーをまとめたテンプレートです。割り当てを行うと対象アカウントに IAM Identity Center 管理下のIAMロールが作成され、権限セットを変更すればポリシーとロールも追随します。ロール名は AWSReservedSSO_ に権限セット名と一意サフィックスが続く形式で、ARNは aws-reserved 配下の sso.amazonaws.com パスに置かれます。アイデンティティソースが us-east-1 にある場合、ARNにリージョン部分は入りません。

ここに落とし穴があります。割り当てを全削除するとロールも削除され、後で再割り当てすると別の一意サフィックスでロールが作り直される仕様です。Amazon EKS の aws-auth ConfigMap や AWS KMS のキーポリシーでロールARNを直接参照していると、参照が古くなってアクセスが壊れます。回避策は、参照先アカウントに割り当てを1つ常設する、条件演算子 ArnLike で末尾をワイルドカードにする、の2つです。

ポリシーの上限は二段構造になっています。権限セットあたり、インラインポリシーは1本（非空白文字で10,240バイトまで）、AWS管理ポリシーと顧客管理ポリシーは合計25本です。ただしIAM側に「ロールにアタッチできる管理ポリシーは10本」というクォータがあるため、25本を使い切るにはデプロイ先アカウントごとに引き上げ申請が必要になります。許可境界の指定も可能です。

割り当て変更の反映が即時・30分・最大12時間に分かれる理由

セッションの種類が3層に分かれており、失効の伝播速度もそれぞれ違います。権限を剥がしたのに使えてしまうという問い合わせの大半は、この構造で説明できます。

IAMロールセッションだけが独立して動く点が要注意です。いったん確立すると元のサインインセッションの状態と無関係に、権限セットへ設定した時間まで持続します。長時間のCLI処理が突然切れないようにするための設計です。なおグループの追加・削除は例外で、アクセスポータルとCLIには即時反映されます（外部IdP利用時はIdP側の同期後）。

Organizations全機能有効化から外部IdP連携までの導入手順

導入は前提の確認から入ります。順序を間違えると、アイデンティティソースを切り替える手戻りが発生しかねません。ここでは組織インスタンスと外部IdPを使う、最も一般的な構成の手順を示します。

AWS Organizationsの全機能有効化と委任管理者の指定手順

前提はAWS Organizationsです。公式FAQは、アカウントのシングルサインオン管理を行うには組織の全機能（all features）を有効化する必要があると述べています。一括請求のみの構成では、マルチアカウントの権限割り当てに進めません。

1. Organizations の機能セットを確認し、一括請求のみなら全機能へ切り替える
2. 管理アカウントで IAM Identity Center を有効化し組織インスタンスを作る
3. 日常運用を移すため、セキュリティ系アカウントを委任管理者に登録する
4. アイデンティティソースを外部IdPへ切り替える
5. 権限セットを作り、対象アカウントとグループの組で割り当てる

組織構成そのものが固まっていない場合は、AWS Organizationsのマルチアカウント管理とSCP設計を先に済ませてください。OU構成が決まらないうちに権限セットを量産すると、後からOU単位の割り当てに整理し直す作業が発生します。

外部IdP接続とSCIM同期で属性・グループ名を設計する手順

外部IdPとの接続はSAML 2.0のメタデータ交換で行い、ユーザーとグループの同期はSCIMで自動化します。SCIMによるID自動プロビジョニングの仕組みを押さえておくと、どの属性をマッピングすべきかの判断が早くなります。同期の失敗はほぼ属性の不足か命名の衝突です。

スロットリングも設計要素になります。SCIM APIは書き込み25 TPS・読み取り40 TPS、Identity Store API は1API・1インスタンスあたり20 TPSです。数千人規模の初回同期では、IdP側のバッチ設定を絞らないと調整が入ります。グループ名は、1権限セットに割り当てられるグループ数が100（増加不可）である点を見据え、部署名ではなく職務機能を軸に命名してください。

権限セットをCloudFormationとTerraformでIaC化する判断

権限セットと割り当てをコンソールで作ると差分が追えなくなります。CloudFormation なら AWS::SSO::PermissionSet と AWS::SSO::Assignment、Terraform なら aws_ssoadmin_permission_set が対応リソースです。改称後もリソース名は SSO 表記のままで、旧記事のサンプルもそのまま動きます。CreateAccountAssignment は非同期呼び出し15並列まで（引き上げ不可）なので、数百アカウントへ一気に流すIaCにはリトライ設定を入れてください。

AWS CLI v2のsso-session設定とPKCE認可でのトークン更新

開発者が最も頻繁に触るのはCLIです。設定形式が2種類あり、どちらを書いたかでトークンの自動更新の有無が変わります。ここを間違えると1日に何度も再ログインする運用になります。

sso-session形式とレガシー形式でトークン自動更新が違う点

推奨はSSOトークンプロバイダー構成です。sso-session セクションに sso_start_url と sso_region を必須で書き、sso_registration_scopes にはアカウントとロールの一覧を取得するための sso:account:access を指定します。プロファイル側に書くのは sso_session、sso_account_id、sso_role_name の3つです。

レガシー構成は、プロファイルに sso_start_url と sso_region を直接書く古い形式です。公式ドキュメントは、この形式ではトークンの自動更新に対応しないと明記しています。既存の設定に sso-session の記述が無ければレガシー形式で、書き換えるだけで再ログインの頻度が下がるはずです。1つの sso-session は複数プロファイルから再利用でき、認証部分を共通化できます。

aws configure ssoからaws sso loginまでの実行手順

初回設定は対話式のウィザードで済みます。バージョン2.22.0を境に認可方式の既定が変わるため、CLIのバージョンを先に確認してください。

1. aws configure sso でセッション名・Start URL・SSOリージョン・スコープを入力する
2. ブラウザで認可が完了したら、アカウントとロールの一覧から選択する
3. 既定リージョン・出力形式・プロファイル名を指定して書き込む
4. 以後は aws sso login に --profile か --sso-session を指定する
5. 作業終了時は aws sso logout でキャッシュを削除する

2.22.0以降はPKCE認可が既定になり、表示されるURLはサインイン対象と同じ端末のブラウザで開く必要があります。リモートのシェルで作業する場合は --use-device-code を付けてデバイス認可に切り替えてください。同バージョン以降は Start URL の代わりに Issuer URL も指定できます。

CI/CDでIdentity Centerを使わずOIDC連携を選ぶ判断

ここは言い切ります。CI/CDのジョブから IAM Identity Center を使うのは避けてください。認可フローがブラウザ操作を前提としており、デバイス認可に切り替えても人間がコードを入力する工程が残ります。無人実行との相性が構造的に悪い仕組みです。

代替は、GitHub Actions や GitLab CI のOIDCプロバイダーをIAMのIDプロバイダーとして登録し、リポジトリやブランチを条件にしたIAMロールを引き受ける構成です。長期のアクセスキーも不要になり、どのワークフローが引き受けたかを監査で追えます。人のアクセスはIdentity Center、機械のアクセスはOIDC連携という住み分けにしてください。

クォータとセッション時間から逆算する権限セット設計の実務的な上限

権限セットは無制限に増やせません。既定クォータは権限セット3,500・1アカウントあたり500で、増加できないグループ100・インラインポリシー1本・トークン発行者10が設計を縛ります。実務で先に当たるのはIAM側の管理ポリシー10本の壁で、既存IAMロールをそのまま移す移行では顧客管理ポリシー1本へ統合しておくと手数が減ります。

サインアウト後も最大12時間残るロールセッションの穴の塞ぎ方

退職者のアクセス停止を「アカウント無効化」だけで済ませると穴が残ります。ユーザーのアクセス無効化・削除・セッション失効・本人のサインアウトのいずれでも、アクセスポータルへのアクセスは即時に止まる一方、既存のアプリケーションセッションは約30分、IAMロールセッションは最大12時間残ります。

塞ぎ方は2つです。第一に、権限セットのセッション時間を業務実態へ合わせて短くします。既定は1時間で、長時間バッチを回す権限セットだけ個別に延ばす運用なら大半は1〜2時間で足ります。第二に、退職処理の手順へ「IdP側の無効化」と「Identity Center 側のセッション失効」を両方入れてください。IdP側だけを止めても Identity Center 側の既存セッションは自前で切る必要があります。

IdP起点のSAMLシングルログアウトにも、SAML 2.0アプリケーションへの送信にも非対応である点を前提に運用設計してください。MFAはFIDO2認証器・RFC 6238準拠のTOTPアプリ・AWS Managed Microsoft AD 経由のRADIUS MFAに対応し、1ユーザー最大8デバイス（仮想認証アプリ2つ＋FIDO認証器6つ）まで登録できます。Identity Center 側のMFAを有効にすると、ポータルのサインインではRADIUS MFAが上書きされます。

IAM Identity Centerを採用する条件と見送るべき組織構成

採用可否を条件付きで結論づけます。判断材料はアカウント数・IDソースの有無・アクセスする人数の3つで、追加料金が発生しないため費用は材料になりません。

AWSアカウント複数と外部IdPが揃う組織で採用する具体条件

次の3条件が揃うなら採用します。第一に、AWSアカウントが3つ以上あり今後も増える見込みがあること。第二に、社内に単一の人事系IDソース（Entra ID、Okta、ADのいずれか）が既にあること。第三に、AWSを触る人が5名以上で入退社や異動が発生すること。この状態ではIAMユーザーを作り分ける運用が破綻します。

2つしか揃わない場合も、Organizations の全機能を有効化する予定があるなら先に入れておくほうが安いです。後から移行するとIAMユーザーの棚卸しと権限セットへの再設計が同時に発生します。土台づくりから外部に任せる選択もあり、当社ではAWSを含むクラウドインフラ構築の支援として、OU設計から権限セットのIaC化まで請け負っています。

単一アカウントや機械認証が中心の環境で導入を見送る場面と代替

見送るべき場面を挙げます。AWSアカウントが1つだけで、触る人が3名以下、かつ社内にIdPが無い環境では過剰です。Identity Center ディレクトリにユーザーを作る手間はIAMユーザーと大差なく、全機能有効化という前提だけが増えます。この規模ならIAMユーザーにMFAを強制し、アクセスキーを発行しない運用で足ります。

もう1つは、人が触るのは障害対応時だけで日常はCI/CDとバッチしか動かない環境です。この場合はOIDC連携のIAMロールで完結し、人のアクセス基盤を作る投資が回収できません。合弁やグループ会社統合の途中で複数のIdPが並存している場合も、組織あたり1ソースの制約に当たるため、IdP側の統合を先に済ませてください。

移行時にIAMユーザーを残したまま失敗する典型パターンと対策

最も多い失敗は、IAM Identity Center を入れたあともIAMユーザーを残して両方が生き続ける状態です。棚卸しの対象が2系統に分かれ、退職者のアクセスキーが放置されます。対策は移行計画の時点で「IAMユーザーの廃止期限」を切ることです。

よくある質問

導入検討と移行の現場で実際に寄せられる質問を、公式ドキュメントの記述に沿って整理します。

AWS SSOとIAM Identity Centerは別のサービスですか？

同じサービスです。2022年7月26日に AWS Single Sign-On から AWS IAM Identity Center へ改称されました。後方互換のため、sso と identitystore のAPI名前空間、aws sso 系のCLIコマンド、AWS::SSO 接頭辞のCloudFormationリソース、AWSServiceRoleForSSO サービスリンクロールはいずれも変わっていません。旧名称で書かれたIaCはそのまま動作します。

IAM Identity Centerの利用に料金はかかりますか？

サービス自体に追加料金はかかりません。AWS公式FAQは「IAM Identity Center is offered at no extra charge.」と明記しています。課金が発生するのは周辺です。アイデンティティソースとして AWS Managed Microsoft AD や AD Connector を立てればディレクトリ側の料金がかかり、外部IdPを使う場合はIdP側のライセンス費用が主なコストになります。

権限セットを変更したら反映はいつになりますか？

権限セットの変更自体は、IAM Identity Center が対応するIAMポリシーとロールを更新することで反映されます。ただし既存のIAMロールセッションには即時に効きません。すでに発行されたセッションは権限セットへ設定した時間（既定1時間・最大12時間）まで持続します。グループの追加・削除はアクセスポータルとCLIに即時反映され、既存のアプリケーションセッションは次回更新時、おおむね30分以内に切り替わります。

IAMユーザーは全廃すべきですか？

人が使うIAMユーザーは廃止する方向で問題ありませんが、全廃を急ぐ必要はありません。公式ドキュメントは、IAMでのフェデレーションを既に使っている場合、既存のAWSアカウントアクセスのワークフローを変更せずAWSマネージドアプリケーション向けにだけ IAM Identity Center を使う構成を認めています。実務では、人はIdentity Center、CI/CDはOIDC連携のIAMロール、緊急時用に最小限のIAMユーザーを1つ、という3層構成が扱いやすい形です。

リージョンごとに設定が必要ですか？

インスタンスは単一リージョンで動きますが、追加リージョンへ複製すれば、有効化したすべてのリージョン経由でアカウントとアプリケーションにアクセスできます。有効化できるリージョン数の既定クォータは6で、増加申請が可能です。複製時はAPIのスロットリング上限が有効リージョンごとに適用されます。ただし利用できるAPI操作にリージョン差があるため、複製前に公式の対応表で確認してください。

関連記事

• SAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分け：外部IdPと交換するメタデータとアサーションの中身がわかります
• AWS Managed Microsoft ADとは？料金・エディション・Simple AD/AD Connectorとの違い：ADを選ぶ場合の判断材料です
• Okta（オクタ）とは？認証の仕組み・機能・料金・セキュリティ：外部IdPの代表例としてSCIM同期の前提を確認できます
• Microsoft Entra ID（旧Azure AD）とは？Azure AD/Active Directoryとの違い：Microsoft 365利用企業の比較対象です
• 認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定：全社の認証基盤としての着手順を整理できます