2026.09.27 AWS

AWS SSOへの移行手順：IAMユーザー棚卸しから権限セットのTerraform化まで

AWS SSOは2022年7月26日にAWS IAM Identity Centerへ改称されたサービスで、CLIやTerraformの識別子には今も「sso」の名前が残っています。IAMユーザーとアクセスキーで複数アカウントを運用してきた組織がAWS SSOへ移るとき、手間がかかるのはサービスの有効化ではありません。既存ユーザーの棚卸し、権限セットのコード化、古いキーを止める順番です。認証情報レポートでの棚卸しコマンド、Terraformでの権限セットとグループ割り当て、アクセスキーの無効化から削除までの並行期間、移行後の複数アカウント切り替えを、公式ドキュメントに沿って順に扱います。

まとめ：AWS SSO移行で先に決める棚卸し基準とIAMユーザー廃止期限

移行は「棚卸し→権限セットのコード化→並行運用→キーの無効化→削除」の順で進めます。最初に認証情報レポートを取り、IAMユーザーを人が使うもの、機械が使うもの、90日以上使われていないものに分けてください。人が使うユーザーだけがAWS SSOへの移行対象で、機械用のキーはOIDCやIAMロールへ置き換える別の作業です。

権限セットと割り当ては最初からTerraformで書き、コンソールでの手作業を残さないようにします。IAMユーザーのキーはいきなり削除せず、Inactiveにして数日から1か月の業務サイクルを見てから消す。IAMユーザーの廃止期限を移行計画の時点で決めておかないと、2つの入口が並んだまま棚卸しの手間だけが倍になります。

AWS SSOの改称で変わった名前と変わらずに残ったCLI・Terraform識別子

検索すると「AWS SSO」と「IAM Identity Center」の記事が混在しているのは、名前が変わっても中身が同じだからです。サービスの定義や権限セットの考え方はAWS IAM Identity Centerの権限セット設計とIAMとの使い分けで解説しているので、ここでは移行作業で出会う名前だけを整理します。

2022年7月26日の改称で既存の設定と運用が変わらなかった範囲

AWSの改称発表は、既存のAWS SSO利用者にとって、複数アカウントやアプリケーションへのアクセスを一元管理する方法に変更は無いと書いています。改称前に作った権限セットや割り当ては、そのままIdentity Centerの画面に並ぶ。作り直しは要りません。

料金も変わっていません。公式FAQはIdentity Centerを追加料金なしのサービスとし、有効化しても既存のIAMロール・ユーザー・ポリシーには手を加えないと明記しています。この性質があるので、IAMユーザーを残したまま並行して導入できます。

sso・sso-admin・identitystoreの3つのCLI名前空間の役割分担

AWS CLIでは、改称後もサービスの操作が「sso」を含む名前空間に分かれています。利用者がアクセスポータル経由で認証情報を得るのがsso、管理者が権限セットと割り当てを操作するのがsso-admin、ユーザーとグループを扱うのがidentitystoreです。移行作業で最初に打つのは、インスタンスとIDストアのIDを確かめる次のコマンドになります。

# 管理アカウント（または委任管理者アカウント）の認証情報で実行する
$ aws sso-admin list-instances
{
    "Instances": [
        {
            "InstanceArn": "arn:aws:sso:::instance/ssoins-1234567890abcdef",
            "IdentityStoreId": "d-1234567890"
        }
    ]
}

# 既存の権限セットとグループを一覧する
$ aws sso-admin list-permission-sets --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef
$ aws identitystore list-groups --identity-store-id d-1234567890

Terraformでも同じ構図で、権限セットはaws_ssoadmin_*、ユーザーとグループはaws_identitystore_*というリソース名です。ドキュメントを探すときは「Identity Center」ではなく、この識別子で引くと早く当たります。

移行前にIAMユーザーとアクセスキーの利用実態を認証情報レポートで棚卸しする手順

移行の範囲を決めるには、どのIAMユーザーが、いつ、何に使われているかを数字で押さえる必要があります。IAMには全ユーザーの状態を1枚のCSVにまとめる認証情報レポートがあり、これを起点にします。

