9
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 20

Japan AWS Jr. Champions Advent Calendar 2025

@yuki_0inJapan AWS Jr. Champions

「aws login」コマンドを試してみた話

Posted at

はじめに

2025年11月19日に、AWS CLIの新機能「aws login」コマンドが発表されました🎉

世界最速記事なんてものからは程遠いですが、、、
本記事では、実際に「aws login」コマンドを試してみた手順、「aws login」コマンドのメリット・デメリット、今後の展望について記載しております。

「aws login」コマンドとは？

「aws login」は、AWS CLI v2.32.0以降で利用可能な新しいコマンドで、以下の特徴があります。

  • 長期アクセスキーの作成や管理をすることが不要
  • AWSマネジメントコンソールで既に使用しているサインイン方法と同じ方法でサインインできる

実際に試してみた手順

それではさっそく「aws login」コマンドを試していきます！

前提条件

  • AWSマネジメントコンソールにログイン可能
  • 必要なIAM権限が付与されている

1. AWS CLIのバージョン確認とアップデート

  • 「aws --version」コマンドにてAWS CLIのバージョンを確認する
＞aws --version
  • v2.32.0以降ではない場合、アップデートする

※著者はWindows環境

＞msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi

image.png

Wizard画面に沿って進め、インストールする。
※既にインストール済みでも、このコマンドで最新版に上書きされる
※事前のアンインストールは不要

image.png

  • 再度AWS CLIのバージョンを確認し、 v2.32.0以降がインストール済みであることを確認する
＞aws --version

※v2.32.0以降になっていればOK！

2. 「aws login」コマンドの実行

  • 「aws login」コマンドにてログインしてみる
＞aws login
  • デフォルトブラウザが自動的に起動するので、既存セッションの利用 or 新規ログインを選択

※ 既存のセッションの利用を選択
※「Sign into new session」で、任意のAWSアカウントにログインしなおすことも可能

image.png

  • 認証成功画面が表示されること
    　（認証情報は正常に共有されました。セッションの有効期限が切れるまでご利用いただけます。このタブを閉じてください。）

image.png

  • 認証確認のため「aws sts get-caller-identity」コマンドを実行
aws sts get-caller-identity

image.png

あれ、上手くいかない。。。。😢

ってことで、エラーの原因と解決策を探っていきます。

3.遭遇したエラーと解決法（同じエラーにならなかった場合は飛ばしてOK！）

症状

aws loginでログインは成功するが、その直後に認証確認のためaws sts get-caller-identityコマンドを実行すると以下のエラーが発生:

＞aws login
# ブラウザ認証成功
Updated profile default to use arn:aws:sts::... credentials.

＞aws sts get-caller-identity
#失敗
An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid.
#上記エラー文が表示される

原因

~/.aws/credentialsファイルに古い静的認証情報が残っていた

調査したところ、どうやらAWS CLIは認証情報を以下の優先順位で参照するとのこと:

  1. 環境変数
  2. credentialsファイルの静的キー ← これが優先された
  3. SSOトークン

つまり、aws loginでSSOトークンは正しく取得できていたが、credentialsファイルに存在する古いaws_access_key_idとaws_secret_access_keyが優先的に使用され、その認証情報が無効だったためエラーが発生。

解決方法

~/.aws/credentialsから古い認証情報を削除:

＞notepad %USERPROFILE%\.aws\credentials

以下の部分を削除して保存:

[default]
aws_access_key_id = AKIA................
aws_secret_access_key = ................................

削除後、再度ログイン:

＞aws login
# ブラウザ認証成功

＞aws sts get-caller-identity
{
    "UserId": "AROAXXXXXXXXXXXXXXXXX:my-session-name",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/my-role-name/my-session-name"
}

aws sts get-caller-identityコマンドで認証確認成功！！嬉しい！！

ポイント

  • SSO環境ではcredentialsファイルに静的キーは不要
  • 古いIAMユーザーのキーが残っていると、SSOログインしても優先的に使用されてしまう
  • aws loginコマンド使用時はcredentialsファイルをクリーンに保つ必要がある

