公開2026.09.11更新2026.10.04 16 人が閲覧（直近 30 日） AWS

aws loginコマンドの実行手順とsso login・アクセスキーとの使い分け

Q: aws loginとaws configureはどちらを使えばよいですか？

手元の開発端末で対話的に作業するならaws loginです。 aws configure で長期アクセスキーを平文保存する運用は、鍵の流出リスクとローテーションの手間が残ります。aws loginなら最大12時間で失効する一時認証情報を15分ごとに更新するため、端末から長期キーを無くせます。非対話の環境では、どちらも使わずIAMロールの引き受けに寄せてください。

Q: 1つのブラウザで複数のAWSアカウントに同時サインインできますか？

できます。 公式ドキュメント では、1つのブラウザで最大5つの異なるIDへ同時にサインインできると説明されています。ルート、IAM、フェデレーションのロールを任意に組み合わせられ、IDごとに別タブでコンソールが開く仕様です。機能はブラウザ単位のオプトインで、有効にするとコンソールURLにサブドメインが付くため、既存のブックマークは更新が要ります。

Q: aws loginの認証情報はどこに保存され、どう消せますか？

既定ではLinuxとmacOSが ~/.aws/login/cache 、Windowsがユーザープロファイル配下の .aws/login/cache です。保存先は環境変数 AWS_LOGIN_CACHE_DIRECTORY で変更できます。削除は aws logout で行い、login方式のプロファイルをまとめて閉じるなら --all を付けてください。

aws loginコマンドの実行手順とsso login・アクセスキーとの使い分け

aws loginは、AWSマネジメントコンソールのサインイン情報をそのままCLIとSDKの認証に使うコマンドです。AWS CLI 2.32.0で追加され、ブラウザで本人確認を済ませると、最大12時間の一時認証情報が手元に降ります。長期アクセスキーをcredentialsファイルに置く運用を、端末側の変更だけで畳めるようになりました。必要なバージョンと権限、configへ書かれる値、キャッシュの保存先、aws sso loginとの境界、ExpiredTokenの解決順序、CIで採用しない判断までを扱います。同じ語で検索される「コンソールへのログイン」側も併せて整理しました。

まとめ：aws loginで得られる12時間の一時認証情報と適用範囲

aws loginが使えるのは、AWS CLI 2.32.0以降で、ルート・IAMユーザー・IAMフェデレーションのいずれかでコンソールにサインインできる場合です。IAMユーザーとロールには管理ポリシーSignInLocalDevelopmentAccessが要ります。ルートなら追加権限は不要。IAM Identity Centerの組織は対象外で、従来どおりaws sso loginを使います。

得られる認証情報は15分ごとに自動更新され、セッション全体はIAMプリンシパルのセッション期間（上限12時間）で切れます。運用で最初に踏むのは権限不足ではなく、同じプロファイルに残っていた古いアクセスキーが優先されてExpiredTokenになる事故です。移行時はaws configure listのTYPE列がloginかを必ず確認してください。ブラウザを開く前提のコマンドなので、CI／CDや共有サーバーでは採用しません。

aws loginコマンドの前提条件とCLI 2.32.0以降のバージョン確認

導入判断の前に、バージョン・権限・ユーザー種別の3点を確認します。どれか1つでも外れていると、コマンド自体が存在しないか、ブラウザ認証の最後で拒否されます。手元のCLIが2.32.0に届いていなければ、公式のインストール手順で更新してください。v1系を使い続けている環境では選択肢に入らないため、AWS CLI v2の設定とv1サポート終了への移行手順を先に通します。

AWS CLI 2.32.0で追加されたaws loginの位置づけと発表時期

AWS CLIのCHANGELOGには、2.32.0の項目として「Adds the aws login command, which allows you to use your AWS Management Console credentials for CLI and SDK authentication」と記録されています。GitHubのタグ情報では2.32.0は2025年11月19日付。同日にAWSから開発者がCLIおよびSDKの認証にコンソール認証情報を使用可能という発表が出ています。