generate-credential-reportによる4時間に1回のCSV取得

IAMユーザーガイドの認証情報レポートの章によると、レポートは4時間に1回まで生成でき、直近4時間以内のレポートがあればそれが返されます。必要な権限はiam:GenerateCredentialReportとiam:GetCredentialReportの2つです。

# レポートの生成を依頼する（State が COMPLETE になるまで数秒かかる）
$ aws iam generate-credential-report

# 中身は Base64 で返るので、デコードして CSV に保存する
$ aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv

このレポートには弱点があります。対象はパスワード、ユーザーごとの最初の2本のアクセスキー、MFAデバイス、X.509署名証明書だけで、CodeCommitのパスワードやAmazon Bedrockの長期APIキーのようなサービス固有の認証情報は載りません。Bedrockを使っているアカウントでは、ListServiceSpecificCredentialsで別に洗い出してください。

最終使用日で人・機械・90日放置の3群に分ける判定スクリプト

CSVの列のうち、判定に使うのはpassword_enabled、password_last_used、access_key_1_active、access_key_1_last_used_dateと、2本目のキーの同名列です。値がN/Aやno_informationなら一度も使われていません。次のPythonは標準ライブラリだけで3群に振り分けます。

import csv
from datetime import datetime, timedelta, timezone

LIMIT = datetime.now(timezone.utc) - timedelta(days=90)

def recent(value):
    # N/A と no_information は未使用として扱う
    if value in ("N/A", "no_information", ""):
        return False
    return datetime.fromisoformat(value.replace("Z", "+00:00")) >= LIMIT

with open("credential-report.csv", newline="") as f:
    for row in csv.DictReader(f):
        if row["user"] == "<root_account>":
            continue
        keys = [row[f"access_key_{i}_last_used_date"] for i in (1, 2)
                if row[f"access_key_{i}_active"].lower() == "true"]
        human = row["password_enabled"].lower() == "true"
        used = recent(row["password_last_used"]) or any(recent(k) for k in keys)
        group = "放置" if not used else ("人" if human else "機械")
        print(f"{group}\t{row['user']}\t有効キー{len(keys)}本")

「放置」に入ったユーザーは、移行を待たずに無効化の候補です。「人」はAWS SSOのユーザーとして作り直し、「機械」は後の章でOIDCロールへ置き換えます。コンソールのパスワードとアクセスキーを両方持つユーザーは「人」に入りますが、キーが夜間バッチに使われていることがあるので、access_key_1_last_used_service列で呼び出し先のサービスも確認してください。

権限セットと割り当てをTerraformで書いて複数アカウントへ配る実装手順

棚卸しで「人」に分けたユーザーの権限を、権限セットとグループ割り当てに置き換えます。最初からコードで管理する理由は、コンソールで権限セットや割り当てを作ると、後から変更の差分を追えないためです。Terraform AWS Providerの最新版は2026年9月時点で6.66系で、以下のコードはこの系統を前提にしています。

aws_ssoadmin_instancesとpermission_setの権限定義

権限セットはaws_ssoadmin_permission_setで定義します。session_durationはISO 8601形式で、省略時はPT1H（1時間）です。インスタンスのARNとIDストアのIDは、データソースから引けば手で書かずに済みます。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.66"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1" # Identity Center を有効化したリージョン
}

data "aws_ssoadmin_instances" "this" {}

locals {
  instance_arn      = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  identity_store_id = tolist(data.aws_ssoadmin_instances.this.identity_store_ids)[0]
}

resource "aws_ssoadmin_permission_set" "developer" {
  name             = "Developer"
  description      = "開発アカウント向けの作業権限"
  instance_arn     = local.instance_arn
  session_duration = "PT4H"
}

作業時間に合わせてPT4Hとした例です。上限は12時間ですが、長くするほど端末紛失時に残る時間も伸びる。期限の仕組みはaws sso loginの設定手順とトークン期限で詳しく扱っています。

グループ単位のaccount_assignmentで複数アカウントへ割り当てる書き方

