# Using IAM Identity Center across multiple AWS Regions
This topic explains how to use AWS IAM Identity Center across multiple AWS Regions. Learn how to replicate your instance to additional Regions, manage workforce access and sessions, deploy applications, and maintain account access during service disruptions.
When you enable an organization instance of IAM Identity Center, you choose a single AWS Region (primary Region). You can replicate this instance to additional AWS Regions if it meets certain prerequisites. IAM Identity Center automatically replicates workforce identities, permission sets, user and group assignments, sessions, and other metadata from the primary Region to the chosen additional Regions.
## Benefits of multi-Region support
Replicating IAM Identity Center to additional AWS Regions provides two key benefits:
+ **Improved resiliency of AWS account access** – Your workforce can access their AWS accounts even if the IAM Identity Center instance experiences a service disruption in its primary Region. This applies to access with permissions provisioned before the disruption.
+ **Enhanced flexibility in choosing deployment Regions for AWS managed applications** – You can deploy AWS managed applications in your preferred Regions to meet application data residency requirements and improve performance through proximity to users. Applications deployed in additional Regions access replicated workforce identities locally for optimal performance and reliability.
## Prerequisites and considerations
Before you replicate your IAM Identity Center instance, ensure the following requirements are met:
+ **Instance type** - Your IAM Identity Center instance must be an [organization instance](organization-instances-identity-center.md). Multi-Region support is not available in [ account instances](account-instances-identity-center.md).
+ **Identity source** - Your IAM Identity Center instance must be connected to an external identity provider (IdP), such as [https://www.okta.com/](https://www.okta.com/). Multi-Region support is not available for instances that use [Active Directory](gs-ad.md) or the [Identity Center directory](quick-start-default-idc.md) as the identity source.
+ **AWS Regions** - Multi-Region support is available in [commercial Regions enabled by default](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html#manage-acct-regions-considerations) in your AWS account. Opt-in Regions are not currently supported.
+ **KMS key type for encryption at rest** - Your IAM Identity Center instance must be configured with a multi-Region [customer managed KMS key](https://docs.aws.amazon.com/kms/latest/cryptographic-details/basic-concepts.html). The KMS key must be located in the same AWS account as IAM Identity Center. For more information, see [Implementing customer managed KMS keys in AWS IAM Identity Center](identity-center-customer-managed-keys.md).
+ **AWS managed application compatibility** - Visit the application table in [AWS managed applications that you can use with IAM Identity Center](awsapps-that-work-with-identity-center.md) to confirm the following two application requirements:
+ All AWS managed applications that are in use by your organization must support IAM Identity Center that is configured with a customer managed KMS key.
+ The AWS managed applications that you want to deploy in additional Regions must support this type of deployment.
+ **External IdP compatibility** - To fully take advantage of multi-Region support, the external IdP must support multiple assertion consumer service (ACS) URLs. This is a SAML feature that is supported by IdPs such as Okta, Microsoft Entra ID, PingFederate, PingOne, and JumpCloud.
If you use an IdP that doesn't support multiple ACS URLs, such as Google Workspace, we recommend that you work with your IdP vendor to enable this feature. For options that are available without multiple ACS URLs, see [Using AWS managed applications without multiple ACS URLs](multi-region-workforce-access.md#aws-app-use-without-multiple-acs-urls) and [AWS account access resiliency without multiple ACS URLs](multi-region-failover.md#account-access-resiliency-without-multiple-acs-url).
## Choosing an additional Region
When choosing an additional Region among commercial Regions enabled by default, consider these factors:
+ **Compliance requirements** – If you need to run AWS managed applications that access datasets limited to a specific Region for compliance reasons, choose the Region where the datasets reside.
+ **Performance optimization** – If data residency isn't a factor, select a Region closest to your application users to optimize their experience.
+ **Application support** – Verify that your required AWS applications are available in your chosen Region.
+ **AWS account access resiliency** – For continuity of access to AWS accounts, choose a Region geographically distant from the primary Region of your IAM Identity Center instance.
**Note**
IAM Identity Center has a quota on the number of AWS Regions. For more information, see [Additional quotas](limits.md#additionallimits).
# Replicate IAM Identity Center to an additional Region
If your environment meets the [prerequisites](multi-region-iam-identity-center.md#multi-region-prerequisites), such as configuring IAM Identity Center with a multi-Region customer managed KMS key, complete the following steps to replicate your IAM Identity Center instance to an additional Region. Your primary Region continues to operate normally during and after these steps.
## Step 1: Create a replica key in the additional Region
Before replicating IAM Identity Center to a Region, you must first create a replica key of your customer managed KMS key in that Region and configure the replica key with the permissions required for the operations of IAM Identity Center. For instructions on creating multi-Region replica keys, see [Create multi-Region replica keys](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-replicate.html).
The recommended approach for the KMS key permissions is to copy the key policy from the primary key, which grants the same permissions already established for IAM Identity Center in the primary Region. Alternatively, you can define Region-specific key policies, though this approach increases the complexity of managing permissions across Regions and may require additional coordination when updating policies in the future.
**Note**
AWS KMS doesn't synchronize your KMS key policy across the Regions of your multi-Region KMS key. To keep the KMS key policy in sync across the KMS key Regions, you will need to apply changes in each Region individually.
## Step 2: Add the Region in IAM Identity Center
Adding a Region in IAM Identity Center triggers automatic replication of IAM Identity Center data to that Region. The replication is asynchronous with eventual consistency. The following tabs provide instructions for doing this in the AWS Management Console and AWS CLI.
------
#### [ Console ]
**To add a Region**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/).
1. In the navigation pane, choose **Settings**.
1. Choose the **Management** tab.
1. In the **Regions for IAM Identity Center** section, choose **Add Region**.
1. In the **AWS Regions available for replication** section, choose your preferred AWS Region. If the Region doesn't appear in the list, it's not available for replication because the KMS key hasn't been replicated there. For more information, see [Implementing customer managed KMS keys in AWS IAM Identity Center](identity-center-customer-managed-keys.md).
1. Choose **Add Region**.
1. In the **Regions for IAM Identity Center** section, monitor the Region status. Use the **Refresh** button (circular arrow) to check the latest Region status as needed. After the replication completes, proceed to Step 2.
------
#### [ AWS CLI ]
**To add a Region**
```
aws sso-admin add-region \
--instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef \
--region-name eu-west-1
```
**To check the current Region status**
```
aws sso-admin describe-region \
--instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef \
--region-name eu-west-1
```
When the Region status is ACTIVE, you can proceed to Step 2.
------
The duration of the initial replication to an additional Region depends on the amount of data in your IAM Identity Center instance. Subsequent incremental changes are replicated within seconds in most cases.
## Step 3: Update external IdP setup
Follow the tutorial for your external IdP in [IAM Identity Center identity source tutorials](tutorials.md) for the following steps:
**Step 3.a: Add the Assertion Consumer Service (ACS) URLs to your external IdP**
This step enables direct sign-in to each additional Region and is required to enable sign-in to AWS managed applications deployed in those Regions and for access to AWS accounts through those Regions. To learn where to find the ACS URLs, see [ACS endpoints in the primary and additional AWS Regions](multi-region-workforce-access.md#acs-endpoints).
**Step 3.b (Optional): Make the AWS access portal available in the external IdP portal**
Make the AWS access portal in the additional Region available as a bookmark app in the external IdP portal. Bookmark apps contain only a link (URL) to the desired destination and are similar to a browser bookmark. You can find the AWS access portal URLs in the console by choosing **View all AWS access portal URLs** in the **Regions for IAM Identity Center** section. For more information, see [AWS access portal endpoints in the primary and additional AWS Regions](multi-region-workforce-access.md#portal-endpoints).
IAM Identity Center supports IdP-initiated SAML SSO in each additional Region, but external IdPs typically support this with only a single ACS URL. For continuity, we recommend keeping the primary Region's ACS URL in use for IdP-initiated SAML SSO and relying on bookmark apps and browser bookmarks for access to additional Regions.
## Step 4: Confirm firewall and gateway allow-lists
Review your domain allow-lists in firewalls or gateways, and update them based on the [documented allow-lists](enable-identity-center-portal-access.md).
## Step 5: Provide information to your users
Provide your users with information about the new setup, including the AWS access portal URL in the additional Region and how to use the additional Regions. Review the following sections for relevant details:
+ [Workforce access through an additional Region](multi-region-workforce-access.md)
+ [Failover to an additional Region for AWS account access](multi-region-failover.md)
+ [Deploying and managing applications across multiple AWS Regions](multi-region-application-use.md)
## Region changes beyond adding the first Region
You can add and remove additional Regions. The primary Region cannot be removed other than by deleting the entire IAM Identity Center instance. For more information on removing a Region, see [Remove a Region from IAM Identity Center](remove-region.md).
You cannot promote an additional Region to be the primary or demote the primary Region to be additional.
## What data is replicated?
IAM Identity Center replicates the following data:
| Data | Replication source and target |
| --- | --- |
| Workforce identities (users, groups, group memberships) | From the primary Region to the additional Regions |
| Permission sets and their assignments to users and groups | From the primary Region to the additional Regions |
| Configuration (such as external IdP SAML settings) | From the primary Region to the additional Regions |
| Application metadata and application assignments to users and groups | From an application's connected IAM Identity Center Region to the other enabled Regions |
| Trusted token issuers | From the primary Region to the additional Regions |
| Sessions | From the session's originating Region to the other enabled Regions |
**Note**
IAM Identity Center doesn't replicate data stored in AWS managed applications. Also, it doesn't change the regional footprint of an application deployment. For example, if your IAM Identity Center instance in in US East (N. Virginia), and you have Amazon Redshift deployed in the same Region, replicating IAM Identity Center to US West (Oregon) doesn't affect the deployment Region of Amazon Redshift and the data it stores.
**Considerations:**
+ **Global resource identifiers across enabled Regions** - Users, groups, permission sets, and other resources have the same identifiers across the enabled Regions.
+ **Replication doesn't affect provisioned IAM roles** - Existing IAM roles provisioned from permission set assignments are used during account sign-in from any enabled Region.
# Workforce access through an additional Region
This section explains how your workforce can access the AWS access portal, AWS accounts, and applications when you have enabled IAM Identity Center in multiple Regions.
The AWS access portal in an additional Region displays the AWS accounts and applications your workforce has access to in the same way as in the primary Region. Your workforce can sign into the AWS access portal in an additional Region through a direct link to the regional portal endpoint (for example, `https://ssoins-111111h2222j33pp.eu-west-1.portal.amazonaws.com`) or through a [bookmark app](replicate-to-additional-region.md#update-external-idp-setup) you set up in the external IdP.
You can use the AWS access portal endpoint in an additional Region to authorize the AWS CLI for access to APIs as an IAM Identity Center user. This functionality works in the same way as in the primary Region. However, CLI authorizations are not replicated across enabled Regions. Therefore, you have to authorize the CLI in each Region individually.
## User sessions across multiple AWS Regions
IAM Identity Center replicates user sessions from the originating Region to the other enabled Regions. Session revocation and sign-out in one Region are also replicated to the other Regions.
### Session revocation by IAM Identity Center administrators
IAM Identity Center administrators can revoke user sessions in additional Regions. As sessions are replicated across Regions, under normal conditions it suffices to revoke a session in a single Region and let IAM Identity Center replicate the change to the other enabled Regions. If the primary Region of IAM Identity Center has a disruption, administrators can perform this operation in additional Regions.
## AWS access portal endpoints in the primary and additional AWS Regions
If you need to look up the AWS access portal URLs for the enabled Regions, follow these steps:
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/).
1. In the navigation pane, choose **Settings**.
1. Choose the **Management** tab.
1. In the **Regions for IAM Identity Center** section, choose **View all AWS access portal URLs**.
The following table specifies the AWS access portal endpoints across the primary and additional Regions of an IAM Identity Center instance.
| AWS access portal endpoint | Primary Region | Additional Region | URL pattern and example |
| --- | --- | --- | --- |
| Classic IPv4 only1 | Yes | No | **Pattern:** `https://[Identity Store ID].awsapps.com/start` **Example:** `https://d-12345678.awsapps.com/start` |
| Custom-alias IPv4 only1 | Yes (optional) | No | **Pattern:** `https://[custom alias].awsapps.com/start` **Example:** `https://mycompany.awsapps.com/start` |
| Alternative IPv4 only2 | Yes | Yes | **Pattern:** `https://[Identity Center instance ID]. [Region].portal.amazonaws.com` **Example:** `https://ssoins-111111h2222j33pp.eu-west-1.portal.amazonaws.com` |
| Dual-stack2 | Yes | Yes | **Pattern:** `https://[Identity Center instance ID].portal. [Region].app.aws` **Example:** `https://ssoins-111111h2222j33pp.portal.eu-west-1.app.aws` |
1 In additional Regions, the custom alias is not supported, and the `awsapps.com` parent domain is not available.
2 The alternative IPv4 only and dual-stack portal endpoints don't have the trailing `/start` in the URL.
## Assertion Consumer Service (ACS) endpoints in the primary and additional AWS Regions
If you need to look up the ACS URLs or download them as part of the SAML metadata, follow these steps:
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/).
1. In the navigation pane, choose **Settings**.
1. Choose the **Identity source** tab.
1. In the **Actions** dropdown menu, choose **Manage authentication**.
1. The **Service provider metadata** section displays the AWS access portal and ACS URL for each enabled Region. IPv4-only and dual-stack URLs are displayed on separate tabs. If your IdP supports uploading a SAML metadata file, you can choose **Download metadata file** to download the SAML metadata file with all ACS URLs. If your IdP does not support uploading a metadata file, or you prefer to add ACS URLs individually, you can copy individual URLs from the table in the console, or choose **View ACS URLs** and then **Copy all URLs**. Retain the ACS URL that is already configured for the primary Region to ensure that service provider-initiated SAML single sign-on from the primary Region remains functional.
The following table specifies the SAML Assertion Consumer Service (ACS) endpoints across the primary and additional Regions of an IAM Identity Center instance:
| ACS endpoint | Primary Region | Additional Region | URL pattern and example |
| --- | --- | --- | --- |
| IPv4 only | Yes | Yes | **Pattern:** `https://[Region].signin.aws/platform/saml/acs/[Tenant ID]` **Example:** ` https://us-west-2.signin.aws/platform/saml/acs/1111111111111111-aaee-ffff-dddd-11111111111` |
| Alternative IPv4 only\$1 | Yes | No | **Pattern:** `https://[Region] .signin.aws.amazon.com/platform/saml/acs/[Tenant ID]` **Example:** ` https://us-west-2.signin.aws.amazon.com/platform/saml/acs/1111111111111111-aaee-ffff-dddd-11111111111` |
| Dual-stack | Yes | Yes | **Pattern:** `https://[Region].sso.signin.aws/platform/saml/acs/[Tenant ID]` **Example:** ` https://us-west-2.sso.signin.aws/platform/saml/acs/1111111111111111-aaee-ffff-dddd-11111111111` |
\$1 For instances that were enabled before February 2026, retain this endpoint because service provider-initiated SAML single sign-on to the primary Region requires it. IAM Identity Center does not use this endpoint for instances that were enabled in February 2026 or later.
## Using AWS managed applications without multiple ACS URLs
Some external identity providers (IdPs) don't support multiple assertion consumer service (ACS) URLs in their IAM Identity Center application. Multiple ACS URLs are a SAML feature that is required for direct sign-in to a specific Region in a multi-Region IAM Identity Center.
For example, if you launch an AWS managed application through an application link, the system triggers sign-in through the application's connected IAM Identity Center Region. However, if the ACS URL for that Region is not configured in the external IdP, the sign-in fails.
To resolve this issue, work with your IdP vendor to enable support for multiple ACS URLs. In the meantime, you can still use AWS managed applications in additional Regions. First, sign into the Region whose ACS URL is configured in the external IdP (the primary Region by default). After you have an active session in IAM Identity Center, you can launch the application from the AWS access portal in any enabled Region, or through an application link.
# Failover to an additional Region for AWS account access
The topic of AWS account access through IAM Identity Center is covered extensively in [Configure access to AWS accounts](manage-your-accounts.md). This section provides additional details relevant to maintaining AWS account access across multiple AWS Regions in the event of a service disruption in the primary Region.
If your IAM Identity Center instance experiences a disruption in the primary Region (for example, the AWS access portal in the primary Region is unavailable), your workforce can switch to an additional Region to continue accessing AWS accounts and unaffected applications. For more information, see [Workforce access through an additional Region](multi-region-workforce-access.md).
We recommend that you communicate the AWS access portal endpoints in additional Regions and the external IdP setup (such as bookmark apps for the additional Regions) to your workforce as soon as you complete the setup in [Replicate IAM Identity Center to an additional Region](replicate-to-additional-region.md). This will enable them to be ready for failover to an additional Region if needed.
Similarly, we recommend that AWS CLI users create [AWS CLI profiles](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) for additional Regions for each of the profiles they have for the primary Region. Then, they can switch to that profile if there is a service disruption in the primary Region.
**Note**
Continuity of access to AWS accounts also depends on the health of your external IdP and permissions such as permission set assignments and group memberships being provisioned and replicated before a service disruption. We recommend your organization also set up [AWS break-glass access](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/ag.sad.5-implement-break-glass-procedures.html) to maintain AWS access to a small group of privileged users when the external IdP has a service disruption. [Emergency access](emergency-access.md) is a similar option that avoids using IAM users, but it too depends on the external IdP.
## AWS account access resiliency without multiple ACS URLs
Some external identity providers (IdPs) don't support multiple assertion consumer service (ACS) URLs in their IAM Identity Center application. Multiple ACS URLs are a SAML feature that is required for direct sign-in to a specific Region in a multi-Region IAM Identity Center.
To enable your users to access their AWS accounts through multiple IAM Identity Center Regions, you must configure the respective regional ACS URLs in the external IdP. However, if the external IdP supports only a single ACS URL in their IAM Identity Center application, users can directly sign into a single IAM Identity Center Region.
To resolve this issue, work with your IdP vendor to enable support for multiple ACS URLs. In the meantime, you can use additional Regions as backup for access to AWS accounts.
If an IAM Identity Center service disruption occurs in the primary Region, you must update the ACS URL in the external IdP with an additional Region's ACS URL. After this update, your users can access the AWS access portal in the additional Region using the existing IAM Identity Center application in the external IdP portal, or through a direct link that you share with them.
We recommend that you test this setup periodically to ensure that it works when needed and communicate this failover process to your organization.
**Note**
When you use an additional Region for access to AWS accounts in this setup, your users might not be able to access AWS managed applications that are connected to the primary Region. Therefore, we recommend this only as a temporary measure to maintain access to AWS accounts.
# Deploying and managing applications across multiple AWS Regions
The topic of application access through IAM Identity Center is covered extensively in [Configure access to applications](manage-your-applications.md). This section provides additional details relevant to the deployment and management of applications across multiple AWS Regions.
## Deploying and managing AWS managed applications across multiple AWS Regions
With a single-Region IAM Identity Center instance, you can deploy AWS managed applications in the same Region as your instance. Some applications such as Amazon Q Business support a cross-Region connection to IAM Identity Center, which enables their deployment outside the IAM Identity Center's Region if the application of interest is available there. However, cross-Region calls can cause slower application performance, and most AWS managed applications don't support this type of connection.
A multi-Region IAM Identity Center instance lets you deploy AWS managed applications in any enabled Region with a connection to IAM Identity Center in the same Region ("Region-local connection"). Deployment in the primary Region is supported by all integrated AWS managed applications. To confirm which AWS managed applications support deployment in additional Regions of IAM Identity Center, see the applications table in [AWS managed applications that you can use with IAM Identity Center](awsapps-that-work-with-identity-center.md). In any case, the AWS managed application has to be available in the Region where you want to deploy it.
With a Region-local connection to IAM Identity Center, AWS managed applications access workforce identities in the same Region for optimal performance and reliability. We recommend choosing a Region-local connection when deploying an AWS managed application whenever the [prerequisites](multi-region-iam-identity-center.md#multi-region-prerequisites) are met.
To deploy an AWS managed application in an additional Region of IAM Identity Center, start the deployment in that Region through the application console or API in the same way that you deploy in the primary Region.
**Considerations:**
+ If you haven't replicated your IAM Identity Center to that Region yet, we recommend that you do this first so that the application deployment can complete right away.
+ AWS managed applications will, in many cases, automatically establish a Region-local connection if you've already replicated IAM Identity Center to the Region.
+ If an AWS managed application offers a cross-Region connection to IAM Identity Center, we recommend that you choose a Region-local connection provided that the [prerequisites](multi-region-iam-identity-center.md#multi-region-prerequisites) are met.
+ If the application doesn't support deployment in additional Regions, you can deploy it in the primary Region provided that the application is available there.
**Important**
If your IAM Identity Center instance is multi-regional, all AWS managed applications in use by your organization must support IAM Identity Center configured with a customer-managed KMS key regardless of the application deployment Region. Confirm this in the [AWS managed applications that you can use with IAM Identity Center](awsapps-that-work-with-identity-center.md) before deploying an application and before configuring a customer-managed KMS key in your IAM Identity Center.
### An application's management Region
After you deploy an AWS managed application in an additional Region of IAM Identity Center using a Region-local connection, you manage the application and its assignments to users and groups in the same Region. IAM Identity Center replicates the application metadata including assignments to users and groups to other enabled Regions so that your workforce can launch applications from any enabled Region.
If your AWS managed application is using a cross-Region connection to IAM Identity Center, you can manage the application details such as name and description, and application assignments to users and groups through IAM Identity Center console and API in the connected Region. Regardless of the connection type, you can manage the application through its console in its deployment Region.
### Trusted identity propagation
You can use trusted identity propagation with AWS managed applications that support it in any enabled Region of your IAM Identity Center instance.
All applications that propagate identity context to each other must be in the same Region.
### An application’s dependency on its connected IAM Identity Center Region
Each AWS managed application connects to a specific IAM Identity Center Region during deployment. The application then depends on that Region for user sign-in, even if your IAM Identity Center is enabled in multiple Regions. If your IAM Identity Center is experiencing a disruption in that Region, users might not be able to access AWS managed applications connected to the Region.
## Deploying and managing customer managed applications across multiple AWS Regions
IAM Identity Center supports SAML and OAuth2 [customer managed applications](customermanagedapps.md). You can choose to create them in any enabled Region of your IAM Identity Center instance. After you create one, you manage the application and its assignments to users and groups in the same Region.
# Remove a Region from IAM Identity Center
To remove an additional Region from your IAM Identity Center instance, follow these steps:
## Step 1: Update external IdP configuration
You can choose to remove the ACS URL for this Region from your external IdP or keep it in case you want to add this Region again later. We recommend that you remove or hide the bookmark app you might have created for the AWS access portal in this Region.
## Step 2: Remove the Region
------
#### [ Console ]
**To add a Region**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/).
1. In the navigation pane, choose **Settings**.
1. Choose the **Management** tab.
1. In the **Regions for IAM Identity Center** section, choose the additional Region you want to remove.
1. Choose **Remove**.
1. Before confirming removal by choosing **Remove Region**, pay attention to the warning about the potential loss of access to applications that were created in this IAM Identity Center Region. If you're not sure whether you have such applications, choose **Applications** in the navigation pane and confirm the connected Region in the **Created from** column for each AWS managed and customer managed application.
**Note**
You may continue incurring charges for deployments of AWS managed applications that are still connected to the removed Region even if you lose access to these applications. To prevent this, you need to remove these AWS managed application deployments through the application console or API before removing the Region in IAM Identity Center. If you already removed the IAM Identity Center Region, you can restore access to applications by adding the Region back.
1. In the **Regions for IAM Identity Center** section, monitor the Region status. Use the **Refresh** button (circular arrow) to see the latest Region status as needed. After the Region is removed, the Region no longer appears in the Region list.
------
#### [ AWS CLI ]
**To remove a Region**
```
aws sso-admin remove-region \
--instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef \
--region-name eu-west-1
```
**To check the current Region status**
```
aws sso-admin describe-region \
--instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef \
--region-name eu-west-1
```
When the Region is removed, proceed to Step 2.
------
## Step 3: Delete the replica key
You can choose to remove the replica key from this Region to avoid incurring KMS storage charges. For more information, see [Deleting an AWS KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html).
**Important**
Make sure to delete only the replica key in this specific Region. The other IAM Identity Center Regions continue to rely on the KMS key in the other enabled Regions for normal operations.
# IAM Identity Center service APIs supported in additional AWS Regions
| API | Functionality in additional Regions |
| --- | --- |
| [Identity Center API](https://docs.aws.amazon.com/singlesignon/latest/APIReference/welcome.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/api-support-in-additional-regions.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/api-support-in-additional-regions.html) |
| [Identity Store API](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/welcome.html) | Read operations |
| [OIDC API](https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/Welcome.html) | All operations are supported |
| [Access Portal API](https://docs.aws.amazon.com/singlesignon/latest/PortalAPIReference/Welcome.html) | All operations are supported |
| [SCIM API](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) | No operation is supported |
# AWS CloudTrail events of IAM Identity Center in the primary and additional Region
In AWS CloudTrail, you can audit actions that IAM Identity Center users and administrators take across all enabled AWS Regions of your IAM Identity Center instance. The AWS CloudTrail events are emitted and logged in the Region where the action takes place. For more information, see [Logging and monitoring in IAM Identity Center](security-logging-and-monitoring.md).
# Availability of IAM Identity Center use cases in the primary and additional Regions
| Feature | Regional availability |
| --- | --- |
| Workforce directory with a user portal | |
| User access to the AWS access portal including portal sign-in and global sessions (one sign-in for all Regions) | All enabled Regions |
| Display of all assigned accounts | All enabled Regions |
| Display of all assigned applications (regardless of where the applications were created) | All enabled Regions |
| Read access to users, groups, and memberships in the AWS Console or via Identity Store APIs | All enabled Regions |
| Revoke user sessions | All enabled Regions |
| Automatic synchronization of users and groups from an external identity source such as external IdP through SCIM API or Identity Store API | Primary Region only |
| Configure automatic identity provisioning with SCIM | Primary Region only |
| Configure SAML SSO with an external IdP | Primary Region only - read access through the console in all enabled Regions |
| Create/update/delete operations on users, groups and group memberships via the console or Identity Store APIs. | Primary Region: available via Identity Store API but blocked in the IAM Identity Center console when SCIM API is used for provisioning (except disable/enable user access and delete user, which are always available). Additional Regions: unavailable |
| Multi-account access | |
| Access assigned accounts via the AWS access portal, AWS CLI, and shortcut links | All enabled Regions |
| Manage multi-account permission sets and their assignments in the console and APIs (including temporary elevated access) | Primary Region only |
| Access to applications and AWS services | |
| Deploy AWS managed applications through the application console and APIs | All enabled Regions – subject to applications' regional availability and support for deployment in additional Regions |
| Create customer managed applications through the Identity Center console and APIs | All enabled Regions |
| Manage application metadata and assignments in the console and APIs | Application's connected IAM Identity Center Region |
| Launch applications from the AWS access portal or directly via an application link or bookmark | All enabled Regions |
| SSO to Amazon EC2 instances | All enabled Regions |
| Trusted identity propagation | |
| Create a trusted token issuer | Primary Region only |
| Trusted identity propagation with AWS managed applications | All enabled Regions - Applications that propagate identity context to each other must be in the same Region |
| Other administrative features | |
| All other administrative features such as Region management, KMS key management, instance management, and session management (except session revocation) | Primary Region only - read access available in all enabled Regions for some data (permission set assignments excluded) |