AWSマルチアカウント認証の方式比較と、SAML+SCIMによる外部IdP連携手順

はじめに

NTTビジネスソリューションズの平田です。

AWSアカウントやIAMユーザーが増えると、「各AWSアカウントのIAMユーザー管理が大変」という課題にぶつかります。AWSアカウントごとにIAMユーザーを管理する運用は手間がかかるだけでなく、削除漏れや権限の棚卸しが困難になるなど、IDガバナンスの面でもリスクを抱えます。

本記事では複数AWSアカウントを保有する環境において、AWSマネジメントコンソールのユーザーを一元管理する方式の比較と、そのうちの一つ（外部IdP → IAM Identity Center連携）の導入手順を紹介します。

前半（1〜5章）は3方式の比較と選定基準、後半（6章）は方式③の導入手順です。比較だけ知りたい方は5章まで、手順を知りたい方は6章からお読みください。

本記事は2026年2月時点の情報に基づきます。

目次

対象読者

• 複数のAWSアカウントを管理するシステム管理者
• AWSのIAMとIdentity Centerについて概要的な知識をお持ちの方（AWS Certified Solutions Architect - Associateの学習経験がある方を想定）
• ID管理のガバナンスを検討中の方

前半 認証方式の比較

1. マルチアカウント環境における認証方式

AWSのベストプラクティスでは、ワークロードや環境（開発・ステージング・本番など）ごとにAWSアカウントを分離することが推奨されています。

docs.aws.amazon.com

しかしAWSアカウントを分離すると、IAMの管理が煩雑になります。なぜかというと、AWSアカウントごとにIAMユーザーやIAMグループを個別に管理する必要があるためです。例えば管理者には以下のような不便があります。

• 卒業者が出たら、全AWSアカウントからIAMユーザーを削除して回る
• 「どのAWSアカウントの誰がどの権限を持っているか」を一覧で確認が困難

ユーザーにとっても、AWSアカウントごとに認証情報が分かれます。

• AWSアカウントごとに異なるユーザー名・パスワード・MFAを管理する
• アクセスするAWSアカウントが変わるたびにサインインし直す

AWSアカウントが増えるほど、これらの管理工数とミスのリスクが増えていきます。

ユーザーの一元管理を行うことで、このような管理工数の削減やリスクを低減でき、かつユーザーの利便性が向上します。 一元管理の方式として、大きく分類すると3つあります。

方式	概要
① 外部IdP → AWSアカウント	外部のIdP（Okta、Keycloakなど）からSAMLで各AWSアカウントにログイン
② IAM Identity Center → AWSアカウント	Identity Centerの組み込みディレクトリでユーザーを管理し、許可セット（Permission Set）で各AWSアカウントへのアクセスを制御
③ 外部IdP → IAM Identity Center → AWSアカウント	外部IdPでユーザーを管理し、Identity Center経由で各AWSアカウントにアクセス

これらの方式は、いずれもIAMユーザーを各AWSアカウントに登録する必要がなく、ユーザー情報を一元管理できます。次のセクションから、それぞれの仕組みとメリットデメリットを整理します。

2. 方式①: 外部IdP → AWSアカウント（SAML連携）

SAMLとは

SAML（Security Assertion Markup Language）2.0は、認証情報や属性情報をシステム間で授受するためのプロトコルで、シングルサインオン（SSO）に利用します。IdP（Identity Provider）がユーザーを認証し、「このユーザーは認証済みです」という情報をSP（Service Provider、ここではAWSマネジメントコンソール）に伝えます。ユーザーがIdPで一度ログインすれば、SP側で再度パスワードを入力する必要がありません。

方式①の仕組み

この方式は、外部IdP（Okta、Keycloakなど）が各AWSアカウントに直接SAML連携します。

外部IdPのグループとAWSアカウントのIAMロールを1:1で紐づけます。具体的には、以下の設定を行います。

1. AWSアカウント側: IAMにIDプロバイダ（SAML）を作成し、IAMロールの信頼ポリシーでそのプロバイダを指定する
2. 外部IdP側: SAMLアサーションに「どのIAMロールを引き受けるか」（ロールARN）を含める設定を行う