割り当てはaws_ssoadmin_account_assignmentで書き、principal_typeはUSERかGROUP、target_typeはAWS_ACCOUNTです。人単位で割り当てると入退社のたびにコードを直すことになるので、グループに割り当て、人の出入りはグループの所属で吸収します。

data "aws_identitystore_group" "developers" {
  identity_store_id = local.identity_store_id

  alternate_identifier {
    unique_attribute {
      attribute_path  = "DisplayName"
      attribute_value = "developers"
    }
  }
}

resource "aws_ssoadmin_account_assignment" "developer" {
  for_each = toset(["111122223333", "444455556666"]) # 開発・検証アカウント

  instance_arn       = local.instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
  principal_id       = data.aws_identitystore_group.developers.group_id
  principal_type     = "GROUP"
  target_id          = each.value
  target_type        = "AWS_ACCOUNT"
}

Identity Centerのクォータでは、1つのアカウントの1つの権限セットに割り当てられるグループは100までで、引き上げできません。割り当てを作るAPI（CreateAccountAssignment）は未完了の非同期呼び出しが15件までに制限されています。数十アカウントへ一度に配るapplyがスロットリングで失敗したら、-parallelismを下げて流し直してください。グループを社内のIdPから同期する場合は、Terraformではdataで参照するだけにし、aws_identitystore_group_membershipで所属を書くのはIDストアを直接使う構成に限ります。

depends_onを書かないと削除順が崩れる管理ポリシー添付の注意点

権限セットにAWS管理ポリシーを付けるのはaws_ssoadmin_managed_policy_attachmentです。プロバイダのドキュメントは、割り当てと組み合わせるときはdepends_onで割り当てへの依存を明示するよう求めています。書かないと、destroyのときに割り当てより先にポリシーが外れる順序が保証されません。

resource "aws_ssoadmin_managed_policy_attachment" "developer_poweruser" {
  instance_arn       = local.instance_arn
  managed_policy_arn = "arn:aws:iam::aws:policy/PowerUserAccess"
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn

  depends_on = [aws_ssoadmin_account_assignment.developer]
}

1つの権限セットに付けられる管理ポリシーは、AWS管理とカスタマー管理を合わせて25本までです。ただしIAM側のロールあたり管理ポリシーの既定上限は10本なので、11本目からは配布先の各アカウントでIAMのクォータ引き上げが先に要ります。

コンソールで作った既存の権限セットをterraform importで取り込む判断

AWS SSO時代から権限セットをコンソールで作ってきた組織では、コードを書く前に既存分をTerraformの管理下へ入れる必要があります。数が少なければ、同じ名前でコードを書いてimportする方法が確実です。importブロックとCLIの違いはterraform importで既存リソースをコード化する手順にまとめています。

権限セットが数十本あり、半分近くが誰にも割り当てられていない状態なら、importせずに必要なものだけを新しく書き直すほうが早く終わります。aws sso-admin list-accounts-for-provisioned-permission-setで配布先の無い権限セットを先に洗い出し、取り込む対象を絞ってください。

IAMユーザーとAWS SSOを並行運用してアクセスキーを止めるまでの切り替え手順

権限セットが配れたら、IAMユーザーからの切り替えに入ります。一気に消すと、棚卸しで見落とした夜間バッチや外部ツールが止まるため、無効化と削除の間に待機期間を置きます。

利用者ごとにAWS SSOで入れることを確かめてから旧ユーザーを止める順序

並行期間の手順は次のとおりです。Identity Centerは既存のIAMユーザーに手を加えないので、1から3までは既存の運用を止めずに進められます。

利用者をIDストアのグループに入れ、アクセスポータルから対象アカウントへ入れることを本人に確かめてもらう
CLIを使う利用者は~/.aws/configをsso-session形式に書き換え、aws sts get-caller-identityのArnにAWSReservedSSO_が出ることを確認する
~/.aws/credentialsに残った長期キーを削除してもらう
管理者がそのIAMユーザーのコンソールパスワードを無効にし、アクセスキーをInactiveにする
待機期間を置いたあとにIAMユーザーを削除する

