はじめに
こんにちは。マルチアカウント運用を楽にしたいすずきです。
AWS Organizationsを利用した一人アドミン検証シリーズの3本目です。
前2本では前後編としてまとめていましたが、アカウント管理・運用を考えると、Organizationsだけで収まるわけがなかったので、『一人アドミン検証シリーズ』として不定期にまとめていこうと思います。
- 第1回: 組織の作成とアカウント管理
- 第2回: SCP・タグポリシーによる統制
- 第3回: IAM Identity Centerによるアクセス管理 ← 本記事
第1回では管理アカウントのIAMユーザーからスイッチロールでメンバーアカウントに入っていました。動くには動くのですが、アカウントごとにスイッチ先のIAMロールを個別に用意して管理しないといけないため、アカウントが増えるほどに管理も運用も大変になります。
今回はそこをIAM Identity Centerに置き換えて安全に、楽に管理運用したい！という内容です。
なお、本記事では外部IdP(OktaやEntra IDなど)との連携は扱いません。IAM Identity Centerで設定できる範囲内でのみ試した内容をまとめています。
本記事の情報は2026年9月時点のものです。
最新情報については公式ドキュメントをご確認ください。
前回までのおさらい
第1回・第2回では、個人アカウント1つを管理アカウントにして次の構成を作りました。
- Root配下に
SandboxOUを作成 - 新規メンバーアカウント
Sandbox-A・Sandbox-Bを作成してSandboxOUへ移動 -
SandboxOUに、SCP(envタグなしのLambda関数作成を拒否)とタグポリシー(envタグの値をsandboxに標準化)をアタッチ
第2回の時点で「OU配下で何ができるか」の統制はかかりました。ただ、その統制された環境に誰がどうやって入るかは手つかずのままです。今のところ、管理アカウントのIAMユーザーで一度ログインして、そこからOrganizationAccountAccessRoleにスイッチロールする、という導線しかありません。
本記事ではここにIAM Identity Centerを入れて、アクセスの入口を切り替えます。
この記事でわかること
- Organizations環境でIAM Identity Centerを有効化する手順
- Identity Center内蔵ディレクトリでユーザー・グループを作り、許可セット経由で複数のAWSアカウントにアクセス権を割り当てる手順
- SCPがIAM Identity Center経由のアクセスにも有効かどうか
先に結論
IAMユーザー管理のアカウントをIAM Identity Centerへ移行し、動作確認をしました。
以下はざっくりとした比較表です
| 他アカウントへのログイン | スイッチロール(第1回) | IAM Identity Center(本記事) |
|---|---|---|
| ログインに使う認証情報 | 管理アカウントのIAMユーザー | Identity Centerのユーザー |
| 招待アカウントへのロール | 手動で作成する | 許可セットの割り当てで自動作成される |
| MFA | IAMユーザーごとに設定する | デフォルトで有効 |
| 権限を変えたいとき | アカウントごとにIAMロールを編集 | 許可セットを1箇所直せば割り当て先すべてに反映 |
1. IAM Identity Centerとは
IAM Identity Centerのユーザーガイドには次のように書かれています(翻訳)。
AWS IAM Identity Center は、従業員ユーザーを Kiro や Amazon Quick などの AWS マネージド アプリケーションやその他の AWS リソースに接続するための AWS ソリューションです。既存の ID プロバイダーを接続してディレクトリからユーザーとグループを同期したり、IAM Identity Center でユーザーを直接作成および管理したりできます。その後、IAM Identity Center を以下のいずれか、または両方に使用できます。
・アプリケーションへのユーザーアクセス
・AWSアカウントへのユーザーアクセス
簡単にまとめると「複数のAWSアカウントとアプリケーションへのアクセスを、1つのIDで一元管理する仕組み」のようです。旧称のAWS Single Sign-On(AWS SSO)のほうが馴染みがある方もいるかもしれません。
用語整理
- インスタンス：IAM Identity Center自体のデプロイ単位。Organizationsの管理アカウントで有効化する組織インスタンスと、メンバーアカウント単位のアカウントインスタンスの2種類があり、今回使うのは前者
- IDソース：ユーザーをどこで管理するかを決める設定。外部IdP・Active Directory・Identity Center内蔵ディレクトリの3つがあり、今回は内蔵ディレクトリを使用
- 許可セット：「どこまでできるか」をIAMポリシーのテンプレートとして定義したもの
- 割り当て：許可セットを「誰が」「どのアカウントに」使えるかを紐づけたもの。割り当てると対象アカウント側にIAMロールが自動で作成される
料金はIAM Identity CenterのFAQに記載のとおり追加費用なしで使えます。Organizations自体も無料だったので、一人アドミンの練習台としては引き続きありがたい構成です。
組織インスタンスとアカウントインスタンス
組織インスタンスとアカウントインスタンスの公式ドキュメントによると、両者の違いは次のとおりです。
| 組織インスタンス | アカウントインスタンス | |
|---|---|---|
| 有効化する場所 | Organizationsの管理アカウント | メンバーアカウント / スタンドアロンアカウント |
| 複数アカウントへの権限付与 | できる | できない(そのアカウント内のアプリのみ) |
| 数の制限 | 管理アカウントごとに1つ | AWSアカウントごとに1つ(組織内の複数アカウントでそれぞれ作れる) |
マルチアカウントに権限を配りたい今回の用途では、組織インスタンス一択です。アカウントインスタンスは「Organizationsを他部署が管理していて管理アカウントを触れないが、そのアカウントでAWSマネージドアプリケーションだけ使いたい」といったケース向けのようです。
2. 今回つくる構成
Sandbox OU配下の2アカウントに対して、Identity Centerのユーザー1人からアクセスできる状態を作ります。
概要
- 管理アカウントでIAM Identity Centerを有効化する(組織インスタンス、リージョンは東京)
- IDソースはIdentity Center内蔵ディレクトリのまま使う
- ユーザーを1人、グループを1つ(
SandboxAdmins)作り、ユーザーをグループに入れる - 許可セットを2つ作る
-
AdministratorAccess(事前定義済み):管理者用権限。検証等で自由に操作するとき用 -
PowerUserAccess(事前定義済み):よく開発環境等で用いられる許可セット。基本的なリソースの操作はできるが、IAMユーザー・グループの管理周りの変更ができない
-
-
SandboxAdminsグループに、Sandbox-A・Sandbox-Bの2アカウント分の割り当てを作る
ユーザーではなくグループに割り当てるのは、あとからユーザーが増えた時にグループへ入れるだけで済むからです(一人アドミンだとありがたみが薄いですが笑)。
前提条件
- 第1回で作成した組織と
SandboxOU、およびSandboxOU配下のメンバーアカウント2つ - 第2回で
SandboxOUにアタッチしたSCPとタグポリシー(8. SCPはIdentity Center経由のアクセスにも有効かで使います) - 管理アカウントの認証情報(有効化・設定用)
3. IAM Identity Centerの有効化
管理アカウントでマネジメントコンソールにログインし、IAM Identity Centerのコンソールを開きます。
有効化する前に、画面右上のリージョンが意図したものになっているかを確認します。ここで選んだリージョンが組織インスタンスのプライマリリージョンになり、あとから変えたい場合はインスタンスごと削除して作り直しになります(参考)。今回は東京リージョン(ap-northeast-1)で作ります。
「インスタンス設定」でシングルリージョン・マルチリージョン・カスタムインスタンスの3種類から選び、「有効にする」をクリックします。マルチリージョンを選ぶとレプリケーション用にカスタマー管理のKMSキーが自動作成され、KMSの料金が発生します。個人検証なのでシングルリージョンを選びました。
有効化が完了すると、ダッシュボードの「AWS access portal URL」欄に3種類のURLが表示されます。
- デュアルスタック:
https://ssoins-xxxxxxxxxxxxxxxx.portal.ap-northeast-1.app.aws - Regional IPv4 URL:
https://ssoins-xxxxxxxxxxxxxxxx.ap-northeast-1.portal.amazonaws.com - IPv4専用:
https://d-xxxxxxxxxx.awsapps.com/start
このうちユーザーのログイン先として案内するのは、サブドメイン部分をカスタマイズできる「IPv4専用」のURLです。ランダムなIDのままだと覚えにくいので、ダッシュボードの「AWS access portal URL」欄にある「編集」からサブドメイン部分を好きな名前に変更できます。ただし公式ドキュメントにあるとおり一度設定すると変更できないので注意が必要です。
4. ユーザーとグループの作成
IDソースは内蔵のIdentity Centerディレクトリをそのまま使うので、追加の設定なしでユーザーを作れます。
グループの作成
先にグループを作ります。IAM Identity Centerコンソールの左メニューから「グループ」を開き、「グループを作成」をクリックします。
任意のグループ名(例: SandboxAdmins)と説明を入力して作成します。この時点ではメンバーがいないので、ユーザーは空欄のまま「グループを作成」をクリックします。
ユーザーの作成
左メニューの「ユーザー」を開き、「ユーザーを追加」をクリックします。
ユーザー名・メールアドレス・氏名を入力します。メールアドレスは招待メールの送信先になるので、実際に受け取れるアドレスにします。
パスワードの設定方法は「パスワードの設定手順が記載された E メールをこのユーザーに送信します」を選びます。もう一方の「ワンタイムパスワードを生成して...」を選ぶと、その場で初期パスワードが画面に表示されます。
次の画面で、さきほど作ったSandboxAdminsグループにチェックを入れてユーザーを追加します。
作成が完了すると、入力したメールアドレスに招待メールが届きます。
メール内のリンクから新しいパスワードを設定します。
MFAは、2023年11月16日以降に作成されたIAM Identity Centerインスタンスではデフォルトで有効になっているため、初回サインイン時にそのまま登録を求められます(MFAの公式ドキュメント)。
登録後はAWSアクセスポータルにページが遷移します。
現時点ではアカウントへの割り当てをしていないため何も表示されません。
5. 許可セットの作成
ユーザーができたので、次は「どこまでできるか」を定義する許可セットを作ります。
左メニューの「マルチアカウントのアクセス許可」→「許可セット」を開き、「アクセス許可セットを作成」をクリックします。
許可セットのタイプは「事前定義されたアクセス許可セット」と「カスタムアクセス許可セット」の2種類あります。前者はAWS管理ポリシーを1つ選ぶだけ、後者は複数のポリシーやインラインポリシー、アクセス許可境界を自分で組み合わせる形になります。今回はどちらも事前定義で作ります。
AdministratorAccessを選んで次に進むと、許可セット名とセッション期間を設定する画面に遷移します。
セッション期間はデフォルトが1時間で、最大12時間まで伸ばせます。ここで設定した時間を超えるとコンソールからサインアウトされ、入り直しになります。検証中に何度も入り直すのは面倒なので、AdministratorAccessのほうは少し長めにしました。
同じ手順でPowerUserAccessの許可セットも作ります。作り終えると、一覧に2つ並びます。
なお、この時点ではまだどのアカウントにも紐づいていないため、対象アカウント側にIAMロールは作られていません。ロールが作られるのは次の割り当てのタイミングです。
6. AWSアカウントへの割り当て
ユーザー(グループ)と許可セットが揃ったので、両者をAWSアカウントに紐づけます。
左メニューの「マルチアカウントのアクセス許可」→「AWSアカウント」を開くと、組織のOU構成がそのまま表示されます。(第1回・第2回で作ったSandbox OUと配下アカウントが表示されています。)
Sandbox-AとSandbox-Bの両方にチェックを入れて、「ユーザーまたはグループを割り当て」をクリックします。
「グループ」タブからSandboxAdminsを選びます。
次に、割り当てる許可セットとしてAdministratorAccessとPowerUserAccessの両方にチェックを入れます。
内容を確認して「送信」をクリックすると、対象アカウントへのプロビジョニングが始まります。
プロビジョニングが完了すると、対象アカウント側にAWSReservedSSO_AdministratorAccess_xxxxxxxxのような名前のIAMロールが自動で作られます。第1回で招待アカウントに手動でロールを作った作業が、ここでは割り当て操作だけで済んでいることになります。
AWSReservedSSO_で始まるロールはIAM Identity Centerの管理下にあり、IAMコンソールからは編集できません。権限を変えたい場合は許可セット側を修正します。
7. 動作確認: AWSアクセスポータルからログイン
設定が終わったので、実際にユーザーとしてログインしてみます。
3. IAM Identity Centerの有効化で確認したAWSアクセスポータルのURLをブラウザで開き、作成したユーザー名とパスワードでサインインすると、アクセスできるAWSアカウントの一覧が表示されます。
アカウントを展開すると、割り当てたAdministratorAccessとPowerUserAccessが選択肢として並びます。ここから入りたい権限を選んでコンソールに移動する流れです。
管理アカウントに一度ログインしてからスイッチロールする、という往復がなくなり、ポータルから行きたいアカウントを直接選べるようになりました！
第1回で「ブラウザのプロファイルを分けた方が良い」と書いた問題も、ポータル1枚から複数アカウントを行き来できるので、だいぶ軽くなった感覚があります。
8. SCPはIdentity Center経由のアクセスにも有効か
ここが今回いちばん気になっていたところです。
第2回でSandbox OUに「envタグなしのLambda関数作成を拒否する」SCPをアタッチしました。今回作った許可セットはAdministratorAccess、つまりIAM上は何でもできる権限です。この状態でタグなしのLambda関数を作ろうとしたら、どうなるでしょうか。
第2回で書いたとおりSCPはIAMポリシーの上限として働くので、ブロックされるはずです。
ただ、Identity Centerが自動生成するロールでは試したことがなかったため実際に確かめてみます。
アクセスポータルからSandbox-AにAdministratorAccessで入り、Lambdaコンソールからenvタグなしで関数を作成してみます。
そのまま「関数を作成」をクリックしたところ、しっかりブロックされました。第2回でスイッチロールから試したときと同じ、SCPによる明示的な拒否のメッセージが出ています。
許可セットがAdministratorAccessでもSCPでの制限が優先されるという当たり前といえば当たり前の結果なのですが、「アクセスの入口をIdentity Centerに変えても、第2回で敷いたガードレールはそのまま効き続ける」ことを確認できました。
統制の層(SCP)とアクセスの層(Identity Center)は独立して積み上がる、という整理ができた気がします。
なお、SCPが適用されないのは管理アカウントだけ、という第2回の仕様もそのままです。管理アカウントに対する許可セットの割り当てを作った場合、そこから入ってもSCPは効きません。
まとめ
第1回から第3回を通して、個人アカウント1つを起点に、組織の作成・SCPによる統制・IAM Identity Centerによるアクセス管理までを一人で一通り体験しました。
第1回の時点では「スイッチロールで入れるならこれでいいのでは」と思っていたのですが、実際に置き換えてみると印象が変わりました。ユーザーの管理は1箇所にまとまり、アカウントごとにロールを手で作る作業もなくなるなど、今回試した機能だけでもメリットを感じられました。
そして、SCPがIdentity Center経由のアクセスにも変わらず有効なことを自分の手で確認できたのも勉強になりました。「統制はOrganizationsのSCPで、アクセスはIdentity Centerで」と役割がしっかり分担されているので、アカウントの管理・運用時には気をつけたいと思います。
次はAWS Control Towerを試して、ここまで手作業で組み立ててきた構成がどこまで自動で用意されるのかを見てみたいと思います。あわせてAWS Configによる構成の継続的な監視にも挑戦して、もう少し本番運用に近いガバナンス構成に近づけていきたいと思います。