ユーザーが外部IdPからログインすると、SAMLアサーションに含まれるロールARNに基づいて、対象AWSアカウントのIAMロールを引き受けます（AssumeRoleWithSAML）。

方式①のメリット

• 構成がシンプル: AWSアカウント側の設定はIAM SAMLプロバイダとIAMロールだけです。
• プロビジョニング不要: AWS側にユーザー情報を事前登録する必要がありません。外部IdPで認証に成功すれば、そのままIAMロールを引き受けられます。

方式①のデメリット

• 設定がN×Mで膨張する: AWSアカウント数（N）×ロール種類数（M）分の設定が必要です。AWSアカウント2つ、ロール2種類なら4つの設定で済みますが、AWSアカウント10×ロール5種類で50の設定になります。
• 管理が分散する: IAMロールは各AWSアカウントで個別に作成・管理するため、「どのAWSアカウントにどのロールがあるか」の全体像を把握しにくくなります。

方式①の設定例

外部IdPとしてKeycloakを利用した場合の設定例です。（外部サイト） qiita.com

3. 方式②: IAM Identity Center（組み込みディレクトリ）→ AWSアカウント

IAM Identity Centerとは

IAM Identity Center（旧AWS SSO）は、複数のAWSアカウントへのアクセスを一元管理するサービスです。ユーザーはAccess Portalという単一のサインイン画面からサインインし、アクセス権のあるAWSアカウントを選んで操作します。以下、Identity Centerと略します。

方式②の仕組み

この方式は、Identity Centerの組み込みディレクトリでユーザーとグループを管理し、許可セットによって各AWSアカウントへのアクセス権を定義します。

許可セットの仕組み

許可セットは「AWSアカウントで何ができるか」を定義するテンプレートです。IAMポリシーを含みますが、IAMロールそのものではありません。

許可セットの割り当ては3つの次元で行います。

• グループ: 誰がアクセスするか
• AWSアカウント: どのAWSアカウントにアクセスするか
• 許可セット: どの権限でアクセスするか

例えば、「DevelopersグループにPowerUserAccess権限を、開発用AWSアカウントで割り当てる」のように指定します。

この割り当てを行うと、Identity Centerが対象のAWSアカウントにIAMロールを自動生成します。生成されるIAMロールの名前は AWSReservedSSO_{PermissionSet名}_{一意のサフィックス} という形式です。

ここで重要なのは、許可セットとIAMロールの関係が1:nであることです。1つの許可セットを3つのAWSアカウントに割り当てれば、3つのIAMロールが生成されます。管理者は許可セットだけを管理すればよく、各AWSアカウントのIAMロールを手動で作る必要はありません。

方式②のメリット

• AWS内で完結: 外部サービスに依存しません。AWSアカウントがあればすぐに始められます
• 一元管理: 許可セットを一度定義すれば、複数のAWSアカウントに一括適用できます。方式①のN×M問題が発生しません
• IAMロールの自動生成: AWSアカウント側のIAMロールの作成・削除をIdentity Centerが自動で行います

方式②のデメリット

• ID管理がAWSに閉じる: 1点目のメリットの裏返しですが、ユーザー・グループをAWS内で個別管理します。組織に既存のIdP（Okta、Keycloakなど）があると、ユーザー情報を二重管理することになります
• AWS以外のアプリケーションとの統合: Identity Centerは他のSaaSへのSAML IdPにもなれますが、外部SaaSへのSSO連携は主にSAML 2.0で行います（OAuth 2.0はTrusted Identity Propagation向け）

方式②の設定例

Identity Centerを利用した場合の設定方法です。（外部サイト） docs.aws.amazon.com

この記事の後半で手順を紹介しますが、その中にも内包されています。

4. 方式③: 外部IdP → IAM Identity Center → AWSアカウント

SCIMとは