2の確認を飛ばすと、環境変数やcredentialsファイルの長期キーが優先されて、本人はSSOで入っているつもりのまま旧キーを使い続けます。Arnの確認は利用者全員に求めてください。

update-access-keyでInactiveへ変更後の削除待機期間

アクセスキー更新の公式手順は、最終使用情報で使われていないように見えても、すぐに削除せずまずInactiveにするよう勧めています。InactiveのキーはActiveへ戻せますが、削除したキーは戻せません。

# 最終使用日時と呼び出し先のサービスを確認する
$ aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

# 無効化する（止まった処理が見つかったら --status Active で戻す）
$ aws iam update-access-key --user-name taro.yamada \
    --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive

# 待機期間を置いてから削除する
$ aws iam delete-access-key --user-name taro.yamada \
    --access-key-id AKIAIOSFODNN7EXAMPLE

公式は「数日待つ」とだけ書いています。実務では、そのアカウントで最も周期の長い定期処理を1回見送れる長さを待機期間にしてください。月次の請求集計がIAMユーザーのキーで動いているなら、数日では足りず1か月が必要です。最終使用日時は15分以内の複数回の利用を1回として記録するので、「いつ最後に使ったか」は分かっても頻度は分かりません。

CI/CDと外部ツールに残る長期キーをOIDCロールへ置き換える順番

棚卸しで「機械」に分けたキーは、AWS SSOでは置き換えられません。IAMのベストプラクティスは、人にはIDプロバイダー経由の一時認証情報を、ワークロードにはIAMロールの一時認証情報を使うよう分けて書いています。GitHub Actionsでの移行先は、AssumeRoleWithWebIdentityを使って一時認証情報を取得するOIDC連携です。その構成はGitHub ActionsとTerraformでAWSのCI/CDを構築する手順で扱っています。

順番は、人のユーザーを先に移し、機械のキーを後に回すのが安全です。人のユーザーの削除は影響が本人に閉じますが、機械のキーを止めると本番のデプロイやデータ連携が止まります。機械用のキーは1本ずつロールへ置き換え、置き換えたものから同じ手順でInactiveにします。

移行後に複数アカウントを行き来するコンソールとCLIの切り替え方法

IAMユーザー時代はアカウントごとにサインインし直すか、スイッチロールで移動していました。AWS SSOに移ると、1回のサインインで割り当てのあるアカウントを行き来できます。

マルチセッションで最大5つのIDに1つのブラウザで同時サインインする設定

マネジメントコンソールのマルチセッションを有効にすると、1つのブラウザで最大5つのIDに同時にサインインでき、IDごとに別のタブでコンソールが開きます。有効化はアカウントメニューの「Turn on multi-session」で、ブラウザごとの設定です。Identity Centerのロールは、アクセスポータルから追加のロールにサインインすると、アカウントメニューにセッションとして並びます。

有効にするとコンソールのURLにアカウントIDを含むサブドメインが付きます。社内の手順書やブックマークに旧形式のURLを貼っている場合は、移行と同時に書き換えてください。

CLIのprofile切り替えとaws-sso-cliなど補助ツールの採否

CLIでは、1つのsso-sessionを複数のprofileで共有し、--profileで切り替えるのが標準の形です。設定の書き方はaws sso loginのsso-session設定と複数アカウントの切り替えで解説しています。アカウントが数十あり、profileを手で書くのが負担になる組織向けに、aws-sso-cliのようなOSSもあります。READMEによると、割り当てのあるロールを自動で検出して~/.aws/configを管理し、認証情報を暗号化したうえでキャッシュする機能を備えたツールです。

採否の目安は、割り当てのあるアカウントが10前後までなら標準のprofileで足ります。補助ツールは認証情報を扱うサードパーティ製ソフトなので、全社に配る前に配布元と更新状況の審査が必要です。審査の手間より、profileのひな形を1つ作って配るほうが安く済む組織が大半です。

AWS SSOへの移行を急ぐ組織とIAMユーザーのまま据え置く場面の判断基準

AWS SSOへの移行は、すべての組織で急ぐべき作業ではありません。判断は、人の出入りの頻度と、長期キーしか受け付けない製品の有無で決まります。

