はじめに
今更ですが、aws login と aws sso login のよくある 4 つのログインパターンについて、使い方だけをシンプルにまとめてみました。IAM ユーザーなら aws login、SSO（IAM Identity Center）なら aws sso login を使います。
| パターン | サインインの方法 | コマンド | CLI で使う権限 |
|---|---|---|---|
| 1 | IAM ユーザー | aws login |
IAM ユーザー |
| 2 | IAM ユーザー | aws login |
IAM ユーザーからスイッチロールした IAM ロール |
| 3 | SSO（IAM Identity Center） | aws sso login |
許可セット（Permission Set）のロール |
| 4 | SSO（IAM Identity Center） | aws sso login |
許可セットのロールからスイッチロールした IAM ロール |
事前に必要なもの
-
AWS CLI 2.32.0 以上（
aws --versionで確認。aws loginに必要） -
パターン 1・2：IAM ユーザーに
SignInLocalDevelopmentAccess管理ポリシー（スイッチロール先の IAM ロールには不要） - パターン 3・4：IAM Identity Center で、自分のユーザーにアカウントと許可セットが割り当て済み
パターン 1：通常の aws login（IAM ユーザー）
aws login --profile dev
- リージョンが未設定なら聞かれるので入力します
- ブラウザが開くので、コンソールにサインイン済みならそのセッションを選択、未サインインなら「IAM user」でサインインします
- ターミナルに戻ると完了です
~/.aws/config には次のようなプロファイルが作られます。
[profile dev]
login_session = arn:aws:iam::111111111111:user/your-user
region = ap-northeast-1
確認は get-caller-identity で行います。
aws sts get-caller-identity --profile dev
Arn が IAM ユーザーの ARN になっていれば成功です。UserId は IAM ユーザーなら AIDA で始まる ID、ロールなら AROA で始まるロール ID と :<セッション名> になります（aws:userid の値）。
{
"UserId": "AIDAJPQTIG3UOYXEXAMPLE",
"Account": "111111111111",
"Arn": "arn:aws:iam::111111111111:user/your-user"
}
パターン 2：IAM ユーザーからスイッチロール
aws login で取得したプロファイルを スイッチロールの元（source_profile） にします。これは従来のアクセスキーを source_profile にするスイッチロールと同じ書き方です（IAM ロールを使う設定）。
- パターン 1 の手順で
devプロファイルにaws loginしておきます -
~/.aws/configにスイッチロール用のプロファイルを追記します
[profile dev-admin]
role_arn = arn:aws:iam::222222222222:role/AdminRole
source_profile = dev
region = ap-northeast-1
- スイッチロール先のプロファイルを指定してコマンドを実行します
aws sts get-caller-identity --profile dev-admin
Arn が assumed-role/AdminRole/... になっていれば成功です。
{
"UserId": "AROAEXAMPLEADMINROLEID:botocore-session-1762300000",
"Account": "222222222222",
"Arn": "arn:aws:sts::222222222222:assumed-role/AdminRole/botocore-session-1762300000"
}
セッション名は既定で botocore-session-<UNIX 時刻> になります（変えたい場合は role_session_name を追記）。スイッチロール先のロールの信頼ポリシーで IAM ユーザー（またはアカウント）を許可し、IAM ユーザー側に sts:AssumeRole の権限が必要なのは、通常のスイッチロールと同じです。
パターン 3：SSO（IAM Identity Center）での aws sso login
SSO の場合は aws login ではなく、aws configure sso でプロファイルを作り、aws sso login でサインインします（IAM Identity Center 認証の設定）。
- 初回だけ、ウィザードでプロファイルを作ります
aws configure sso
- SSO session name・SSO start URL・SSO region・SSO registration scopes（既定のまま Enter）を入力します
- ブラウザが開くのでアクセスポータルで認証し、使うアカウントとロール（許可セット）を選びます
- 既定のリージョン・出力形式を入力し、最後のプロファイル名は
sso-devにします - この時点でサインインも済んでいます
~/.aws/config には次のようなプロファイルが作られます。
[profile sso-dev]
sso_session = my-sso
sso_account_id = 111111111111
sso_role_name = PowerUserAccess
region = ap-northeast-1
output = json
[sso-session my-sso]
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access
- 2 回目以降（トークンの期限切れ後など）は
aws sso loginだけでサインインできます
aws sso login --profile sso-dev
- 確認します
aws sts get-caller-identity --profile sso-dev
Arn が assumed-role/AWSReservedSSO_<許可セット名>_xxxx/<ユーザー名> になっていれば成功です。
{
"UserId": "AROAEXAMPLESSOROLEID:your-user",
"Account": "111111111111",
"Arn": "arn:aws:sts::111111111111:assumed-role/AWSReservedSSO_PowerUserAccess_xxxxxxxxxxxx/your-user"
}
パターン 4：SSO からスイッチロール
パターン 2 と同じく、パターン 3 で作ったプロファイルを source_profile にします。
- パターン 3 の手順で
sso-devプロファイルにaws sso loginしておきます -
~/.aws/configにスイッチロール用のプロファイルを追記します
[profile sso-dev-admin]
role_arn = arn:aws:iam::222222222222:role/AdminRole
source_profile = sso-dev
region = ap-northeast-1
- スイッチロール先のプロファイルを指定してコマンドを実行します
aws sts get-caller-identity --profile sso-dev-admin
Arn が assumed-role/AdminRole/... になっていれば成功です。
{
"UserId": "AROAEXAMPLEADMINROLEID:botocore-session-1762300000",
"Account": "222222222222",
"Arn": "arn:aws:sts::222222222222:assumed-role/AdminRole/botocore-session-1762300000"
}
許可セットのロール ARN は付け直すと末尾が変わるため、スイッチロール先の信頼ポリシーは Principal をアカウント（arn:aws:iam::<元アカウント>:root）にし、aws:PrincipalArn を ArnLike で arn:aws:iam::<元アカウント>:role/aws-reserved/sso.amazonaws.com/*AWSReservedSSO_<許可セット名>_* に絞るのが良さそうです（許可セットの参照方法。
Identity Center が us-east-1 だと ARN にリージョンが入らないため、/*/ ではなく /*AWSReservedSSO_ にしています）。
ログアウト
aws logout（パターン 1・2）、aws sso logout（パターン 3・4）でキャッシュされた認証情報を削除できます。
aws logout --profile dev # aws login：プロファイル単位
aws logout --all # aws login：全プロファイルのキャッシュを削除
aws sso logout # aws sso login：全プロファイル分の SSO トークンと認証情報のキャッシュを削除
どちらも ~/.aws/config のプロファイルは残ります。
スイッチロール先は、パターン 2 は aws logout 直後から使えなくなり、パターン 4 は aws sso logout 後もキャッシュが残るため有効期限の 15 分前（既定なら取得から約 45 分）までは使えます。
注意点
-
セッションの長さ:
aws loginの認証情報は 15 分ごとに自動更新され、最長 12 時間（主体の最大セッション時間まで）有効です -
ロールチェーン: パターン 4 はロールからロールへのスイッチなので、
duration_secondsを 3600 より大きくすると失敗します -
プロファイルは分ける: サインイン用（
dev/sso-dev）とスイッチロール用（dev-admin/sso-dev-admin）は別にし、ログインはサインイン用のプロファイルで行います -
ブラウザがない環境: SSH 先のサーバーなどでは
aws login --remote/aws sso login --use-device-codeで別端末のブラウザからログインできます
まとめ
- IAM ユーザーは
aws login、SSO はaws sso loginで、どちらも長期のアクセスキーなしで CLI の一時認証情報を取れます - スイッチロールは、どちらの場合もサインインしたプロファイルを
source_profileに指定するだけで使えます