方式③では外部IdPのユーザー情報をIdentity Centerに同期する必要があります。この同期に使うプロトコルがSCIMです。
SCIM（System for Cross-domain Identity Management）は、ユーザーやグループの情報をシステム間で自動同期するためのプロトコルです。IdPでユーザーを追加・変更・削除すると、その情報がREST API経由で連携先に自動反映されます。この記事では、外部IdP（Okta）からSCIMを使ってIdentity Centerに同期します。

方式③では、SAMLとSCIMの2つのプロトコルを使います。役割が異なるので、混同しないように整理しておきます。

• SAML: 認証（ログイン時に「誰か」を伝える）
• SCIM: プロビジョニング（IdPのユーザー・グループ情報をIdentity Centerに同期する）

SAMLだけでは「Identity Centerにそのユーザーが存在しない」ためログインできません。SCIMで事前にユーザーを同期しておく必要がある、というのが方式③のポイントです。

方式③の仕組み

この方式では、外部IdPでユーザー・グループを管理し、SCIMでIdentity Centerに同期します。権限管理は方式②と同じく、Identity Centerの許可セットで行います。

方式②との違いはユーザーとグループの管理元がどこにあるか（プライマリがどこか）です。方式②ではIdentity Centerがユーザーとグループの管理元ですが、方式③では外部IdPが管理元です。Identity Center側のユーザーとグループは、IdPから同期されたコピーです。

なお、許可セット → IAMロール自動生成の仕組みは方式②と同じです。

また、Identity CenterはJIT（ジャストインタイム）プロビジョニングに対応していないため、ユーザー・グループの事前同期が必要です。SCIM対応のIdP（Okta、Entra IDなど）なら自動同期できますが、非対応のIdPの場合は手動でIdentity Centerにユーザー・グループを作成します。

方式③のメリット

• ID管理とアクセス管理の役割分担: 「誰がいるか」「誰がどのグループに所属するのか」は外部IdPが管理し、「どのAWSアカウントに、どの権限で」はIdentity Centerが管理します。責務が明確に分かれます（ID管理は外部IdP、アクセス管理はIdentity Center）
• 組織のID基盤と連携: 組織に既存のIdPがあれば、AWS用に別のユーザー管理を持つ必要がありません
• Access Portal: ユーザーは単一のサインイン画面から、アクセス権のあるAWSアカウントを選んで操作できます（このメリットは方式②にも共通）

方式③のデメリット

• プロビジョニングが必須: IdPのユーザー・グループ情報をIdentity Centerに同期する仕組み（SCIMまたは手動）が必要です
• 構成が最も複雑: 外部IdP、Identity Center、AWSアカウントの3レイヤーにまたがるため、設定・運用・トラブルシュートの範囲が広くなります
• 外部IdPの費用:AWSのコストに加え、外部IdPのコストが必要です。

正直なところ、方式③は3つの中で構成やしくみが最も複雑です。ただ、一度組み上げてしまえば「ユーザーの追加・削除はIdP側だけ」「権限の変更はIdentity Center側だけ」と作業の分担がはっきりするので、運用負担がぐっと下がります。

5. 方式選択の考え方

3方式の比較

観点	①外部IdP→AWSアカウント	②Identity Center→AWSアカウント	③外部IdP→Identity Center→AWSアカウント
ユーザー管理の場所	外部IdP	Identity Center	外部IdP
AWSアクセス管理（権限付与）	各AWSアカウントのIAM	Identity Center	Identity Center
IAMロール	手動作成（N×M）	自動生成	自動生成
プロビジョニング	不要	―	必須（SCIM/手動）
構成の複雑さ	低い	中程度	高い
AWSアカウント増加時	設定が線形に増加	許可セットで吸収	許可セットで吸収

「Identity Centerだけではダメなのか？」

方式②と③を見ると、AWSアクセスの管理はどちらもIdentity Centerが担います。Identity Centerは他のSaaSへのSAML IdPにもなれるので、「方式②だけでAWSアクセスも他アプリのSSOも、全部まかなえるのでは？」というツッコミがあると思います。

判断のポイントは以下の3つです。