遭遇したエラーをまとめると以下にまとめます。

遭遇したエラーまとめ
既存のaws configureと競合しているため、上手くいかない！！

症状： aws loginを実行しても、古いアクセスキーが使用される
原因： ~/.aws/credentialsに保存された古い認証情報が優先される
解決策： ~/.aws/credentialsから古い認証情報を削除

やっと、認証確認が成功したのでAWS CLIコマンドを試していきます！

3. AWS CLIコマンドを試してみる

＞aws s3 ls

無事成功！！

4. スイッチロール先の権限をそのままCLIで利用できるか確認（おまけ）

「aws login」コマンドが無事成功したので、コンソール上でスイッチロールしてみて、スイッチロール先のアカウントが簡単に触れるのかおまけで試してみようと思います。
きっとアクティブなセッションにサインインできるのでいけるはず！！

  • ブラウザ（コンソール上）でアカウント①からアカウント②へスイッチロールする
  • CLIで「aws login」コマンドを入力
  • デフォルトブラウザが自動的に起動し、既存セッションの利用 or 新規ログインを選択できるので「既存セッション」を選択

image.png
※このとき既存セッションにはスイッチロール先のアカウント②のIDが表示される

あれ、上手くいかない。。。。part2😢
「400エラー」が表示されてしまいました。

image.png

ってことで、エラーの原因と解決策をまたまた探っていきます。

5.遭遇したエラーと解決法 part2（同じエラーにならなかった場合は飛ばしてOK！）

原因

スイッチロール先のアカウントにて権限が不足していたため

解決方法

  • スイッチロール先のアカウントにて、マネージドポリシー SignInLocalDevelopmentAccessまたは、signin:AuthorizeOAuth2Accessとsignin:CreateOAuth2Tokenの権限を付与する
  • 再度CLIで「aws login」コマンドを入力
  • デフォルトブラウザが自動的に起動し、既存セッションの利用 or 新規ログインを選択できるので「既存セッション」を選択
  • 認証成功画面が表示される
    image.png
  • CLI上に下記が表示されるため、
    「y」でdefaultプロファイルを上書きして進む or 下記記載の「6. 推奨：プロファイル名を分けて管理」 を参考に進める 
Profile default is already configured to use session 
arn:aws:sts::111111111111:assumed-role/BaseAccount-Role/user@example.com. 

Do you want to overwrite it to use 
arn:aws:sts::222222222222:assumed-role/SwitchRole-Role/user@example.com 
instead? (y/n): y

このメッセージの意味:
defaultプロファイルは既に 元のアカウント①(111111111111) のセッションで設定されています。
これを スイッチロール先のアカウント②(222222222222) のセッションに上書きしますか?という確認。

  • yを選択: スイッチロール先のアカウントがdefaultプロファイルとして設定される

  • nを選択: 元のアカウントの設定を維持

  • 認証完了後、動作確認

＞aws sts get-caller-identity

{
    "UserId": "AROAXXXXXXXXXXXXXXXXX:user@example.com",
    "Account": "222222222222",
    "Arn": "arn:aws:sts::222222222222:assumed-role/SwitchRole-Role/user@example.com"
}
  • スイッチロール先のアカウント②(222222222222)の権限でCLIが実行できることを確認する
＞aws s3 ls

無事成功！！（アカウント②のS3バケット一覧が取得できました）

遭遇したエラーまとめ Part2
「aws login」コマンドにてスイッチロール先の権限でCLI利用が出来ない

症状： aws loginを実行しても、400エラーが表示される
原因： スイッチロール先のアカウントにて権限が不足していたため
解決策： スイッチロール先のアカウントにマネージドポリシー SignInLocalDevelopmentAccessまたは、signin:AuthorizeOAuth2Accessとsignin:CreateOAuth2Tokenの権限を付与する

6. 推奨：プロファイル名を分けて管理

上記のような場合、毎度defaultプロファイルを上書きするのは、あまりベストプラクティスとは言えなそうなので、defaultプロファイルを上書きするのではなく、アカウントごとにプロファイル名を分けること推奨します。

# 元のアカウント用
aws login --profile base-account

