公開2026.07.30更新2026.09.27 セキュリティ

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

Q: aws loginとaws sso loginはどちらを使いますか？

入口が違います。 aws sso login は Identity Center のプロファイル（ sso-session ）でサインインし、権限セット由来のロールで資格情報を取ります。 aws login はブラウザでコンソールにサインインした状態から資格情報を引き取るコマンドで、AWS CLI 2.32.0 以上が前提です。account access manager で既存IAMロールを割り当てている場合や、ルートユーザー・IAMユーザーで入っている場合は後者を使います。両方を混在させる組織では、プロファイル名で系統が分かるようにしておくと運用が楽になります。

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ロールセッションの扱いを整理します。権限セットをCLIとIaCで作る手順、IAM側に追加された account access manager との使い分けも、実行できる形で載せました。採用条件と見送り条件も条件付きで示します。

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

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

設計で最初に決めるのは権限セットの粒度とセッション時間です。権限セットは各アカウントでIAMロールになるため、IAM側の「ロールにアタッチできる管理ポリシーは10本」というクォータが実質の天井になります。セッション時間はアクセスポータルが既定8時間、AWSアカウント側のIAMロールセッションが既定1時間で上限12時間。延ばすほど退職・権限剥奪時に権限が残る時間も伸びます。学習用アカウントへ配る権限セットをAWS CLIで作り、セッション時間を短く切る手順は、AWS Skill Builderの使い方と料金を実装者目線で解説した記事にコマンド付きで整理しています。

選択肢はもう1つ増えました。IAM の account access manager を使うと、権限セットを介さず既存のIAMロールを Identity Center のユーザー・グループへ割り当てられます。カスタム信頼ポリシーやロールタグ、ロールパスを残したいなら、権限セット一本槍より扱いやすい構成です。判断の順序は「アカウント横断の均一な人向けアクセス＝権限セット」「アカウントごとに違う既存ロールを流用＝account access manager」「機械のアクセス＝OIDC連携」の3分割で考えてください。

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 を指していると読み替えてください。ドキュメントのURLも docs.aws.amazon.com/singlesignon/ のままなので、公式を参照するときの検索語は旧名のほうが当たります。

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

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

公式ドキュメントは、この3系統を用途で並べています。権限セットは「読み取り専用・管理者といった均一な人向けアクセスを、変更不可のIAMロールとして自動プロビジョニングする」用途。account access manager は「アカウントごとに内容が異なるカスタムIAMロールを流用する」用途。IAMフェデレーションによる直接のロール引き受けは「ワークロード向け」。ロールの供給元が自動か手動（IaC）か、割り当て情報がどこに載るかが違います。

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

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

アカウントインスタンスは有効化したアカウントに束縛され、用途は一部AWSマネージドアプリの分離配置に限ると公式に書かれています。1アカウントに作れるインスタンスは1つだけ（増加不可）なので、先にアカウントインスタンスを有効化すると手戻りになります。組織インスタンスを作っても権限セットの画面が出ないときは、設定の「管理」タブでマルチアカウント権限が無効になっている可能性を疑ってください。UpdateInstance APIからも切り替えられます。

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

構成要素は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本（サイズ上限32,768バイト・非空白文字で10,240バイトまで）、AWS管理ポリシーと顧客管理ポリシーは合計25本です。ただしIAM側に「ロールにアタッチできる管理ポリシーは10本」というクォータがあるため、25本を使い切るにはデプロイ先アカウントごとに引き上げ申請が必要になります。許可境界の指定も可能で、AWS管理ポリシーのARNか顧客管理ポリシーの名前とパスのどちらかを選びます。

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

セッションの種類が分かれており、失効の伝播速度もそれぞれ違います。権限を剥がしたのに使えてしまうという問い合わせの大半は、この構造で説明が可能です。数値は公式の認証セッション解説に一覧があります。

セッション種別	既定	上限	失効の伝播
ユーザー対話セッション	8時間	90日	即時（再認証が必要）
アプリケーションセッション	1時間	自動更新	おおむね30分以内
IAMロールセッション	1時間	12時間	期限切れまで持続
ユーザー背景セッション	設定依存	長時間ジョブ向け	設定した期間まで

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

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

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

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

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

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

組織構成そのものが固まっていない場合は、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（増加不可）である点を見据え、部署名ではなく職務機能を軸に命名してください。ユーザー20万・グループ10万が既定の収容上限で、どちらも引き上げ申請の対象です。

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

