developersIO
マルチリージョンのIAM Identity CenterとOktaを連携してシングルサインオンしてみた

マルチリージョンのIAM Identity CenterとOktaを連携してシングルサインオンしてみた

AWSAWS IAM Identity CenterOkta
FacebookHatena blogX
2026.02.05

はじめに

皆様こんにちは、あかいけです。

先日、IAM Identity Centerがマルチリージョン構成に対応しましたね。
これにより、プライマリリージョンで障害が発生した場合でも、追加リージョン経由でAWSアカウントへのアクセスを継続できるようになりました。

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

というわけで今回は、
マルチリージョンのIAM Identity CenterとOktaを連携してシングルサインオンできるようにしてみました。

前提条件

この記事では以下が完了していることを前提としています。

補足：マルチリージョンKMSキーのKMSキーポリシーについて

マルチリージョンKMSキーのキーポリシーの設定がちょっと複雑だったので補足します。
設定済みの方は読み飛ばしてください。

最低限必要なキーポリシー

マルチリージョンのIAM Identity Centerにて使うにあたり、最低限必要そうなキーポリシーは以下の通りでした。

キーポリシー
ステートメント 用途
EnableIAMUserPermissions キーポリシーの管理権限
AllowIAMIdentityCenterAdminToUseTheKMSKeyViaIdentityCenter IAM Identity Center管理者用(暗号化操作)
AllowIAMIdentityCenterAdminToUseTheKMSKeyViaIdentityStore Identity Store管理者用(暗号化操作)
AllowIAMIdentityCenterAdminToDescribeTheKMSKey IAM Identity Center管理者用(DescribeKey)
AllowIAMIdentityCenterToUseTheKMSKey IAM Identity Centerサービス用(暗号化操作)
AllowIdentityStoreToUseTheKMSKey Identity Storeサービス用(暗号化操作)
AllowIAMIdentityCenterAndIdentityStoreToDescribeKMSKey サービス用(DescribeKey) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableIAMUserPermissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<管理アカウントID>:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowIAMIdentityCenterAdminToUseTheKMSKeyViaIdentityCenter",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<管理アカウントID>:root"
      },
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::<管理アカウント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::<管理アカウントID>:root"
      },
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKeyWithoutPlaintext"
      ],
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::<管理アカウント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::<管理アカウントID>:root"
      },
      "Action": "kms:DescribeKey",
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::<管理アカウント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": "<管理アカウント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": "<管理アカウントID>"
        }
      }
    },
    {
      "Sid": "AllowIAMIdentityCenterAndIdentityStoreToDescribeKMSKey",
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "identitystore.amazonaws.com",
          "sso.amazonaws.com"
        ]
      },
      "Action": "kms:DescribeKey",
      "Resource": "*"
    }
  ]
}

なお上記は、「IAM Identity Centerの管理アカウントはAWS 組織管理アカウントのみ」記載していますが、
委任された管理アカウントがある場合はそちらも記載が必要です。

https://docs.aws.amazon.com/singlesignon/latest/userguide/baseline-KMS-key-policy.html
https://docs.aws.amazon.com/singlesignon/latest/userguide/advanced-kms-policy.html

必要な作業について

IAM Identity Centerのマルチリージョン有効化後、追加リージョンでのSSOを機能させるには以下の設定が必要です。
基本的にはACS URLをOkta側の設定で追加するだけで、アクセスはできるようになりました。

設定項目 設定対象 作業内容
ACS URLの取得 IAM Identity Center Oktaに登録するSAMLエンドポイントの取得
ACS URLの追加 Okta 追加リージョンへの直接サインインを有効化
ポータルURLの登録
(任意)		 ブラウザ 追加リージョンのポータルへのショートカット

公式ドキュメントだと、「Step 3: Update external IdP setup」が該当します。

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

設定前の状態

当たり前ですが、設定前はセカンダリリージョンのアクセスポータルURLにアクセスしても、
以下のエラーが出ます。

スクリーンショット 2026-02-05 1.18.51

IAM Identity Center側

ACS URLの取得

マルチリージョン有効化後、各リージョンのACS(Assertion Consumer Service)URLを確認できるようになります。

IAM Identity Centerコンソールのアイデンティティソースのアクションから「認証の管理」を開きます。

スクリーンショット 2026-02-05 1.39.12

「サービスプロバイダーのメタデータ」の「ACSのURLを表示」から確認します。

スクリーンショット 2026-02-05 1.39.31

利用できるACS URLには以下の形式があります。
なおAlternative IPv4形式は2026年2月以降の新規インスタンスでは使用されておらず、非推奨のようです。