直後の2.32.1でPython 3.9から3.11までの非互換が修正され、2.32.32では「既存の別方式の認証情報が入っているプロファイルをaws loginが書き換えないようにする」改善が入りました。初期版に触れた環境ほど、後述するプロファイルの混在事故を踏みやすかった経緯が読み取れる履歴です。執筆時点の最新は2.36.42系でした。

SignInLocalDevelopmentAccessポリシーの2アクションと付与先

IAMユーザーやロールでaws loginを使うには、AWS管理ポリシーSignInLocalDevelopmentAccessをアタッチします。ポリシーのリファレンスによれば、ARNはarn:aws:iam::aws:policy/SignInLocalDevelopmentAccess、作成は2025年11月19日18時34分（UTC）、編集は2026年2月12日17時59分（UTC）で、既定バージョンはv3です。

許可しているアクションはsignin:AuthorizeOAuth2Accessとsignin:CreateOAuth2Tokenの2つだけ、リソースはarn:aws:signin:*:*:oauth2/public-client/*です。データ面の権限は含みません。「一時認証情報を発行してよい」という入口の許可であり、S3やEC2に何ができるかは既存のIAMポリシーがそのまま決めます。権限設計そのものはAWS IAMのユーザー・ロール・ポリシーの使い分けを先に整えてください。

aws loginの実行手順とブラウザ認証・configに書かれる設定値

ここからは実際の操作です。初回だけリージョンを聞かれ、2回目以降はコマンド1つでブラウザが開きます。

aws loginの初回実行でリージョンを尋ねられたときの入力内容

ターミナルでコマンドを打つと、既定ブラウザが開いてサインイン画面に遷移します。プロファイルを分けるなら--profile、リージョンを固定するなら--regionです。

$ aws --version

$ aws login

$ aws login --profile my-dev-profile

$ aws login --region ap-northeast-1

プロファイルが新規で、まだリージョンが決まっていない場合、CLIは「No AWS region has been configured.」に続けてAWS Region [us-east-1]:と尋ねてきます。入れた値はaws configure set region NEW_REGIONで後から変更できるので、国内向けのシステムならap-northeast-1で構いません。ブラウザが自動で開かないときは、ターミナルに表示されるhttps://signin.us-east-1.amazonaws.com/authorize形式のURLを手で開いてください。

configファイルに追記されるlogin_sessionの値と読み方

認証が終わると、公式ドキュメントのとおりconfigファイルにプロファイルが作られます。アクセスキーは書かれません。書かれるのはどのIAMプリンシパルのセッションを使うかという指定だけです。

[default]
login_session = arn:aws:iam::012345678901:user/username
region = us-east-1

login_sessionにARNが入る点が、従来のaws configureとの決定的な違いです。同じプロファイルで別のIAMユーザーにサインインし直すと、CLIは「Profile signin is already configured to use session …. Do you want to overwrite it …? (y/n):」と上書き確認を出します。読み取り専用ユーザーと管理者ユーザーを取り違えたまま作業を続ける事故は、この確認で止まる。確認が出たら、表示されているARNが意図どおりかを読んでください。

–remoteでの別端末認証とファイアウォール遮断時の切り替え

ブラウザのない踏み台や、社内のセキュリティ製品がOAuthコールバック用のポート開放を止める環境では、--remoteを使います。CLIはhttps://{region}.signin.amazonaws.com/authorizeで始まる一意のURLを表示し、ブラウザは自動で開きません。手元の端末でそのURLを開いて認証し、表示された認可コードをターミナルへ貼り戻します。

ポート開放を情報システム部門に依頼して待つより、この1オプションで済ませたほうが速い場面が多い。ただし後述するとおり、same-deviceとcross-deviceはIAM側で別々に許可・拒否できるため、--remoteを常用させる前に組織の方針を決めておく必要があります。

aws logoutでのキャッシュ削除先と–allによる一括終了

作業が終わったら、期限切れを待つかaws logoutでキャッシュを消します。プロファイル指定がなければ既定プロファイル、--profileを付ければ特定セッション、--allを付ければlogin方式のプロファイルすべてが対象です。

キャッシュの既定の置き場所は、LinuxとmacOSが~/.aws/login/cache、Windowsがユーザープロファイル配下の.aws/login/cacheです。環境変数AWS_LOGIN_CACHE_DIRECTORYで別の場所へ移せるため、暗号化ボリュームへ寄せたい要件があるならこの変数で管理してください。離席時は画面ロックではなくaws logout --allまで打つ運用が確実です。

aws loginとaws sso login・アクセスキーの選び分けの基準

3つの方式は代替関係ではなく、対象ユーザーで住み分けます。組織のID基盤がどこにあるかで選ぶコマンドが決まります。

IAM Identity Center利用時にsso loginへ振り分ける境界

公式の前提条件には「IAM Identity Centerを使う場合はIdentity Center認証の設定へ進む」と明記されています。Identity Centerの利用者がaws loginを打っても、目的の一時認証情報は得られません。sso-sessionの書き方や期限切れの対処はaws sso loginの設定手順とトークン期限・デバイスコード認可・エラー対処で詳しく扱っています。Identity Center側の設定では、初回にaws configure ssoでプロファイルを作り、以降はaws sso login --profile my-profileで更新します。

方式	対象ユーザー	有効期間	主な置き場所
aws login	ルート・IAM・IAM連携	最大12時間	手元の開発端末
aws sso login	Identity Centerの利用者	ポータル設定に従う	組織での常用
アクセスキー	IAMユーザー	無期限	非対話の旧環境のみ

組織のID基盤としてどちらを選ぶかは、IAM Identity Centerの権限セット設計とIAMとの使い分けで判断してください。単一アカウントしか触らないならaws loginで足り、アカウントが増えて人の出入りが発生する段階でIdentity Centerへ寄せる順序が現実的です。

長期アクセスキーからaws loginへ移す際の残作業と削除順序

移行で失敗しやすいのは、新方式を足しただけで古い鍵を消し忘れるパターンです。順序を固定してください。まずaws loginで新しいプロファイルを作り、aws sts get-caller-identityで意図したARNが返ることを確認（ARNの読み方はaws sts get-caller-identityの使い方を参照）。次にcredentialsから該当キーを削除し、最後にIAM側で無効化してから削除します。

逆にすると、鍵を消した直後に権限不足が判明して作業ができなくなります。IAM側の無効化を先に挟むのは、削除前に依存箇所の有無を確認できるからです。無効化して数日運用し、どこも壊れないことを確かめてから削除する。手元の端末に平文の長期キーが1枚も残っていない状態が、この移行の完了条件です。

ExpiredTokenエラーの原因と認証情報の解決元をたどる手順

aws loginの直後にExpiredTokenやAccessDeniedExceptionが出たら、権限ではなく解決元を疑います。原因はほぼ1つに絞れます。

aws configure listのTYPE列でloginかどうかを見分ける手順

公式のトラブルシューティングは、同じプロファイルに既存の認証情報と新しいlogin認証情報が混在している状態を原因として挙げています。aws configure listを実行し、TYPE列を読んでください。

$ aws configure list
NAME       : VALUE                    : TYPE                    : LOCATION
profile    : <not set>                : None                   : None
access_key : ****************MPLE     : login                   :
secret_key : ****************EKEY     : login                   :
region     : us-east-1                : config-file             : ~/.aws/config

TYPE列がloginなら、認証情報はaws loginのキャッシュから解決されています。ここがshared-credentials-fileやenvになっていれば、別の経路が勝っている状態です。--debugを付けて実行すると、どの経路をどの順で試したかまで出る。エラー文面を検索する前に、この1コマンドで解決元を確定させてください。

credentialsファイルと環境変数の残存キーが優先される順序

ホームディレクトリのcredentialsに書かれた長期キーは、login認証情報より先に解決されます。公式の例でも、TYPE列がshared-credentials-fileのときはそちらが優先されると説明されています。対処は、対象プロファイルの残存キーをconfigとcredentialsの両方から手で消すこと。シェルの初期化ファイルでAWS_ACCESS_KEY_IDを export している場合も同じで、新しいターミナルを開いてTYPE列がloginで揃うまで潰してください。

IAMポリシーで同一端末認証と別端末認証を分けて制御する権限設計

ここが上位記事の手薄な部分です。aws loginは「入れるか入れないか」の二択ではなく、同一端末認証と別端末認証を別々に許可できます。受託開発でクライアントのアカウントを触る場面では、この分離が実務上の要になります。

localhostとremoteのリソースARNで許可範囲を絞る書き方

公式ドキュメントは、same-device認証にarn:aws:signin:{region}:{account-id}:oauth2/public-client/localhost、cross-device認証に同じ形式のremoteを使うと案内しています。管理ポリシーのSignInLocalDevelopmentAccessは両方を含むワイルドカードなので、片方だけ許すならカスタマー管理ポリシーを書きます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "signin:AuthorizeOAuth2Access",
        "signin:CreateOAuth2Token"
      ],
      "Resource": "arn:aws:signin:ap-northeast-1:012345678901:oauth2/public-client/localhost"
    }
  ]
}

この書き方なら、開発端末でのaws loginは通り、aws login --remoteは拒否されます。認可コードを別端末へ持ち出す経路を閉じ、画面共有やチャットでコードが流れる事故を構造的に防ぎたい場合に採る形です。踏み台経由の運用が前提ならremoteだけを許可してください。両方を無条件に開けるのは、端末管理が行き届いた少人数チームまで。権限境界とネットワーク構成をまとめて設計し直す段階なら、AWS・Google Cloud・Azureのインフラ構築として設計から引き受けています。

CI/CDと共有端末でaws loginを採用しない条件と代替手段

結論から書きます。CI／CDでaws loginは採用しません。ブラウザでの本人確認が前提の設計なので無人実行では認証フローが完了せず、仮に通せたとしても12時間で切れる認証情報をパイプラインに持ち込む理由がありません。GitHub ActionsならOIDCでIAMロールを引き受ける方式、AWS内で動かすならタスクロールやインスタンスプロファイルを使います。夜間バッチや長時間のデータ移行も同じで、数時間を超える処理はEC2やLambdaへ載せ、手元の端末はロールを引き受けるまでの操作に限定してください。

共有の踏み台サーバーも見送りです。キャッシュは~/.aws/login/cacheに置かれるため、同じOSユーザーを複数人で使い回すと、誰のセッションで操作したのかが端末側から判別できません。CloudTrail上のIDは記録されても、操作の主体が追えない状態は監査で問題になります。共有サーバーではロールの引き受けに寄せてください。

ルートユーザーでのaws login実行を運用から外す判断基準

ルートユーザーはaws loginに追加権限が不要です。手軽ですが、日常運用では使いません。ルートには権限の絞り込みができず、CloudTrailで見ても操作を誰かに帰属させられないためです。アカウント作成直後にIAMユーザーやIdentity Centerを整えるまでの一時的な足場としてだけ使い、整い次第切り替えます。

ルートを残す場合は多要素認証を必須にしてください。方式の選定基準は多要素認証（MFA）の3要素と実装方式に整理しています。ルートのaws loginセッションが12時間有効という点も見落とせません。作業が終わったらaws logoutまで実行する。この1手間で、放置された最上位権限のセッションを消せます。

マネジメントコンソールのサインインURLとIAMユーザーへの配布

同じキーワードで探される「コンソールへのログイン」側も押さえます。IAMユーザーに配るURLの形式と、監査ログの発火先が主な論点です。

アカウントIDとエイリアスを含むサインインURLの2つの指定形式

IAMユーザーのサインインに関する公式ドキュメントでは、アカウント専用のサインインページをhttps://{My_AWS_Account_ID}.signin.aws.amazon.com/console/の形式で示しています。汎用エンドポイントはhttps://console.aws.amazon.com/で、アカウントIDまたはエイリアスを手入力します。

公式が添えている注意が実務的です。ブックマークはブラウザの機能で作らず、URLを手で入力して作る。リダイレクトによって本来のサインインURLが隠れてしまうためです。新しいメンバーへは、ユーザー名と初期パスワードにこのURLを揃えて渡し、初回サインインでパスワード再設定が求められる旨も添えてください。

サインイン監査をCloudTrailで残すためのエンドポイント指定

CloudTrailでサインインイベントを記録している場合、ログの出先はサインインしたURLで変わります。リージョン対応のコンソールへhttps://alias.signin.aws.amazon.com/consoleでサインインすると、https://us-east-2.signin.aws.amazon.comのようなリージョナルエンドポイントへリダイレクトされ、そのリージョンのログに残ります。リージョンを持たないS3コンソールへ直接サインインした場合は、グローバルのログになる。

特定リージョンに寄せたいなら、https://alias.signin.aws.amazon.com/console?region=ap-southeast-1のようにクエリで指定します。サインインログが見つからない相談は、この振り分けを知らず片方のログだけを見ているのが原因です。社内IdP経由へ切り替える場合は、シングルサインオンの4つの実現方式とIDトークン検証で方式の違いを確認してください。

よくある質問

aws loginの導入と移行で実際に問い合わせの多い点を、公式ドキュメントの記述に沿って答えます。

aws loginで発行された認証情報を古いSDKに渡せますか？

コンソール認証情報に未対応の古いSDKやツールには、CLIを外部認証情報プロバイダとして挟む回避策が公式に案内されています。login用のプロファイルでサインインしたうえで、別プロファイルにcredential_processを設定し、そこからCLIを呼び出す形です。

[profile signin]
login_session = arn:aws:iam::012345678901:user/username
region = ap-northeast-1

[profile process]
credential_process = aws configure export-credentials --profile signin --format process
region = ap-northeast-1

aws loginとaws configureはどちらを使えばよいですか？

手元の開発端末で対話的に作業するならaws loginです。aws configureで長期アクセスキーを平文保存する運用は、鍵の流出リスクとローテーションの手間が残ります。aws loginなら最大12時間で失効する一時認証情報を15分ごとに更新するため、端末から長期キーを無くせます。非対話の環境では、どちらも使わずIAMロールの引き受けに寄せてください。

1つのブラウザで複数のAWSアカウントに同時サインインできますか？

できます。公式ドキュメントでは、1つのブラウザで最大5つの異なるIDへ同時にサインインできると説明されています。ルート、IAM、フェデレーションのロールを任意に組み合わせられ、IDごとに別タブでコンソールが開く仕様です。機能はブラウザ単位のオプトインで、有効にするとコンソールURLにサブドメインが付くため、既存のブックマークは更新が要ります。

aws loginの認証情報はどこに保存され、どう消せますか？

既定ではLinuxとmacOSが~/.aws/login/cache、Windowsがユーザープロファイル配下の.aws/login/cacheです。保存先は環境変数AWS_LOGIN_CACHE_DIRECTORYで変更できます。削除はaws logoutで行い、login方式のプロファイルをまとめて閉じるなら--allを付けてください。

aws loginを実行するとファイアウォールの警告が出るのはなぜですか？

same-device認証では、CLIがOAuthのコールバックを受けるためにローカルのポートを開きます。セキュリティ製品がこれを外部からの接続要求と解釈し、遮断することがある。公式のトラブルシューティングは、ポート開放を待たずに--remoteへ切り替える方法を案内しています。別端末認証を許可しない方針なら、localhost側のリソースARNだけを許可し、ポート開放を情報システム部門と調整してください。