# スイッチロール先アカウント用
aws login --profile switch-account

メリット:

  • 両方のアカウントを同時に使い分けられる
  • 誤操作のリスクを減らせる
  • どのアカウントで作業しているか明確

使用例:

# 元のアカウントでS3操作
aws s3 ls --profile base-account

# スイッチロール先のアカウントでS3操作
aws s3 ls --profile switch-account

設定ファイルの例:

~/.aws/config

[profile base-account]
login_session = arn:aws:sts::111111111111:assumed-role/BaseAccount-Role/user@example.com
region = ap-northeast-1

[profile switch-account]
login_session = arn:aws:sts::222222222222:assumed-role/SwitchRole-Role/user@example.com
region = ap-northeast-1

メリット

ここまで実際に触ってみたこととドキュメント記載内容を踏まえて、メリットについて考えてみます。

セキュリティの大幅な向上

アクセスキーの漏洩リスクを排除できるため、セキュリティの向上につながる。

  • 長期認証情報をローカルに保存する必要がない
  • 短期的な認証情報のみを使用するため、万が一の漏洩時の影響も限定的

認証の簡素化

「aws login」コマンド1つのシンプルな認証フローでログインが可能。

  • 「aws login」コマンド一つでログイン完了
  • ブラウザで既にログイン済みであれば、ほぼワンクリックで認証完了
  • MFA設定済みの場合もブラウザ側で処理されるため、CLI側での操作は不要

マルチアカウント管理の利便性向上

スイッチロールとの親和性があるため、マルチアカウント管理が簡単になる。

  • ブラウザで使用しているスイッチロール先の権限をそのままCLIで利用可能
  • 複数アカウントを管理している場合でも、アカウントごとにアクセスキーを管理する必要がない

注意点
スイッチロール先のアカウントに必要なIAM権限を付与する必要あり
（上記参照）

デメリット（注意点）

次に、デメリット（注意点）についても同じくここまで実際に触ってみたこととドキュメント記載内容を踏まえて、考えてみます。

既存プロファイルとの競合

aws configureとの優先順位に注意する必要がある。

  • 既に aws configure で設定済みのプロファイルがある場合、そちらが優先される
  • defaultプロファイルを空にしておくことで問題を回避可能
  • Switch Role運用時は、プロファイル名を明示的に指定する必要あり
    　（そうでないと毎回defaultプロファイルを上書きになってしまう）

ツールの対応状況

現状非対応のツールもあるため、注意が必要。

  • AWS CDK: 未対応(執筆時点)
  • Terraform: 未対応(執筆時点)
  • 各種AWS SDKやサードパーティツール: 順次対応待ち

リモート環境での利用

リモート環境では「--remoteオプション」が必要なケースもあるようなので注意が必要。

  • ブラウザが起動できない環境では（EC2インスタンスなど、リモートサーバー上で使用する場合） 「aws login --remote」 を使用する必要がある

セッションの有効期限

セッション時間は最大12時間の制限があります。

  • マネジメントコンソールのセッション時間に依存します
  • 12時間を超える長時間作業には不向き

今後の展望

「aws login」コマンドを使用してみた率直な感想としては、「1つのコマンドと1クリックだけで使用が簡単！」 「アクセスキー不要で管理が楽！」 という印象が大きかったです。
また、今回調査をするうえでサインイン方法を比較してみました。

項目 aws configure aws configure sso aws login
設定の複雑さ アクセスキー・シークレットキーの入力 SSO URL等の詳細設定が必要 リージョンのみ
トークン管理 不要(長期認証情報) 手動で aws sso login が必要 自動更新
認証方式 アクセスキー(長期認証情報) IAM Identity Center (SSO) OAuth 2.0
認証情報の有効期限 無期限(削除するまで有効) 短期(通常1-4時間) 最大12時間(自動更新)
セキュリティ 漏洩リスクあり 短期トークン 短期トークン+自動更新

ぱっと比較した限りは、やはり「aws login」のメリットが大きいと感じたので、今後は「aws login」が主流になるのか注目していきたいと思います。

参考資料

9
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
9
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?