--- title: "aws loginコマンドの実行手順とsso login・アクセスキーとの使い分け" url: "https://www.issoh.co.jp/tech/details/17567/" published: 2026-09-11 updated: 2026-10-04 categories: ["AWS"] publisher: "株式会社一創" --- # 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に届いていなければ、[公式のインストール手順](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)で更新してください。v1系を使い続けている環境では選択肢に入らないため、[AWS CLI v2の設定とv1サポート終了への移行手順](https://www.issoh.co.jp/tech/details/17403/)を先に通します。 ### AWS CLI 2.32.0で追加されたaws loginの位置づけと発表時期 AWS CLIの[CHANGELOG](https://github.com/aws/aws-cli/blob/v2/CHANGELOG.rst)には、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の認証にコンソール認証情報を使用可能](https://aws.amazon.com/jp/about-aws/whats-new/2025/11/console-credentials-aws-cli-sdk-authentication/)という発表が出ています。 直後の2.32.1でPython 3.9から3.11までの非互換が修正され、2.32.32では「既存の別方式の認証情報が入っているプロファイルをaws loginが書き換えないようにする」改善が入りました。初期版に触れた環境ほど、後述するプロファイルの混在事故を踏みやすかった経緯が読み取れる履歴です。執筆時点の最新は2.36.42系でした。 ### SignInLocalDevelopmentAccessポリシーの2アクションと付与先 IAMユーザーやロールでaws loginを使うには、AWS管理ポリシー`SignInLocalDevelopmentAccess`をアタッチします。[ポリシーのリファレンス](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SignInLocalDevelopmentAccess.html)によれば、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のユーザー・ロール・ポリシーの使い分け](https://www.issoh.co.jp/tech/details/15427/)を先に整えてください。 ## 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の値と読み方 認証が終わると、[公式ドキュメント](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sign-in.html)のとおり`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の設定手順とトークン期限・デバイスコード認可・エラー対処](https://www.issoh.co.jp/tech/details/17853/)で詳しく扱っています。[Identity Center側の設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html)では、初回に`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との使い分け](https://www.issoh.co.jp/tech/details/15900/)で判断してください。単一アカウントしか触らないならaws loginで足り、アカウントが増えて人の出入りが発生する段階でIdentity Centerへ寄せる順序が現実的です。 ### 長期アクセスキーからaws loginへ移す際の残作業と削除順序 移行で失敗しやすいのは、新方式を足しただけで古い鍵を消し忘れるパターンです。順序を固定してください。まずaws loginで新しいプロファイルを作り、`aws sts get-caller-identity`で意図したARNが返ることを確認（ARNの読み方は[aws sts get-caller-identityの使い方](https://www.issoh.co.jp/tech/details/18084/)を参照）。次に`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 : : 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のインフラ構築](https://www.issoh.co.jp/service/system/aws/)として設計から引き受けています。 ### 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要素と実装方式](https://www.issoh.co.jp/tech/details/13314/)に整理しています。ルートのaws loginセッションが12時間有効という点も見落とせません。作業が終わったら`aws logout`まで実行する。この1手間で、放置された最上位権限のセッションを消せます。 ## マネジメントコンソールのサインインURLとIAMユーザーへの配布 同じキーワードで探される「コンソールへのログイン」側も押さえます。IAMユーザーに配るURLの形式と、監査ログの発火先が主な論点です。 ### アカウントIDとエイリアスを含むサインインURLの2つの指定形式 [IAMユーザーのサインインに関する公式ドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id%5Fusers%5Fsign-in.html)では、アカウント専用のサインインページを`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トークン検証](https://www.issoh.co.jp/tech/details/15821/)で方式の違いを確認してください。 ## よくある質問 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アカウントに同時サインインできますか？ できます。[公式ドキュメント](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/multisession.html)では、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だけを許可し、ポート開放を情報システム部門と調整してください。 ## 関連記事 - [AWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順](https://www.issoh.co.jp/tech/details/17403/)：CLI本体の導入とv2移行を扱っています。 - [AWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分け](https://www.issoh.co.jp/tech/details/15900/)：sso login側へ寄せる場合の権限セット設計が分かります。 - [AWS IAMとは？ユーザー・ロール・ポリシーの違いと権限設計の基準](https://www.issoh.co.jp/tech/details/15427/)：入口を足す前に整える権限設計の全体像です。 - [多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFA](https://www.issoh.co.jp/tech/details/13314/)：ルートに掛けるMFAの方式選定に使えます。 - [シングルサインオン（SSO）とは？4つの実現方式とIDトークン検証](https://www.issoh.co.jp/tech/details/15821/)：社内IdP経由へ切り替える設計の前提です。 --- 出典: [aws loginコマンドの実行手順とsso login・アクセスキーとの使い分け]()（株式会社一創）