アカウント3つ以上で毎月入退社がある組織は期限を切って全面移行する

AWSアカウントが3つを超え、毎月のように人が入れ替わる組織は、期限を切って全面移行してください。IAMユーザーのままだと、退職者1人につきアカウントの数だけユーザーとキーを消す作業が発生し、1つ消し忘れれば退職後もアクセスできます。AWS SSOならグループから外すだけで全アカウントの入口が閉じる。複数アカウントの組み方そのものを見直すなら、AWS Organizationsのマルチアカウント管理と設計判断から始めると権限セットの切り方も決めやすくなります。

典型的な失敗は、期限を決めずに「新しく入った人からSSOにする」と始めるケースです。古いIAMユーザーが何年も残り、棚卸しの対象が2系統に分かれます。移行計画の最初の行に「IAMユーザーの削除日」を書いてください。

長期キーしか受け付けない外部製品が残る環境で例外として残すIAMユーザー

単一アカウントで数人が使うだけなら、Organizationsの全機能有効化という前提だけが増えるので、IAMユーザーにMFAを強制する運用のままで構いません。また、IAMのベストプラクティス自身が、IAMロールを使えないワークロード（例としてWordPressのプラグイン）や、Identity Centerに対応していないサードパーティ製のAWSクライアントでは、IAMユーザーの長期キーを使うよう案内しています。この種のキーは全面移行の後も例外として残ります。

例外のキーは、用途と持ち主をタグで記録し、認証情報レポートで毎月棚卸しする対象に固定します。棚卸しからTerraform化、CI/CDの置き換えまでを移行計画としてまとめて進めたい場合は、AWS・Google Cloud・Azureのインフラ構築として設計から実装まで引き受けています。

よくある質問

AWS SSOへの移行について問い合わせの多い点を、公式ドキュメントの記述に沿って答えます。

AWS SSOとIAM Identity Centerは別のサービスですか？

同じサービスです。AWS SSOは2022年7月26日にIAM Identity Centerへ改称されました。改称前に作った権限セットや割り当てはそのまま使え、移行作業は要りません。CLIのsso・sso-admin・identitystoreやTerraformのaws_ssoadmin_*など、ツール側の識別子には旧名が残っているため、ドキュメントを探すときは両方の名前で引いてください。

AWS SSO（IAM Identity Center）の利用に料金はかかりますか？

公式FAQはIdentity Centerを追加料金なしのサービスとしています。ユーザー数や権限セット数による課金もありません。費用が発生するのは、アイデンティティソースにAWS Managed Microsoft ADを使う場合のディレクトリ料金など、周辺のサービス側です。社内のIdPとつなぐ場合も、IdP側のライセンス費用はIdPの契約に従います。

IAMユーザーを残したままIdentity Centerを有効化しても問題ありませんか？

問題ありません。公式FAQは、Identity Centerを有効化しても既存のIAMロール・ユーザー・ポリシーには手を加えないと明記しています。そのため並行運用が可能で、利用者ごとにSSOで入れることを確かめてから旧ユーザーを止める段階的な移行ができます。ただし並行期間に終わりを決めないと、入口が2つあるまま放置されるので、IAMユーザーの削除日を先に決めてください。

権限セットはいくつまで作れますか？

Identity Centerのクォータでは、インスタンス全体で3,500、1つのAWSアカウントに配布できる権限セットは500で、どちらも引き上げを申請できます。1つの権限セットに付けられる管理ポリシーは25本、インラインポリシーは1本で最大32,768バイトです。1アカウント・1権限セットに割り当てられるグループは100までで、こちらは引き上げできません。

aws sso loginコマンドとAWS SSOへの移行はどう関係しますか？

aws sso loginは、移行を終えた利用者がCLIからAWS SSOの一時認証情報を取るためのコマンドです。移行の手順2で~/.aws/configをsso-session形式に書き換えたあと、このコマンドでサインインします。設定の書き方や期限、エラーの切り分けはaws sso loginの設定手順とエラー対処で扱っています。