1. 組織にすでにIdPがあるか: Okta、Entra IDなどのIdPをすでに運用しているなら、Identity Centerにもユーザーを作ると二重管理になります。外部IdPに接続する方がID管理を一元化できます
2. SAML以外のプロトコルが必要か: Identity Centerの組み込みディレクトリをIdPとした場合、外部のSPと連携できるのはSAML 2.0が主です。OIDCで連携したいSPがある場合には、Identity Centerだけでは対応できません。
3. 認証フローをカスタマイズしたいか: Identity Centerの認証フロー（MFAの種類、条件付きアクセスなど）はAWSの仕様に従います。細かい制御が必要なら、外部IdPの方が柔軟です

実際の企業環境では、すでにIdPを運用しているケースも多いことでしょう。その場合、IDの管理は外部IdPに任せ、Identity CenterはAWSへの入り口に徹する（方式③）のがシンプルになります。

一方、既存のIdPがなかったり（予算の都合で導入が難しかったり…）、AWSの利用規模が小さければ方式②で十分です。

判断フロー

• AWSアカウントが少数（2〜3）で、外部IdPがある → 方式①が手軽
• AWSに閉じた環境で、外部IdPがない → 方式②で始める
• 組織にIdPがある、またはAWSアカウントが多い → 方式③

目安として判断フローを提示しましたが、実際にはこのように単純ではなく、AWSアカウントの設定や運用状況などに影響されます。 現実的には、AWSを導入して間もない組織であれば方式②や方式③の複雑な方式には考えが及ばないでしょうし、AWSアカウントが増えてから問題に直面し方式③を検討するころにはすでに管理状況がバラバラかもしれません。 いずれにしても現状を十分に調査し、仕様を理解し、十分な検証を実施したうえで慎重に導入計画を立てることをお勧めします。

後半 ハンズオン

6. 方式③のハンズオン（Okta → Identity Center → AWSアカウント）

ここからは方式③を実際に構築してみます。外部IdPとしてOktaを使います。 手順が多く、OktaとAWSを行ったり来たりして混乱しやすいので慎重に進めてください。

前提:

• AWSアカウントを2つ以上持っている（Organizations有効化済み）
• Okta Developerアカウントを持っている

6-1. Organizations セットアップ

方式②③ではIAM Identity Centerを使うため、AWS Organizationsが有効になっている必要があります。

1. マネジメントアカウントでAWS Organizationsコンソールを開く
2. 「組織を作成」を選択
3. メンバーアカウントを招待または新規作成する

すでにOrganizationsを使っている場合はこの手順はスキップしてください。

詳細な手順は以下をご参照ください。

docs.aws.amazon.com

6-2. IAM Identity Center 有効化

Identity Centerには「組織インスタンス」と「アカウントインスタンス」の2種類があります。マルチアカウントのアクセス管理にはOrganizations管理アカウントから有効化する「組織インスタンス」が必要です。メンバーアカウント単体で作成する「アカウントインスタンス」では許可セットによるマルチアカウント管理ができません。

1. マネジメントアカウント（または委任管理者アカウント）でIAM Identity Centerコンソールを開く
2. 「有効にする」を選択
3. リージョンを選択する

有効化すると、デフォルトのIDソースとして「Identity Centerディレクトリ」が設定されます。次の手順でこれを外部IdPに切り替えます。

詳細な手順は以下をご参照ください。

docs.aws.amazon.com

6-3. Okta側の準備

今回はOktaが開発者用に提供している無償プラン（Integrator Free Plan）を利用します。Gmailなどのフリーメールでは登録できないのでご注意ください。 Oktaにユーザーとグループを作成します。ここで作成したユーザー・グループが、のちの設定によってSCIMでIdentity Centerに同期されます。

すでにOktaでユーザー・グループを管理している場合はこの手順はスキップしてください。

• Okta Admin Consoleで「ディレクトリ」→「ユーザー」からユーザーを作成します。

  

  

  名前やメールアドレスなどを入力して「保存」をクリックします。

  「ユーザー」画面で、登録したユーザーが表示されることを確認します。

• 「ディレクトリ」→「グループ」からグループを作成します。（例: Developers、Admins）

  

  

