IAM Identity Center のインスタンスとは？リージョンはどう影響する？

Last updated at 2026-02-23Posted at 2026-02-23

IAM Identity Center を有効化すると「インスタンス」というリソースが作成されます。
正直なところ、最初はこの「インスタンス」が何を指しているのかよく分かりませんでした。
自分なりに整理してみました。

1. IAM Identity Center インスタンスとは？

インスタンスでは、Identity Center 関連のユーザーや権限の管理、ログインに必要なアクセスポータルのホストなどを行っています。
組織全体の認証・認可を司る「アクセス制御の中枢」と言えます。

ユーザー情報、許可セット、アカウント割当といった Identity Center のコア機能は、このインスタンスの中で管理されています。

インスタンスと聞くと料金が発生しそうに聞こえますが、Identity Center の利用に追加料金は必要はないと明記されています。

Identity Center インスタンスには種類があります。
組織インスタンスとアカウントインスタンスがありますが、基本的には組織インスタンスが推奨されます。

AWS Organizations の管理アカウントで作成する Identity Center インスタンスです。
各ユーザーがメンバーアカウントにログインするための設定を、管理アカウントで一括で行うような、本来想定された使い方です。

基本的なユーザー管理から、AWS アカウントログイン用のアクセスポータルや管理アカウント委任まで、Identity Center の全ての機能が利用可能です。

アカウントインスタンスは、AWS Organizations を利用しない単一アカウント環境向けの機能です。
マルチアカウント管理や、メンバーアカウントへの横断的なアクセス制御には利用できません。

実質的に、AWS アプリケーションの小規模な検証目的に限られます。
Kiro や Amazon Quick Suite をお試しで使いたい時などが当てはまるかと思います。

インスタンスを作成する際、つまり IAM Identity Center を有効化する際、リージョンをひとつ選択する必要があります。

他のリージョンでは使えない？リージョン選択がどう影響する？と一瞬不安がよぎりますね。

ユーザー管理や権限定義、アクセスポータルのホストは、選択したリージョンで稼働します。

まず安心してよいのは、どのリージョンを選択しても、AWS アカウントへのアクセス制御という主要機能は変わらないという点です。
Dev や Prod などのメンバーアカウントへのログイン可否や許可セットの動作に差はありません。

ただし、IAM Identity Center はリージョナルサービスです。
ユーザー管理や権限定義、アクセスポータルのホストは、選択したリージョンで稼働します。
そのため、裏側ではいくつかの違いが生まれます。

アクセスポータルは、選択したリージョンでホストされます。
東京リージョンを選択した場合、ポータルは ap-northeast-1 で稼働します。

仮に北米ユーザーが多い環境では、わずかながらレイテンシの差が生じる可能性があります。

より重要なのが、リージョナルサービスとの統合です。

Amazon Redshift など、リージョン単位で提供されるサービスでは、IAM Identity Center インスタンスが同一リージョンに存在する必要があります。

例えば、us-east-1 に Redshift クラスターを作成し、SSO 統合を行う場合、Identity Center も us-east-1 に存在している (もしくはそのリージョンにレプリカが存在している) 必要があります。

Identity Center をマルチリージョンにしてこの問題を回避する方法もあります。

結局何を考慮してリージョンを決めたらよいのでしょうか？

まずは候補のリージョンで AWS アプリケーションやサービスの利用に制限がないかを確認し、
次にユーザーが多いリージョンとするのが一番失敗が少ないかと思います。

2026 年 2 月に IAM Identity Center のマルチリージョンサポートの一般提供が開始となりました。

これまでは、一度インスタンスのリージョンを指定すると、リージョンを変更することはできませんでした。
しかし今は、追加のリージョンにインスタンスを複製して有効にすることができるようになりました。

管理は引き続きプライマリリージョンですが、追加リージョンのレプリカで読み取り・アプリ統合ができるようになります。
冗長性の強化や、データレジデンシー要件への対応、そして AWS アプリケーションやリージョナルサービスに対するリージョン選択の柔軟性を持たせることができます。

ただし、ユーザーや許可セットの作成・変更といった管理操作は、引き続きプライマリリージョンで行います。

IAM Identity Center のインスタンスは、組織全体の認証・認可を司る「アクセス制御の中枢」として働くことを見てきました。

またインスタンスのリージョンは、AWS アカウントアクセスの挙動自体を変えるものではありませんが、管理プレーンの所在やリージョナルサービスとの統合に影響することが分かりました。
特に Redshift などと統合する場合は、リージョンについて事前検討が必要です。

現在はマルチリージョンサポートにより柔軟性が向上しているものの、プライマリリージョンの選定は引き続き慎重に行いたいところです。

小さなリソースに見えて、設計思想が凝縮された存在。
それが IAM Identity Center のインスタンスでした。

今日も小さな学びを。