タイプ プライマリリージョン 追加リージョン URL形式
IPv4 only ○ ○ https://[Region].signin.aws/platform/saml/acs/[Tenant ID]
Alternative IPv4 only ○ × https://[Region].signin.aws.amazon.com/platform/saml/acs/[Tenant ID]
Dual-stack ○ ○ https://[Region].sso.signin.aws/platform/saml/acs/[Tenant ID]

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

ポータルURLの確認

追加リージョンのポータルURLも確認しておきます。
前述の「サービスプロバイダーのメタデータ」の「ポータルURLを表示」から見れます。

またポータルURLの形式もリージョンによって異なり、
追加リージョンではAlternative IPv4またはDual-stack形式のポータルURLのみ使用可能です。

タイプ プライマリリージョン 追加リージョン URL例
Classic IPv4 ○ × https://d-12345678.awsapps.com/start
Custom alias ○ × https://mycompany.awsapps.com/start
Alternative IPv4 ○ ○ https://ssoins-111111h2222j33pp.ap-northeast-1.portal.amazonaws.com
Dual-stack ○ ○ https://ssoins-111111h2222j33pp.portal.ap-northeast-1.app.aws

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

Okta側

ACS URLの追加

取得したACS URLをOktaに登録します。

Okta管理コンソールからAWS IAM Identity CenterのOktaアプリを開いて、
「Authentication」>「Sign-on settings」>「Sign-on methods」を編集します。

「AWS SSO ACS URL」にはプライマリを登録するので、それ以降の「AWS SSO ACS URL1 ~」にセカンダリを登録すればOKです。
（このタイミングで気づいたんですが、登録できるAWS SSO ACS URLが17まであって驚きました）

スクリーンショット 2026-02-05 1.29.43

動作確認

では実際に動作確認してみます。

セカンダリリージョン(ap-northeast-3)のアクセスポータルURLを開くとまずOktaの認証が挟まり、それが終わるとちゃんとセカンダリ(ap-northeast-3)のアクセスポータルへアクセスできています。

スクリーンショット 2026-02-05 8.33.12

やったぜ。

なお通常アクセスする際の動線であるユーザーアクセスポータルからのログインの場合、

スクリーンショット 2026-02-05 8.30.50

そのままプライマリ(ap-northeast-1)のアクセスポータルにつながります。
どのリージョンにアクセスするか、みたいな選択肢は出てこないようです。

スクリーンショット 2026-02-05 8.31.59

これはOktaで設定するSAML認証の仕組みが関係しているようです。
まずOktaからAWSへのサインイン時、OktaはデフォルトのACS URL(AWS SSO ACS URL)にSAMLアサーションを送信します。
そのため追加リージョンのACS URL(AWS SSO ACS URL1 ~)は、あくまでリクエスト可能なURLであり、デフォルトではありません。

結果として、ユーザーにリージョン選択肢は表示されず、常にプライマリリージョンのポータルに接続されるみたいです。

ポータルURLのブックマーク登録(任意)

前述の通りOktaのAWS IAM Identity Centerアプリでは、ポータルURLを複数設定することはできません。

そのため、追加リージョンのポータルに直接アクセスしたい場合のURLについて、利用者に事前に情報連携しておき、ブックマークに登録しておくのが良さそうです。
これにより、利用者は直接追加リージョンのポータルにアクセスできます。

実際の運用を考えると、どこかの利用者向けのガイドラインやドキュメントに書いておく、とかもでいいかなと思います。

考慮事項：IdP側の障害について

今回のマルチリージョン設定により、IAM Identity Center側のリージョン障害に対する耐障害性は向上しました。
一方で、IdP側(今回であればOkta)の障害については引き続き考慮が必要です。

Oktaの場合は稼働率99.99%を保証しているため、IdP障害のリスクは低いと判断することもできます。

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

ただし、IdP障害時にもAWSへアクセスできるようにしたい場合は、Break Glass(緊急アクセス)の仕組みを別途検討する必要があります。

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/

さいごに

以上、マルチリージョンのAWS IAM Identity CenterとOktaを連携してシングルサインオンする設定についてまとめました。

Okta側で実施した作業はACS URLを追加しただけだったので、思いの外簡単に作業できました。
また私が検証した限りは既存のシングルサインオンに影響を与えずに設定できたので、導入時も作業調整がしやすそうです。

この記事が誰かのお役に立てば幸いです。

この記事をシェアする

FacebookHatena blogX

関連記事

異なるVPC上のEC2からAmazon FSx for OpenZFS MultiAZをマウントしてみた
asano haruki
2026.02.05
ALB の後ろに API Gateway を配置する構成を組んでみた
kazuki yakame
2026.02.05
Amazon Connect AIエージェントタイプごとに利用可能な変数をまとめてみた
平井裕二
2026.02.05
[アップデート] AWS IAM Identity Center がマルチリージョンをサポートしました
いわさ
2026.02.04