• 作成したグループ(ここではDevelopers)にユーザーを割り当てます。

  

  +ボタンを押して「割り当て済み」に変更後、「完了」をクリック

6-4. Okta → Identity Center 接続（SAML＋SCIM）

この手順はAWS公式ドキュメントに沿ったものです。

docs.aws.amazon.com

作業中、OktaとAWSの設定を行ったり来たりします。そのため、Okta Admin ConsoleとAWSマネジメントコンソールを横並びで作業することをお勧めします。手順の冒頭に(Okta)と記載したものがOkta Admin Consoleの作業、(AWS)と記載したものがAWSマネジメントコンソールでの作業です。

SAML連携設定

公式のステップ1にあたる作業です。

• (Okta)Oktaの管理コンソールで「アプリケーション」→「アプリカタログを参照」→「AWS Identity Center」を検索して選択します。

  

  

  SAMLの設定は本来かなりややこしいのですが、Oktaは主要なSP（今回はAWS）とSAML連携しやすいようにあらかじめテンプレートを用意してくれています。今回はOktaさんの厚意に甘えます。

• (Okta)「統合を追加」をクリックします。

  

• (Okta)一般設定はそのままで「完了」をクリックします。

  

• (Okta)「サインオン」→「編集」をクリックします。

  

• (Okta)表示される「サインオンURL」と「発行者」を控えてください。このパラメータは後でAWS側に設定します。

• (Okta)下にスクロールし、SAML証明書の「アクション」→「証明書をダウンロード」をクリックするとokta.certのダウンロード確認が表示されるので保存してください。このファイルも後でAWS側に設定します。

  

  このOktaの証明書は、SAMLアサーションに付与された電子署名の検証に利用されます。OktaがSAMLアサーションに秘密鍵で署名し、AWS側がこの証明書（公開鍵）で署名を検証することで、アサーションが改ざんされていないことを確認します。

次は公式のステップ2にあたる作業です。

• (AWS)Identity Centerコンソールで「設定」→「アイデンティティソース」→「アクション」→「アイデンティティソース」を選択します。

  

• (AWS)「外部IDプロバイダー」を選択して「次へ」をクリックします。

  

• (AWS)表示されるIAM Identity CenterのSAMLメタデータ（ACSのURL、発行者URL）を控えてください。このパラメータは後程Okta側に設定します。

  

  ACSは、SAML認証フローにおいてIdP（Okta）から送られるSAMLアサーション（認証応答）を受け取るエンドポイントURLです。簡単に言うと、Oktaで認証が成功した後、「この人は認証OKですよ」という情報（SAMLアサーション）をどこに送り返すかを指定するURLがACSです。

  方式①では、IdPから各AWSアカウントへ直接SAMLアサーションを送るため、AWSアカウントごとにACSエンドポイント（https://signin.aws.amazon.com/saml）を設定する必要があります。AWSアカウントが10個あれば、Okta側にも10個のSAMLアプリケーション（またはACS URL）を登録することになります。これが前述したN×M問題の一因です。

  一方、方式③ではIdentity CenterがSAMLアサーションの受け口を一本化しています。Okta側で設定するACS URLは1つだけで、その先のAWSアカウントへの振り分けはIdentity Centerの許可セットが担います。つまり、AWSアカウントが増えてもOkta側のSAML設定は変更不要です。

  この「ACS URLが1つで済む」という点が、方式③を選択する実務上の大きなメリットです。ACS URLを誤って設定した場合のトラブルシューティングについては6-8で後述します

• (AWS)「IdPサインインURL」に、先ほど控えた「OktaのサインオンURL」を入力してください。「IdP発行者URL」に先ほど控えた「Oktaの発行者(URL)」を入力してください。IdP証明書の「ファイルを選択」をクリックし、先ほど保存したokta.certをアップロードしてください。「次へ」をクリックしてください。

  

• (Okta)「高度なサインオン設定」までスクロールします。「AWS SSO ACS URL」に先ほど控えたAWS側の「IAM Identity Center Assertion Consumer Service (ACS) の URL」の値をコピペします。「AWS SSO発行者URL」に先ほど控えたAWS側の「IAM Identity Center 発行者 URL」の値をコピペします。「保存」をクリックします。

  

  