権限セットと割り当てをコンソールで作ると差分が追えなくなります。CloudFormation なら AWS::SSO::PermissionSet と AWS::SSO::Assignment、Terraform なら aws_ssoadmin_permission_set が対応リソースです。改称後もリソース名は SSO 表記のままで、旧記事のサンプルもそのまま動きます。

Terraform の最小構成は次のようになります。インスタンスARNは aws_ssoadmin_instances データソースから引くので、環境ごとに書き分ける必要がありません。session_duration はISO 8601の期間表記で、既定は PT1H です。

data "aws_ssoadmin_instances" "this" {}

resource "aws_ssoadmin_permission_set" "readonly_ops" {
  name             = "ReadOnlyOps"
  description      = "operator read only"
  instance_arn     = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  session_duration = "PT1H"
}

resource "aws_ssoadmin_managed_policy_attachment" "readonly" {
  instance_arn       = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
  permission_set_arn = aws_ssoadmin_permission_set.readonly_ops.arn
}

引数の詳細は Terraform Registry の aws_ssoadmin_permission_set にあります。プロバイダー側の注記どおり、このリソースを更新すると割り当て済みの全アカウントへ自動で再プロビジョニングが走る点は押さえてください。書き方の型を揃えたいなら、TerraformでAWSを構築する手順でバックエンドと認証の設計から確認できます。

CloudFormation で同じものを書くとこうなります。プロパティ名は AWS::SSO::PermissionSet のテンプレートリファレンスに定義があり、ManagedPolicies は最大25要素、Name は32文字までという制限が付きます。

Resources:
  ReadOnlyOps:
    Type: AWS::SSO::PermissionSet
    Properties:
      InstanceArn: "arn:aws:sso:::instance/ssoins-1234567890abcdef"
      Name: "ReadOnlyOps"
      Description: "operator read only"
      SessionDuration: "PT1H"
      ManagedPolicies:
        - "arn:aws:iam::aws:policy/ReadOnlyAccess"
      Tags:
        - Key: "owner"
          Value: "platform"

CreateAccountAssignment は非同期呼び出し15並列まで（引き上げ不可）なので、数百アカウントへ一気に流すIaCにはリトライ設定を入れてください。ProvisionPermissionSet を ALL_PROVISIONED_ACCOUNTS で呼ぶ場合は最大3,500アカウント・同時3呼び出しが上限です。

権限セットをAWS CLIで作成し対象アカウントへ割り当てる作業手順

コンソールでの初回構築が終わったら、以後の追加はCLIに寄せたほうが速くなります。ここでは読み取り専用の権限セットを1本作り、特定アカウントの特定グループへ割り当てるところまでを通します。実行には管理アカウントか委任管理者アカウントの認証情報が必要です。

list-instancesでインスタンスARNと識別子を取得する

すべての sso-admin コマンドはインスタンスARNを要求します。ARNはコンソールの設定画面にも出ていますが、スクリプトへ埋め込むとアカウント間で使い回せなくなるため、都度引くのが安全です。グループIDは identitystore 側から取ります。

INSTANCE_ARN=$(aws sso-admin list-instances \
  --query "Instances[0].InstanceArn" --output text)

IDENTITY_STORE_ID=$(aws sso-admin list-instances \
  --query "Instances[0].IdentityStoreId" --output text)

GROUP_ID=$(aws identitystore list-groups \
  --identity-store-id "$IDENTITY_STORE_ID" \
  --query "Groups[?DisplayName=='platform-operators'].GroupId" \
  --output text)

create-permission-setから割り当てまでを一括で流す

権限セットの作成、管理ポリシーのアタッチ、アカウント割り当ての3手です。セッション時間はISO 8601表記で、ここでは1時間に切っています。アタッチ後は自動で再プロビジョニングが走るため、明示的な適用コマンドは要りません。

PS_ARN=$(aws sso-admin create-permission-set \
  --instance-arn "$INSTANCE_ARN" \
  --name ReadOnlyOps \
  --description "operator read only" \
  --session-duration PT1H \
  --query "PermissionSet.PermissionSetArn" --output text)

aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn "$INSTANCE_ARN" \
  --permission-set-arn "$PS_ARN" \
  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

REQ_ID=$(aws sso-admin create-account-assignment \
  --instance-arn "$INSTANCE_ARN" \
  --permission-set-arn "$PS_ARN" \
  --target-id 111122223333 --target-type AWS_ACCOUNT \
  --principal-type GROUP --principal-id "$GROUP_ID" \
  --query "AccountAssignmentCreationStatus.RequestId" --output text)

