Organizations・IAM Identity Center - AWS

最終更新日: 2026-08-02

TOP(About this memo)) > 一覧(AWS) > Organizations・IAM Identity Center

この分野が分かりづらい理由

AWS Organizations、AWSアカウント(管理アカウント/メンバーアカウント)、IAM Identity Centerのユーザー・Permission Set・アカウントへの割り当て、といった要素が複数の階層にまたがっており、それぞれの役割が初見では掴みにくい(IME)。まず全体の関係図を押さえてから各要素を見ていく。

全体像

AWS Organizations
│
├─ 管理アカウント (Management Account)
│   … Organizationsを有効化した最初のAWSアカウント。組織全体の管理拠点。
│   │
│   └─ IAM Identity Center を有効化する場所
│        ├─ Users            … 実在する人物のログインID
│        ├─ Permission Sets  … 「何ができるか」を定義した権限テンプレート(IAMポリシーの集合)
│        └─ Account assignments
│             (どのUserを、どのAWSアカウントに、どのPermission Setで割り当てるか)
│
└─ メンバーアカウント (Member Account) ×N
     … Organizations配下に作成する個別のAWSアカウント。
       実際のEC2・RDS・S3などのリソースはこちらに構築する。
     │
     └─ Permission Setが割り当てられると、このアカウント内に
        自動でIAMロールが生成される(例: AWSReservedSSO_AdministratorAccess_xxxxxxxx)
        → 自分でIAMロールを作る必要はない

さらに、Identity Centerの「割り当て」は次の3つの掛け合わせだと考えると理解しやすい。

Identity Center User (例: taro.yamada)
        ×
Permission Set (例: AdministratorAccess)
        ×
対象アカウント (例: メンバーアカウント 111122223333)
        ↓
対象アカウント内に自動生成されるIAMロール
        ↓
aws sso login で取得する一時的なSTS認証情報

なぜこの仕組みになっているのか(Why)

「AWSアカウント」「ルートユーザー/IAMユーザー」「Identity CenterのUser」と、ユーザーらしき概念が複数出てくるため混乱しやすい。それぞれが表しているものを整理する。

ルートユーザー・IAMユーザーの位置づけ

AWSアカウントは「人」の単位ではない

Identity Centerは「人」を表す唯一の概念

人が増えた時・減った時の非対称性

なぜAWSアカウント(メンバーアカウント)を分けるのか

分割基準 例
環境ごと dev / staging / prod
システム・プロダクトごと 自社システムA / 自社システムB
顧客・案件ごと 受託システムC(顧客ごとに分けることも)
役割ごと ログ集約専用アカウント、セキュリティ監査専用アカウントなど

分ける実利は以下の通り。

Identity Center側は、これらのアカウントが何個に増えても、Userと割り当てを追加するだけで対応できる。

AWS Organizations

概要

管理アカウントとメンバーアカウント

メンバーアカウントの作成

AWS Organizations → AWS accounts → Add an AWS account → Create an AWS account

費用について

IAM Identity Center

概要

用語整理

用語 役割
User Identity Center上のログインID。実在する人物に対応する
Permission Set 「何ができるか」を定義した権限テンプレート(IAMポリシーの集合に相当)
Assignment(割り当て) User × Permission Set × AWSアカウントの組み合わせを紐付ける操作

ユーザーの作成

IAM Identity Center → Users → Add user

Permission Setの作成

IAM Identity Center → Permission sets → Create permission set

アカウントへの割り当て

IAM Identity Center → AWS accounts → 対象アカウントを選択 → Assign users or groups

メンバーアカウントへのアクセス方法

Organizationsで作成したメンバーアカウントは、IAMユーザーではなく独立したAWSアカウント(なぜAWSアカウント(メンバーアカウント)を分けるのか参照)。アクセス方法は主に3つある。

1. OrganizationAccountAccessRoleでロール切り替え(AssumeRole)

メンバーアカウント作成時、そのアカウントには通常以下のIAMロールが自動作成される(メンバーアカウントの作成のIAM role name参照)。

OrganizationAccountAccessRole

管理アカウント側で十分な権限を持つ主体(IAMユーザーやロール)から、このロールへAssumeRole(コンソールでは「Switch Role」)することでメンバーアカウントにアクセスできる。

Management Account
    ↓ AssumeRole
OrganizationAccountAccessRole
    ↓
Member Account

Terraform運用や、管理アカウント側からの日常的な管理作業では、この方法が最も一般的(Terraformでのマルチアカウント運用を参照)。