• (AWS)確認及び確定のフィールドに「承諾」を入力して「アイデンティティソースを変更」をクリック

  

ここまでで認証（SAML）の設定が完了しました。次にプロビジョニング（SCIM）を設定します。

SCIMプロビジョニング設定

公式のステップ3にあたる作業です。

ここからSCIMによる自動プロビジョニングを設定します。方式①（直接SAML連携）ではIdPとAWSアカウントが直接やり取りするため、SCIM設定は不要です。一方、方式③ではIdentity Centerが認証の中継役となるため、「Identity Center上にユーザーが事前に存在すること」が前提になります。しかしIdentity CenterにはSAML認証時にユーザーを自動作成する機能がないため、このSCIM自動同期で事前にユーザー・グループを同期しておくこと（プロビジョニング）が必要です。

• (AWS)Identity Centerコンソールで「設定」→「自動プロビジョニング」→「有効にする」をクリックします。

  

• (AWS)表示される「SCIMエンドポイント-IPv4のみ」のURLとアクセストークンを控えます。アクセストークンはこの画面を閉じると二度と表示されないので、一時的にテキストファイルに控えるなど確実にコピーしてください。

  

• (Okta)「アプリケーション」→「AWS IAM Identity Center」→「プロビジョニング」タブ→「API統合を構成」をクリックしてください。

  

• (Okta)「API統合を有効化」をチェックするとフォームが表示されます。「ベースURL」にAWS画面の「SCIMエンドポイント-IPv4のみ」のURLをコピペしてください。「APIトークン」にAWS画面の「アクセストークン」をコピペしてください。

  

• (Okta)「API資格情報をテスト」をクリックしてください。設定が正しければ「AWS IAM アイデンティティセンター は正常に検証されました」 のメッセージが表示されます。テストが完了したら「保存」をクリックしてください。

  

  エラーが出た場合コピペするパラメータが正しいことを再確認してください。

• (Okta)「アプリにプロビジョニング」の編集をクリックしてください。

  　

• (Okta)「ユーザーを作成」「ユーザー属性」「ユーザーの非アクティブ化」の3箇所チェックボックスをチェックして「保存」をクリック

6-5. Oktaの情報をIdentity Centerに同期

公式のステップ4にあたる作業です。

この作業では、OktaからIdentity Centerに同期するユーザーとグループを指定します。

• (Okta) まずユーザーの同期を設定します。「割り当て」タブ→「割り当て」→「ユーザーに割り当て」をクリックします。

  

• (Okta) Identity Centerに同期したいユーザーの「割り当て」をクリックします。

  

• (Okta) 「AWS IAM Identity Centerを​ユーザーに​割り当てる」の画面で「保存して戻る」をクリックします。（属性値は特に変更しなくても大丈夫です）

• (Okta) 同期対象のユーザー全てで同じ作業を繰り返し「完了」をクリックします。

  

• (Okta) 「割り当て」タブのユーザー画面で、同期対象のユーザーが表示されることを確認します。

  

• (AWS) Identity Centerのユーザー一覧を確認すると、Oktaのユーザーが同期されていることが確認できます。ここまでがユーザーの割り当て作業でした。

  

• (Okta)次にグループの同期を設定します。「割り当て」タブ→「割り当て」→「グループに割り当て」をクリックします。

  

• (Okta) Identity Centerに同期したいグループの「割り当て」をクリックします（今回はDeveloperグループ）

  

• (Okta) 「AWS IAM Identity Centerをグループに​割り当てる」の画面で「保存して戻る」をクリックします。（属性値は特に変更しなくても大丈夫です）

  

• (Okta) 同期対象のグループ全てで同じ作業を繰り返し「完了」をクリックします。

  

• (Okta)「プッシュグループ」タブ→「プッシュグループ」→「名前でグループを検索」で、グループ名を検索します（今回はAdminsグループを検索）。グループ名が検索できたら「保存」をクリックします。

  

  

