Introduction

Hello everyone, this is Akaike.

Recently, IAM Identity Center now supports multi-region configuration.
This allows you to continue accessing AWS accounts through additional regions even if the primary region experiences an outage.

https://aws.amazon.com/jp/about-aws/whats-new/2026/02/aws-iam-identity-center-multi-region-aws-account-access-and-application-deployment/

So in this article, I've set up multi-region IAM Identity Center with Okta integration for single sign-on.

Prerequisites

This article assumes you have completed the following:

• Basic integration setup between Okta and IAM Identity Center
  • Adding the AWS IAM Identity Center app to Okta
  • SAML configuration (ACS URL, Issuer URL)
  • Automatic user/group provisioning via SCIM
  • Reference: Steps for setting up single sign-on between Okta and AWS IAM Identity Center
• IAM Identity Center multi-region enablement is completed
  • Creation of multi-region KMS keys
  • Creation of replica keys
  • Adding regions to IAM Identity Center
  • Reference: [Update] AWS IAM Identity Center now supports multi-region

Note: About the KMS Key Policy for Multi-Region KMS Keys

The key policy configuration for multi-region KMS keys was a bit complex, so I'll provide additional information.
If you've already configured this, feel free to skip this section.

Minimum Required Key Policy

The minimum key policy needed for multi-region IAM Identity Center appears to be as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableIAMUserPermissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<Management Account ID>:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowIAMIdentityCenterAdminToUseTheKMSKeyViaIdentityCenter",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<Management Account ID>:root"
      },
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::<Management Account ID>:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_*"
        },
        "StringLike": {
          "kms:EncryptionContext:aws:sso:instance-arn": "*",
          "kms:ViaService": "sso.*.amazonaws.com"
        }
      }
    },
    {
      "Sid": "AllowIAMIdentityCenterAdminToUseTheKMSKeyViaIdentityStore",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<Management Account ID>:root"
      },
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::<Management Account ID>:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_*"
        },
        "StringLike": {
          "kms:EncryptionContext:aws:identitystore:identitystore-arn": "*",
          "kms:ViaService": "identitystore.*.amazonaws.com"
        }
      }
    },
    {
      "Sid": "AllowIAMIdentityCenterAdminToDescribeTheKMSKey",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<Management Account ID>:root"
      },
      "Action": "kms:DescribeKey",
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::<Management Account ID>:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_*"
        }
      }
    },
    {
      "Sid": "AllowIAMIdentityCenterToUseTheKMSKey",
      "Effect": "Allow",
      "Principal": {
        "Service": "sso.amazonaws.com"
      },
      "Action": [
        "kms:Decrypt",
        "kms:ReEncryptTo",
        "kms:ReEncryptFrom",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:EncryptionContext:aws:sso:instance-arn": "*"
        },
        "StringEquals": {
          "aws:SourceAccount": "<Management Account ID>"
        }
      }
    },
    {
      "Sid": "AllowIdentityStoreToUseTheKMSKey",
      "Effect": "Allow",
      "Principal": {
        "Service": "identitystore.amazonaws.com"
      },
      "Action": [
        "kms:Decrypt",
        "kms:ReEncryptTo",
        "kms:ReEncryptFrom",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:EncryptionContext:aws:identitystore:identitystore-arn": "*"
        },
        "StringEquals": {
          "aws:SourceAccount": "<Management Account ID>"
        }
      }
    },
    {
      "Sid": "AllowIAMIdentityCenterAndIdentityStoreToDescribeKMSKey",
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "identitystore.amazonaws.com",
          "sso.amazonaws.com"
        ]
      },
      "Action": "kms:DescribeKey",
      "Resource": "*"
    }
  ]
}

Required Tasks

After enabling multi-region for IAM Identity Center, the following configurations are necessary to make SSO function in additional regions.
Basically, I just needed to add the ACS URL to the Okta configuration to enable access.

In the official documentation, this corresponds to "Step 3: Update external IdP setup".

https://docs.aws.amazon.com/singlesignon/latest/userguide/replicate-to-additional-region.html#update-external-idp-setup

State Before Configuration

As expected, before configuration, accessing the secondary region's access portal URL results in the following error:

IAM Identity Center Side

Getting the ACS URL

After enabling multi-region, you can check the ACS (Assertion Consumer Service) URL for each region.

In the IAM Identity Center console, open "Manage authentication" from the actions in the identity source.

Check from "View ACS URLs" in the "Service provider metadata" section.

Available ACS URLs have the following formats.
Note that the Alternative IPv4 format is no longer used for new instances after February 2026 and is not recommended.

https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-workforce-access.html#acs-endpoints

Checking the Portal URL

Let's also check the portal URL for additional regions.
You can view it from "Show portal URLs" in the "Service provider metadata" section mentioned earlier.

The portal URL format also differs by region, and in additional regions, only the Alternative IPv4 or Dual-stack portal URL formats are available.

https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-workforce-access.html#portal-endpoints

Okta Side

Adding the ACS URL

Register the obtained ACS URL in Okta.

From the Okta admin console, open the AWS IAM Identity Center Okta app and edit "Authentication" > "Sign-on settings" > "Sign-on methods".

The primary region is registered in "AWS SSO ACS URL", so you can register secondary regions in "AWS SSO ACS URL1 ~" and so on.
(I was surprised to find out that you can register up to 17 AWS SSO ACS URLs)

Verification

Let's verify that it works.

When opening the secondary region (ap-northeast-3) access portal URL, Okta authentication is requested first, and after that's completed, I can successfully access the secondary (ap-northeast-3) access portal.

Success!

For normal access through the user access portal login:

It connects directly to the primary (ap-northeast-1) access portal.
There's no option to choose which region to access.

This relates to how SAML authentication is configured in Okta.
When signing in from Okta to AWS, Okta sends the SAML assertion to the default ACS URL (AWS SSO ACS URL).
Therefore, additional region ACS URLs (AWS SSO ACS URL1 ~) are merely requestable URLs, not defaults.

As a result, users aren't shown region choices and always connect to the primary region portal.

Bookmarking Portal URLs (Optional)

As mentioned earlier, you can't set multiple portal URLs in Okta's AWS IAM Identity Center app.

Therefore, for direct access to additional region portals, it's good to provide users with this information in advance so they can bookmark it.
This allows users to access additional region portals directly.

In actual operations, including this information in user guidelines or documentation would be helpful.

Consideration: IdP-side Outages

While this multi-region configuration improves resilience against IAM Identity Center regional outages, we still need to consider outages on the IdP side (in this case, Okta).

Okta guarantees 99.99% uptime, so the risk of IdP outages could be considered low.

https://www.okta.com/ja-jp/blog/product-innovation/99-point-99-percent-uptime-for-all1/

However, if you want to ensure AWS access even during IdP outages, you should separately consider a Break Glass (emergency access) mechanism.

https://zenn.dev/cscloud_blog/articles/idp-break-glass-access
https://dev.classmethod.jp/articles/simple-breakglass-arch/
https://dev.classmethod.jp/articles/how-to-switch-to-the-awscontroltowerexecution-role/

Conclusion

I've summarized the configuration for single sign-on between multi-region AWS IAM Identity Center and Okta.

The work on the Okta side was just adding the ACS URL, so it was surprisingly simple.
As far as I tested, this could be configured without affecting existing single sign-on, which should make implementation easier to coordinate.

I hope this article is helpful to someone.