2. IAM Identity Center(SSO)経由でログイン

人間がブラウザでログインする場合、AWSが推奨しているのはこちらの方法(AWSコンソール(ブラウザ)へのログインを参照)。1つのUserで複数アカウントを横断でき、アカウントごとにIAMユーザーを作らずに済む。

3. ルートユーザーでログイン(緊急時のみ)

技術的には可能だが、Organizationsで作成したメンバーアカウントには初期パスワードが設定されていない。ログインするには以下の手順でパスワードを設定する必要がある。

  1. メンバーアカウント作成時に指定したメールアドレスを確認する(メンバーアカウントの作成のEmail address)
  2. AWSサインイン画面で「パスワードをお忘れですか?」を実行
  3. 届いたメールの案内に従ってルートパスワードを設定
  4. ルートユーザーとしてログイン

ルートユーザーは全権限を持ちアカウント個別の管理になるため、緊急時以外は利用しないのがAWSのベストプラクティス(管理アカウントとメンバーアカウントも参照)。

(非推奨) メンバーアカウントにIAMユーザーを作成してログイン

https://<アカウントID>.signin.aws.amazon.com/consoleから専用IAMユーザーでログインする方法もあるが、これは「アカウントごとに個別のIDを持つ」という、Identity Centerで避けたい運用に逆戻りしてしまう(IMO)。

AWSコンソール(ブラウザ)へのログイン

