AWS IAM Identity Center User Management Guide

• Model type: permission-sets
• Description: Access is governed by permission sets, which are administrator-defined collections of IAM policies stored in IAM Identity Center. When a permission set is assigned to a user or group for a given AWS account, IAM Identity Center creates a corresponding IAM role (prefixed AWSReservedSSO_) in that account and attaches the specified policies. Users assume these roles via the AWS access portal or CLI. A single user can hold multiple permission sets across multiple accounts. Permission sets can contain AWS managed policies, customer managed policies (defined in the target account), inline policies, and a permissions boundary.
• Custom roles: Yes
• Custom roles plan: Free (included with AWS account)
• Granularity: Policy-level: up to 10 AWS managed or customer managed policies per permission set, plus one inline policy and one permissions boundary. Customer managed policies must exist in each target AWS account before the permission set can be provisioned there.

1. Sign in to the AWS Management Console with administrative credentials for the management account (organization instance) or the relevant account (account instance).
2. Navigate to IAM Identity Center (https://console.aws.amazon.com/singlesignon/home).
3. In the left navigation pane, choose Users.
4. Choose Add user.
5. On the Specify user details page, enter: Username (required, immutable after creation, 1–100 characters), Password option (send email invitation or generate one-time password), Email address (required, must be unique), First name (required for SCIM auto-provisioning to work), Last name (required for SCIM auto-provisioning to work), Display name.
6. Optionally add the user to one or more existing groups on the Add user to groups page.
7. Review the summary and choose Add user.
8. If email invitation was selected, the user receives an email from no-reply@signin.aws or no-reply@login.awsapps.com with subject 'Invitation to join IAM Identity Center'. The invitation expires in 7 days.
9. After the user is created, assign access by navigating to Multi-account permissions > AWS accounts, selecting the target account(s), choosing Assign users or groups, selecting the user or group, and selecting or creating a permission set.

Required fields: Username (immutable after creation), Email address (must be unique across the Identity Center instance), First name, Last name, Password setup method (email invitation or one-time password)

Watch out for:

• Username cannot be changed via the console after creation. To rename, the user must be deleted and recreated, or the CLI command 'aws identitystore update-user' with AttributePath 'userName' can be used (not officially documented as a supported console operation).
• Email invitation expires in 7 days. If it expires, the admin must reset the password and resend.
• Users created via the CLI (create-user API) do not have passwords set. Admin must generate a one-time password or enable the setting to send a verification email on first sign-in attempt.
• After enabling SCIM automatic provisioning from an external IdP, users can no longer be added or edited manually in the IAM Identity Center console.
• New users must activate their credentials before they can sign in to the AWS access portal.
• Creating a user does not grant any AWS access. A permission set must be separately assigned to the user (or a group the user belongs to) for one or more AWS accounts.

• Can delete users: Yes
• Delete/deactivate behavior: Both disable and delete are supported. Disabling (Disable user access) immediately prevents the user from creating new sign-in sessions to the AWS access portal but does not terminate existing active sessions. Deleting (Delete user) permanently removes the user from the Identity Center directory and removes their access to AWS accounts and applications; this action cannot be undone. For either action, existing active IAM role sessions (assumed via permission sets) continue until they expire per the permission set session duration (up to 12 hours) unless manually revoked.

1. Navigate to IAM Identity Center > Users.
2. Select the username of the user to disable.
3. In the General information section, choose Disable user access.
4. In the confirmation dialog, choose Disable user access.
5. To also terminate existing active portal sessions: on the user's detail page, choose the Active sessions tab, select the sessions to end, and choose Delete session (or End sessions).
6. To revoke active IAM role sessions assumed from permission sets: navigate to the permission set assignments and remove all assignments for the user, or apply a deny SCP via AWS Organizations.

Watch out for:

• Disabling or deleting a user via the console or Identity Store APIs does not immediately terminate existing active IAM role sessions. Those sessions persist until they expire (up to 12 hours per permission set configuration) unless manually revoked.
• After a user is deleted, their active sessions cannot be revoked from the IAM Identity Center console because the user record no longer exists.
• If a user has an active AWS access portal session and is disabled, they can continue to assume new IAM roles until all permission set assignments are also removed.
• For external IdP users, the user must be deprovisioned at the IdP level. Deleting from the Identity Center console alone does not prevent re-provisioning on the next SCIM sync cycle.
• There is no native API to disable a user programmatically (only delete is supported via the Identity Store API). Disabling requires console action or a manual workflow.

• Where to check usage: IAM Identity Center console > Users (lists all users and their status). For login activity: AWS CloudTrail console > Event history, filter by event source 'sso.amazonaws.com' or user name. For inactive Identity Center users: use CloudTrail login events combined with a Lambda function or the AWS re:Post Knowledge Center automation pattern.
• How to identify unused seats: No built-in 'last login' column in the IAM Identity Center Users list. Inactive users must be identified by querying CloudTrail for UserAuthentication events. AWS provides a sample Lambda + EventBridge + DynamoDB pattern (see repost.aws/knowledge-center/auto-remove-inactive-iam-identity-center-users) that tracks last login timestamps and flags users who have not signed in within a configurable period (e.g., 90 days).
• Billing notes: IAM Identity Center itself is offered at no extra charge. Costs may arise from underlying AWS services users access (EC2, S3, RDS, etc.), and from related services such as AWS CloudTrail (for audit logging beyond free tier), AWS Lambda (if using automation), and AWS IAM Access Analyzer (separate pricing). There are no per-user, per-seat, or per-permission-set fees.

There are no per-user, per-seat, or per-permission-set fees for IAM Identity Center itself. Costs arise only from the AWS services users access (EC2, S3, RDS, etc.) and from adjacent services such as CloudTrail (audit logging beyond the free tier) or Lambda (if you build automation).

Related services like IAM Access Analyzer carry separate pricing and are not bundled.

Administrators migrating from classic IAM users consistently flag the permission-set-per-account model as a steep mental shift - access is not global, it must be assigned per account.

Azure AD users hit a hard wall with nested groups: only direct group members sync via SCIM, and multivalue attributes (multiple emails or phone numbers) fail entirely.

Two operational pain points come up repeatedly: usernames cannot be changed in the console after creation, and there is no API to disable a user - only delete - which blocks full automation of offboarding workflows.

Disabling or deleting a user does not immediately terminate existing IAM role sessions; those persist up to 12 hours unless manually revoked.

Common complaints:

• Nested group limitations with Azure AD: Azure AD nested groups are not supported by SCIM provisioning into IAM Identity Center; only direct group members are synced.
• Attribute removal sync issues: Removing an attribute value in the IdP (e.g., clearing a phone number) does not always propagate correctly to IAM Identity Center via SCIM; multivalue attributes are not supported and attempts to sync them fail.
• Complex multi-account setup: The abstraction of users > groups > permission sets > account assignments is confusing for administrators migrating from classic IAM users, particularly the requirement to assign permission sets per account rather than globally.
• Username immutability via console: Username cannot be changed in the IAM Identity Center console after creation; workaround requires CLI or deleting and recreating the user.
• No API to disable users: The Identity Store API supports deleting users but not disabling them; disabling requires manual console action, blocking full automation of offboarding workflows.
• Active sessions persist after disable/delete: Disabling or deleting a user does not immediately terminate existing IAM role sessions assumed via permission sets; sessions persist until expiry (up to 12 hours) unless manually revoked via the console.
• Customer managed policies must exist in each target account: Permission sets referencing customer managed policies require those policies to be pre-created in every target AWS account, increasing operational overhead in large multi-account environments.
• No built-in inactive user report: IAM Identity Center does not expose a last-login timestamp in the console UI; identifying inactive users requires custom CloudTrail-based automation.
• AWSReservedSSO_ roles cannot be modified from IAM console: Attempting to edit permission-set-created roles directly in IAM results in an error; changes must be made exclusively through the IAM Identity Center console.

IAM Identity Center is the right choice if you are already running workloads in AWS and need centralized SSO and access governance across multiple accounts. It handles every app in your AWS portfolio through a single access portal, with no licensing cost for the identity layer itself.

It is a poor fit if your offboarding process requires instant, API-driven session termination - the 12-hour session persistence window and the absence of a programmatic disable endpoint are real operational constraints that require compensating controls (e.g., removing all permission set assignments immediately on offboarding).

Bottom line

IAM Identity Center delivers centralized, policy-driven access across every app and AWS account in your organization at no additional cost, making it the default choice for AWS-native identity management.

The permission set model is powerful but requires deliberate account-by-account assignment hygiene, and the lack of a programmatic disable endpoint means offboarding automation must rely on assignment removal rather than a clean suspend call.

Teams with complex IdP integrations - particularly Azure AD with nested groups - should validate SCIM attribute mapping carefully before rolling out at scale.