非同期のcreate-account-assignmentの完了を確認する

割り当てAPIは非同期で、コマンドが返った時点ではまだロールが出来ていません。IN_PROGRESS のまま先の処理へ進むとロール不在で失敗するので、ステータスを見てから次へ移ります。失敗時は FailureReason に理由が入ります。

aws sso-admin describe-account-assignment-creation-status \
  --instance-arn "$INSTANCE_ARN" \
  --account-assignment-creation-request-id "$REQ_ID" \
  --query "AccountAssignmentCreationStatus.[Status,FailureReason]"

aws sso-admin list-account-assignments \
  --instance-arn "$INSTANCE_ARN" \
  --account-id 111122223333 \
  --permission-set-arn "$PS_ARN"

15並列という制約はこのAPIに掛かります。数十アカウントへまとめて配るスクリプトを書くなら、リクエストIDを配列に貯めてからポーリングする形にしてください。逐次で待つと所要時間がアカウント数に比例します。

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

開発者が最も頻繁に触るのはCLIです。設定形式が2種類あり、どちらを書いたかでトークンの自動更新の有無が変わります。ここを間違えると1日に何度も再ログインする運用になります。aws-cli リポジトリのCHANGELOGで追える最新版は2026年9月時点で2.36系です。

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つです。

[profile dev]
sso_session = corp-sso
sso_account_id = 111122223333
sso_role_name = ReadOnlyOps
region = ap-northeast-1
output = json

[profile prod]
sso_session = corp-sso
sso_account_id = 444455556666
sso_role_name = ReadOnlyOps

[sso-session corp-sso]
sso_region = us-east-1
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:access

レガシー構成は、プロファイルに sso_start_url と sso_region を直接書く古い形式です。AWS CLIのIAM Identity Center設定ガイドは、この形式ではトークンの自動更新に対応しないと明記しています。既存の設定に sso-session の記述が無ければレガシー形式で、下の形から上の形へ書き換えるだけで再ログインの頻度が下がります。

[profile legacy-dev]
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_region = us-east-1
sso_account_id = 111122223333
sso_role_name = ReadOnlyOps
region = ap-northeast-1
output = json

1つの sso-session は複数プロファイルから再利用でき、認証部分を共通化できます。取得したトークンは ~/.aws/sso/cache 配下にセッション名を元にしたファイル名でキャッシュされる仕組みです。デュアルスタック対応のStart URLを使う場合は ssoins- で始まるポータルURLを指定し、独自ドメインのバニティURLなら初回サインイン後にCLIがリダイレクト先から sso_region を書き足します。CLI側の設定全般はAWS CLIの導入と運用をまとめた記事にv1サポート終了後の移行手順まで含めて整理しました。

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

初回設定は対話式のウィザードで済みます。バージョン2.22.0を境に認可方式の既定が変わるため、CLIのバージョンを先に確認してください。sso-session セクションだけを作り直したいときは aws configure sso-session を使います。アクセスポータルと権限セットの期限の関係、デバイスコード認可、エラーの切り分けはaws sso loginの設定手順とトークン期限・デバイスコード認可・エラー対処にまとめています。

aws --version

aws configure sso
aws configure sso --use-device-code

aws sso login --sso-session corp-sso
aws sts get-caller-identity --profile dev

aws sso logout

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

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

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

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

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

account access managerで既存IAMロールを割り当てる選択肢

権限セットは便利ですが、生成されるIAMロールの中身を細かく触れません。信頼ポリシーを書き換えたい、ロールタグでABACをやりたい、ロールパスで整理したい、といった要求は権限セットの外側にあります。IAM 側に追加された account access manager は、この穴を埋める仕組みです。

既存IAMロールをそのまま割り当てる構成が向く場面と導入の前提

account access manager は、Identity Center の組織インスタンスに同期済みのユーザー・グループへ、AWSアカウント内の既存IAMロールを割り当てます。権限セットと併用でき、片方だけでの運用も可能です。公式は次の3点を利点として挙げています。IAMロールタグとセッションタグによるABAC、信頼ポリシーによる引き受け条件の制限とIdPクレームの条件利用、ロールパスによる論理的なグループ化です。

前提として、ロールの供給は自動ではありません。権限セットが「割り当てれば勝手にロールが出来る」のに対し、こちらはIaCかIAMコンソールで先にロールを作っておく必要があります。割り当て情報の置き場所も Identity Center ではなく account access manager 側で、APIの名前空間も IAM とは別の account-access です。ユーザーから見た入口はAWSアクセスポータル内の「AWSアカウントアクセス」アプリケーションで、そのセッションは Identity Center のアプリケーションセッションとして扱われます。