AWS access portal URL(https://xxxxx.awsapps.com/start形式)にブラウザでアクセスし、Identity Centerのユーザーでログインすると、CLIで使っているのと同じ「アカウント×Permission Setの一覧」画面が表示される。各アカウント/ロールの行に2つの選択肢がある。

つまり「CLIでのaws sso login」と「コンソールでのManagement consoleクリック」は、同じ認証基盤の入り口違いなだけで、裏側の仕組みは同じ。ログインしているのはIdentity Centerのユーザーであり、対象アカウント内には自動生成されたIAMロール(AWSReservedSSO_AdministratorAccess_xxxxxxxx)にフェデレーションでスイッチしている形になる。

Terraformでのマルチアカウント運用

環境ごとにメンバーアカウントを分ける構成(なぜAWSアカウント(メンバーアカウント)を分けるのかも参照)は、Terraform運用でもよくあるパターン。

Management Account
├─ dev
├─ stg
└─ prod

管理アカウントから、各環境アカウントのOrganizationAccountAccessRole(または環境ごとに専用に作成したロール)へAssumeRoleする形で運用する。

Management Account
    ↓ AssumeRole
dev

Management Account
    ↓ AssumeRole
stg

Management Account
    ↓ AssumeRole
prod

Terraform自体も、各アカウントのロールをAssumeRoleしてリソースを管理するのが一般的(例: provider "aws" { assume_role { role_arn = "arn:aws:iam::<各アカウントID>:role/OrganizationAccountAccessRole" } }のような設定)。

CLIでの利用

aws configure sso

aws configure sso

対話内容はCLIバージョンによって異なる

sso-session(推奨形式、トークン自動リフレッシュ対応)は AWS CLI v2.9系以降で使える機能。実際に検証した結果、以下の違いを確認した。

バージョン 挙動
v2.7.30 SSO session nameという質問自体が出ない。常にレガシー形式(単一[profile]ブロック)で書き込まれる
v2.9.6以降 SSO session name (Recommended)が質問される。名前を入力するとsso-sessionブロックに分離された推奨形式になり、空欄で進めるとレガシー形式になる

つまり「推奨形式にならない」場合、まずaws --versionでバージョンを確認し、v2.9系より古ければアップデートする(brew upgrade awscli、またはインストール手順のpkgインストーラーを再実行)のが対応策になる。実際にv2.7.30からv2.36.14へアップデートしたところ、SSO session nameの質問が表示されるようになることを確認済み。

新しいバージョン(v2.9系以降)での対話例:

ブラウザが開いてログイン後、割り当てられたアカウント/ロールの一覧から選択し、region/output/プロファイル名を入力すると~/.aws/configに設定が書き込まれる。

推奨形式(SSOトークンプロバイダー設定): セッション名を入力した場合(v2.9系以降のみ)。sso-sessionブロックが分離され、複数プロファイルでのセッション共有やトークンの自動リフレッシュに対応する。

[profile myprofile]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = AdministratorAccess
region = ap-northeast-1
output = json

[sso-session my-sso]
sso_region = ap-northeast-1
sso_start_url = https://xxxxx.awsapps.com/start
sso_registration_scopes = sso:account:access

レガシー形式(非リフレッシュ設定): セッション名を空欄で進めた場合、またはv2.9系より古いCLIの場合。単一の[profile]ブロックに直接書き込まれ、トークンの自動リフレッシュには対応しない。今のところ機能が廃止されたわけではなく、単に古いバージョンや未入力時の挙動として現役でサポートされている。

[profile myprofile]
sso_start_url = https://identitycenter.amazonaws.com/ssoins-xxxxxxxxxxxxxxx
sso_region = ap-northeast-1
sso_account_id = 111122223333
sso_role_name = AdministratorAccess
region = ap-northeast-1
output = json

古いCLIのままレガシー形式を使い続けても、個人利用でプロファイルが1つだけなら実用上の支障はない(IMO)。推奨形式にしたい場合はCLIのアップデートが必要。

いずれの形式・いずれのsso_start_urlの値でも、aws sso login/aws sso logoutの挙動やCLIでの利用方法は変わらない。ただしブラウザでAWSコンソールにログインしたい場合は、sso_start_urlの値ではなく、必ずAWS access portal URL(*.awsapps.com/start形式、招待メールにも記載)を使うこと。sso_start_urlにIssuer URLが設定されている場合、そのURLをブラウザで直接開いてもログイン画面は表示されない。

(出典: Configuring IAM Identity Center authentication with the AWS CLI、Customizing the AWS access portal URL)

設定(config)とセッション(トークン)の違い

対象 保存場所 ログイン/ログアウトの影響
プロファイル設定(start URL、region、account ID、role名など) ~/.aws/config 影響なし。恒久的に残る
一時的な認証トークン(セッション) ~/.aws/sso/cache/*.json ここだけがリセット/発行される

aws sso login/aws sso logoutは上記のうちセッションのトークンだけを操作し、~/.aws/configの内容は一切書き換えない。そのため、ログアウト→ログインを繰り返してもURLやリージョンを毎回入力し直す必要はなく、ブラウザ側でのログイン(場合によってはパスワード入力)のみで済む。

ログイン・ログアウト

aws sso login --profile myprofile
aws sso logout --profile myprofile

セッション状態(ログイン状況)の確認

aws configure listはプロファイルの静的な設定内容を表示するだけで、SSOセッションが有効かどうかまでは分からない。セッション状態の確認には以下を使う。

aws sts get-caller-identity --profile myprofile

The SSO session associated with this profile has expired or is otherwise invalid. To refresh this SSO session run aws sso login with the corresponding profile.

有効期限を直接確認したい場合は、キャッシュされたトークンファイルを見る方法もある(やや裏技的)。

cat ~/.aws/sso/cache/*.json

expiresAtフィールドに有効期限(UTC)が入っている。

--profileを省略する

対象アカウントが実質1つだけの個人利用であれば、該当プロファイルをデフォルトプロファイルにするのが簡単(IMO)。~/.aws/configの[profile myprofile]ヘッダーを[default]に書き換えるだけでよい(中身の各設定値はそのまま)。

[default]
sso_start_url = https://xxxxx.awsapps.com/start
sso_region = ap-northeast-1
sso_account_id = 111122223333
sso_role_name = AdministratorAccess
region = ap-northeast-1
output = json

([sso-session]ブロックを使っている形式の場合は、そのブロックはそのまま残し、[profile]側のヘッダーだけを[default]に書き換えればよい。)

これで以下のように--profile無しで操作できる。

aws sso login
aws sts get-caller-identity
aws s3 ls
aws sso logout

将来、管理アカウント用プロファイルなど複数プロファイルを使い分ける予定があるなら、[default]にはせずexport AWS_PROFILE=myprofileを~/.zshrcに書く方法のほうが、プロファイルの切り替えミスを防ぎやすい(IMO)。

参考: 今回行った作業の流れ

1. ルートアカウントでログイン中のAWSアカウントで Organizations を有効化
   → このアカウントが「管理アカウント」になる(リソースは置かない)

2. Organizations でメンバーアカウントを新規作成
   → Terraformで実際に使うリソースはこちらに構築する

3. IAM Identity Center を有効化し、User を作成(個人名ベースのUsername)

4. Permission Set(AdministratorAccess)を作成

5. メンバーアカウントに対して User × Permission Set を割り当て

6. ローカルで aws configure sso → aws sso login
   → メンバーアカウントに対する一時的な認証情報を取得
This site is open source. Improve this page.