Prerequisites and considerations - AWS IAM Identity Center

Prerequisites and considerations

The following topics provide information about prerequisites and other considerations for setting up IAM Identity Center.

Considerations for choosing an AWS Region

You can enable an IAM Identity Center instance in a single, supported AWS Region of your choice. Choosing a Region requires an assessment of your priorities based on your use cases and company policies. Access to AWS accounts and cloud applications from your IAM Identity Center doesn't depend on this choice; however, access to AWS managed applications and the ability to use AWS Managed Microsoft AD as the identity source can depend on this choice. Refer to AWS IAM Identity Center endpoints and quotas in the AWS General Reference for a list of Regions that IAM Identity Center supports.

Key considerations for choosing an AWS Region.

  • Geographical location – When you select a Region that is geographically closest to the majority of your end users, they'll have lower latency of access to the AWS access portal and AWS managed applications, such as Amazon SageMaker Studio.

  • Availability of AWS managed applications – AWS managed applications, such as Amazon SageMaker, can operate only in the AWS Regions they support. Enable IAM Identity Center in a Region supported by the AWS managed application(s) you want to use with it. Many AWS managed applications can also operate only in the same Region where you enabled IAM Identity Center.

  • Digital sovereignty – Digital sovereignty regulations or company policies may mandate the use of a particular AWS Region. Consult with your company’s legal department.

  • Identity source – If you’re using AWS Managed Microsoft AD or AD Connector as the identity source, its home Region must match the AWS Region in which you enabled IAM Identity Center.

  • Regions disabled by default – AWS originally enabled all new AWS Regions for use in AWS accounts by default, which automatically enabled your users to create resources in any Region. Now when AWS adds a new Region, its use is disabled by default in all accounts. If you deploy IAM Identity Center in a Region disabled by default, then you must enable this Region in all the accounts for which you want to manage access to IAM Identity Center. This is required even if you don’t plan to create any resources in that Region in those accounts.

    You can enable a Region for the current accounts in your organization and you must repeat this action for new accounts you might add later. For instructions, see Enable or disable a Region in your organization in the AWS Organizations user guide. To avoid repeating these additional steps, you can choose to deploy your IAM Identity Center in a Region enabled by default. For reference, the following Regions are enabled by default:

    • US East (Ohio)

    • US East (N. Virginia)

    • US West (Oregon)

    • US West (N. California)

    • Europe (Paris)

    • South America (São Paulo)

    • Asia Pacific (Mumbai)

    • Europe (Stockholm)

    • Asia Pacific (Seoul)

    • Asia Pacific (Tokyo)

    • Europe (Ireland)

    • Europe (Frankfurt)

    • Europe (London)

    • Asia Pacific (Singapore)

    • Asia Pacific (Sydney)

    • Canada (Central)

    • Asia Pacific (Osaka)

  • Cross-Region calls – In some Regions, IAM Identity Center may call Amazon Simple Email Service in a different Region to send email. In these cross-Region calls, IAM Identity Center sends certain user attributes to the other Region. For more information about Regions, see AWS IAM Identity Center Region availability.

Switching AWS Regions

You can switch your IAM Identity Center Region only by deleting the current instance and creating a new instance in another Region. If you already enabled an AWS managed application with your existing instance, you should delete it first before deleting your IAM Identity Center. You must recreate users, groups, permission sets, applications, and assignments in the new instance. You can use the IAM Identity Center account and application assignment APIs to get a snapshot of your configuration and then use that snapshot to rebuild your configuration in a new Region. You may also need to recreate some IAM Identity Center configuration through the Management Console of your new instance. For instructions on deleting IAM Identity Center, see Delete your IAM Identity Center instance.

Quota for IAM roles created by IAM Identity Center

IAM Identity Center creates IAM roles to give users permissions to resources. When you assign a permission set, IAM Identity Center creates corresponding IAM Identity Center- controlled IAM roles in each account, and attaches the policies specified in the permission set to those roles. IAM Identity Center manages the role, and allows the authorized users you’ve defined to assume the role, by using the AWS access portal or AWS CLI. As you modify the permission set, IAM Identity Center ensures that the corresponding IAM policies and roles are updated accordingly.

If you've already configured IAM roles in your AWS account, we recommend that you check whether your account is approaching the quota for IAM roles. The default quota for IAM roles per account is 1000 roles. For more information, see IAM object quotas.

If you're nearing the quota, consider requesting a quota increase. Otherwise, you might experience problems with IAM Identity Center when you provision permission sets to accounts that have exceeded the IAM role quota. For information about how to request a quota increase, see Requesting a quota increase in the Service Quotas User Guide.

Note

If you are reviewing IAM roles in an account that's already using IAM Identity Center, you might notice role names beginning with “AWSReservedSSO_”. These are the roles which the IAM Identity Center service has created in the account, and they came from assigning a permission set to the account.

IAM Identity Center and AWS Organizations

AWS Organizations is recommended, but not required, for use with IAM Identity Center. If you haven't set up an organization, you don't have to. When you enable IAM Identity Center, you will choose whether to enable the service with AWS Organizations. When you set up an organization, the AWS account that sets up the organization becomes the management account of the organization. The root user of the AWS account is now the owner of the organizational management account. Any additional AWS accounts you invite to your organization are member accounts. The management account creates the organizations resources, organizational units, and policies that manage the member accounts. Permissions are delegated to member accounts by the management account.

Note

We recommend that you enable IAM Identity Center with AWS Organizations, which creates an organization instance of IAM Identity Center. An organization instance is our recommended best practice because it supports all features of IAM Identity Center and provides central management capabilities. For more information, see Manage organization and account instances of IAM Identity Center.

If you've already set up AWS Organizations and are going to add IAM Identity Center to your organization, make sure that all AWS Organizations features are enabled. When you create an organization, enabling all features is the default. For more information, see Enabling all features in your organization in the AWS Organizations User Guide.

To enable IAM Identity Center, you must sign in to the AWS Management Console by signing in to your AWS Organizations management account as a user that has administrative credentials or as the root user(not recommended unless no other administrative users exist). You can't enable IAM Identity Center while signed in with administrative credentials from an AWS Organizations member account. For more information, see Creating and managing an AWS Organization in the AWS Organizations User Guide.