aws loginコマンドと従来のaws sso loginの使い分け基準

CLIの体験も違います。権限セットの側は aws configure sso でプロファイルを作り aws sso login でセッションを張る流れでした。account access manager の側は、ブラウザでAWSにサインインして目的のロールでアカウントへ入り、そのあとターミナルで aws login を叩いてブラウザ側のロールセッション資格情報を引き取ります。

aws --version

aws login
aws login --remote
aws login --profile dev --region ap-northeast-1

aws logout

AWSサインインのユーザーガイドによれば、aws login の利用には AWS CLI 2.32.0 以上が必要です。ルートユーザー・IAMユーザー・IAMフェデレーションでコンソールに入れる利用者向けの入口で、認証後のCLIセッションは最大12時間有効。IAMユーザーやロールに対しては SignInLocalDevelopmentAccess 管理ポリシーの付与が要ります。ブラウザを持たない端末では --remote でクロスデバイス認証に切り替えられ、同一端末とクロスデバイスのどちらを許すかはIAMポリシーのリソースARNで制御できます。

使い分けの基準はこうです。Identity Center をIDソースにしてアカウント横断で均一なロールを配るなら aws sso login、アカウントごとに作り込んだ既存IAMロールへ入るなら aws login。両方が並存する組織では、プロファイル名の接頭辞を分けて手順書に書き分けておくと事故が減ります。

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

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

「1つのAWSアカウントで同時に更新できる権限セット（IAMロール）は1本」という制約も見落とされがちです。CIから複数の権限セットを並列で更新すると、後発の呼び出しが弾かれます。パイプラインは対象アカウント単位で直列化しておくのが無難です。

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

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

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

IdP起点のSAMLシングルログアウトにも、SAML 2.0アプリケーションへの送信にも非対応である点を前提に運用設計してください。Identity CenterをVPN接続の認証基盤として使う場合の設定と制約はAWS Client VPNの認証3方式にまとめています。MFAはFIDO2認証器・RFC 6238準拠のTOTPアプリ・AWS Managed Microsoft AD 経由のRADIUS MFAに対応し、1ユーザー最大8デバイス（仮想認証アプリ2つ＋FIDO認証器6つ）まで登録できます。Identity Center 側のMFAを有効にすると、ポータルのサインインではRADIUS MFAが上書きされる仕組みです。どの方式を必須にするかの判断材料は、多要素認証（MFA）の3要素と耐フィッシング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を強制し、アクセスキーを発行しない運用で十分です。CLIの資格情報は aws login で都度取る形にすれば、長期キーを置かずに済みます。

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

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

最も多い失敗は、IAM Identity Center を入れたあともIAMユーザーを残して両方が生き続ける状態です。棚卸しの対象が2系統に分かれ、退職者のアクセスキーが放置されます。対策は移行計画の時点で「IAMユーザーの廃止期限」を切ることです。認証情報レポートでの棚卸し、アクセスキーの無効化から削除までの待機期間、Terraformでの割り当てはAWS SSOへの移行手順｜IAMユーザー棚卸しから権限セットのTerraform化までで手順にしています。

よくある質問

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

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操作にリージョン差があるため、複製前に公式の対応表で確認してください。

aws loginとaws sso loginはどちらを使いますか？

入口が違います。aws sso login は Identity Center のプロファイル（sso-session）でサインインし、権限セット由来のロールで資格情報を取ります。aws login はブラウザでコンソールにサインインした状態から資格情報を引き取るコマンドで、AWS CLI 2.32.0 以上が前提です。account access manager で既存IAMロールを割り当てている場合や、ルートユーザー・IAMユーザーで入っている場合は後者を使います。両方を混在させる組織では、プロファイル名で系統が分かるようにしておくと運用が楽になります。

管理ポリシー10本の上限に当たったらどうしますか？

手は3つあります。第一に、権限セットへ付けている複数のAWS管理ポリシーを顧客管理ポリシー1本へ統合する方法。第二に、デプロイ先アカウントごとにIAMの「ロールにアタッチされた管理ポリシー」クォータの引き上げをService Quotasから申請する方法。第三に、権限セットではなく account access manager で既存IAMロールを割り当て、IAM側のロール設計の自由度を使う方法です。運用の手数を増やしたくないなら、まず第一の統合から試してください。