• (Okta)対象グループのプッシュステータスが「プッシュ中」から「アクティブ」に変化することを確認します。 同期対象のグループ全てで同じ作業を繰り返します。

  

• (AWS) Identity Centerのグループ一覧を確認すると、Oktaのグループが同期されていることが確認できます。作成者がSCIMになっており、SCIMで連携されたことがわかります。ここまでがグループの割り当て作業でした。

  

6-6. 権限を割り当て

Identity Centerのグループやユーザーに対し、AWSアカウントへ権限を割り当てるための作業です。（方式②も同じ作業で割当てできます）

• (AWS)Identity Centerコンソールで「AWSアカウント」を選択し、権限を割り当てたいAWSアカウントにチェックを入れ、「ユーザー又はグループを割り当て」をクリックします。

  

• (AWS)「ユーザーとグループの選択」で、権限を割り当てたいグループ（Oktaから連携されたグループ）にチェックを入れ「次へ」をクリックします。

  

  

• (AWS)「許可セットを選択」画面で、グループに割り当てたい許可セット（権限）にチェックを入れ、「次へ」をクリックします。

  

  

• (AWS) 設定内容を確認し「送信」をクリックします。

  

設定はここでおしまいです。おつかれさまでした。次は動作確認です。

6-7. サインイン確認

• AWSマネジメントコンソール、Okta Admin Consoleからサインオフしておきます。
• Identity CenterのAccess Portal URL（https://<インスタンスID>.awsapps.com/start）にアクセスします。
• Oktaの認証画面にリダイレクトされるので、Oktaのユーザー（6-3で登録したユーザー）でログインします。

• 初回ログインの際にOkta Verifyの設定を求められることがあるので画面の指示に従ってよしなに登録します。

  

• Oktaダッシュボードが表示され、割り当てられたアプリケーション一覧が表示されます。「AWS IAM Identity Center」をクリックします。

  

• Identity Centerで割り当てたAWSアカウントの選択画面が表示されるので、操作対象のAWSアカウントを選択します。

6-8. トラブルシューティング

Oktaのマイアプリ一覧から「AWS IAM Identity Center」をクリックするとエラーが表示される・アクセスできない

Oktaのアプリケーション設定の「サインオン」タブの「AWS SSO ACS URL」を誤っている可能性があります。

SCIMユーザー同期が反映されない

SCIMトークンの有効期限（1年）が切れているかもしれません。Identity Center側で新しいトークンを発行し、Okta側に再設定してください。

認証成功してもAWSアカウントが表示されない

ユーザーまたはグループに許可セットが割り当てられていません。Identity Centerの「AWSアカウント」画面で、対象ユーザー/グループへの許可セット割り当てを確認してください。

7. 設計・設定・運用で気をつけること

CloudTrailでの追跡

Identity Center経由のサインインは、CloudTrailの管理イベントにFederateやAuthenticateといったイベント名で記録されます。詳細な監査ログの設計については以下の公式ドキュメントをご参照ください。

docs.aws.amazon.com

aws.amazon.com

許可セットの変更管理

許可セットを変更すると、その許可セットが割り当てられている全AWSアカウントのIAMロールに反映されます。意図しない権限変更を防ぐため、変更前に影響範囲（どのAWSアカウント・グループに割り当てられているか）を確認してください。

SCIMトークンの有効期限

SCIMアクセストークンの有効期限は1年です。期限が切れるとIdPからIdentity Centerへのユーザー・グループ同期が停止します。SCIMトークンが失効してもSAML認証フロー自体には直接影響しませんが、外部IdP側の変更（ユーザー無効化、グループ変更など）がIdentity Centerに反映されなくなるため、間接的にアクセスに影響が出る可能性があります。

期限切れ前にIdentity Centerコンソールで新しいトークンを生成し、IdP側の設定を更新してください。

docs.aws.amazon.com

既存環境からの移行

すでにIAMユーザーやIAMロール（方式①など）で運用している環境にIdentity Centerを導入する場合、既存のIAMロールをそのまま許可セットに取り込む機能はありません。許可セットを新たに設計し、既存の権限を再現する必要があります。

ただし、Identity Centerの導入と既存のIAMロールの廃止は同時に行う必要はありません。並行運用しながら段階的に移行できます。なお、移行対象はユーザがログインに使うIAMロールのみで、Lambda実行ロールやEC2インスタンスプロファイルなどのサービスロールは対象外です。

IDソースは1つだけ

Identity CenterのIDソース（Identity Source）は、1つの組織につき1つしか設定できません。選択肢は以下の3つのうちいずれかです。

• Identity Centerディレクトリ（組み込み、デフォルト）
• Active Directory（AWS Managed Microsoft ADまたはAD Connector）
• 外部IdP（Okta、Entra IDなど）

つまり、方式②（組み込みディレクトリ）と方式③（外部IdP）は併用できません。

IDソースの切り替えに伴う、登録済み情報の削除

IDソースを切り替えると、切り替え元のユーザー・グループが削除されることがあります。割り当て（許可セットとユーザー/グループの紐づけ）が保持されるかどうかは切り替えパターンによります。詳細は公式ドキュメントを参照してください。

docs.aws.amazon.com

方式③導入後の定期運用タスクの一覧（一例）

タスク	頻度	対応しなかった場合の影響
SCIMアクセストークンの更新	年1回（有効期限: 1年）	ユーザー・グループの同期が停止する。新規ユーザーがログイン不可になる・無効化ユーザが反映されない
許可セットの棚卸し	半年〜年1回（推奨）	不要な権限が残存し、最小権限の原則から逸脱する
退職者のIdP側アカウント無効化	発生都度	SCIM同期によりIdentity Center側も無効化されるが、反映までのタイムラグに注意
SAML証明書の更新	IdP側の証明書有効期限による（今回取得した証明書（okta.cert）は10年でしたが、環境により異なります。）	SAML認証に影響が発生する恐れ

このほかにも、組織によってはCloudTrailログでの利用状況（サインイン状況）を監査することもあるでしょう。

まとめ

マルチアカウント環境の認証方式を3つ比較し、方式③（外部IdP → Identity Center → AWSアカウント）の導入手順を紹介しました。

• 方式①（外部IdP→AWSアカウント）: 構成がシンプルだが、AWSアカウント数に比例して設定が増える
• 方式②（Identity Center→AWSアカウント）: AWS内で完結し、許可セットで一元管理できる。外部IdPがない場合に適している
• 方式③（外部IdP → Identity Center → AWSアカウント）: ID管理とアクセス管理を分離できる。組織にIdPがある場合に適している

余談ですが、このような導入手順を確認したり検証したりすると、MFAデバイス（スマホのAuthenticatorアプリ）にアカウントが増殖してしまいます。手順の確認が終わったらもちろん削除するのですが、実運用で使っているエントリを誤削除してしまわないかいつもひやひやします。このようなひやひや感をユーザーに感じさせないためにも認証の一元化はおすすめです。

執筆者

平田賀一（NTTビジネスソリューションズ（株）バリューデザイン部 システム開発部門）
PaaS/SaaSの開発・運用、社内案件のコンサル、エンジニア育成、NTT WEST Engineers' Blog運営などに携わっています。
技術士(情報工学部門)/CISSP/2025 Japan All AWS Certifications Engineers

参考資料・出典

本記事を執筆するにあたり、以下のサイトを参考にしました。

docs.aws.amazon.com

docs.aws.amazon.com

docs.aws.amazon.com

docs.aws.amazon.com

docs.aws.amazon.com

qiita.com

商標

Amazon Web Services、AWS、AWS Identity and Access Management (IAM)、AWS IAM Identity Center、AWS Single Sign-On、AWS Organizations、AWS CloudTrail、AWS Lambda、Amazon EC2、AWS Managed Microsoft AD、AD Connector、AWS Certified Solutions Architectなどは、Amazon.com, Inc. またはその関連会社の商標です。

Active Directory、Entra IDはMicrosoft Corporationまたはその関連会社の商標です。

KeycloakはThe Linux Foundationの商標です。

Okta、Okta VerifyはOkta, Inc.の登録商標です。