神奈川県からこんにちは、アプリケーションサービス部の千葉です。
AWS re:Invent 2025(のちょっと前で、ホントは11/19なのですが)に発表された「Console認証情報のCLI/SDK利用」機能は、AWS開発者の認証体験を大きく変える可能性を秘めています。
本記事では、従来の認証方法との違いを具体的なコード例とともに解説します。
「ブラウザ認証でCLI」は前からあったのでは?
「ブラウザで認証してAWS CLIを使う」と聞いて、「それ、前からあったよね?」と思った方もいるかもしれません。
確かにaws sso login コマンドは以前から存在していました。
しかし、今回発表された aws login は全く別物です。
aws sso login と aws login の違い
| 観点 | aws sso login(従来) |
aws login(新機能) |
|---|---|---|
| リリース時期 | 以前から存在 | 2025年11月 |
| 前提条件 | IAM Identity Center(旧SSO)の組織導入が必要 | 不要 |
| 対象ユーザー | Identity Center管理下のユーザー | コンソールにログインできる全ユーザー |
| 初期設定 | aws configure sso でプロファイル設定が必要 |
設定不要 |
| 個人アカウント | 導入ハードルが高い | すぐに使える |
つまり aws login の革新性は「Identity Center不要で誰でも使える」という点にあります。
これまでの認証方法と課題
方法1: 長期アクセスキーの利用
# IAMコンソールでアクセスキーを発行後、手動で設定 aws configure AWS Access Key ID [None]: AKIxxxxxxxxxxxxxxxxx AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
課題:
- アクセスキーが
~/.aws/credentialsに平文で保存される - キーの定期ローテーションが必要(しかし実際には放置されがち)
- GitHubへの誤コミットによる漏洩事故が頻発
- チームメンバー間でのキー共有という悪習慣も…(当社じゃないですよ!
方法2: AWS IAM Identity Center (旧SSO) + aws sso login
# 事前にIdentity Centerの設定が必要 aws configure sso aws sso login --profile my-sso-profile
課題:
- 組織でIdentity Centerの導入・設定が前提
- 個人アカウントや小規模チームには導入ハードルが高い
- プロファイル設定が煩雑
方法3: 環境変数での一時認証情報
# STSで一時認証情報を取得して設定 export AWS_ACCESS_KEY_ID=ASIA... export AWS_SECRET_ACCESS_KEY=... export AWS_SESSION_TOKEN=...
課題:
- 取得・設定が手動で面倒
- セッション切れのたびに再取得が必要
新機能: aws login による認証
何が新しいのか
2025年11月19日、AWSは aws login コマンドを発表しました。
これにより、AWSコンソールにログインできるユーザーなら誰でも、Identity Centerの導入なしにブラウザ認証でCLI/SDKを利用できるようになりました。
要件
- AWS CLI 2.32.0 以降
- IAMユーザーの場合:
SignInLocalDevelopmentAccessマネージドポリシーの付与 - ルートユーザーの場合: 追加の権限設定は不要
- Python (boto3) で利用する場合:
botocore[crt]のインストールが必要
認証フロー
# これだけ aws login
- コマンド実行後、ブラウザが自動で開く
- AWSコンソールの認証画面でログイン(MFA含む)
- 認証完了後、一時認証情報が自動的に設定される
認証後の利用
# すぐにCLIが使える aws s3 ls aws ec2 describe-instances
# 事前に botocore[crt] のインストールが必要 # pip install "botocore[crt]" import boto3 # 認証情報の明示的な設定は不要 dynamodb = boto3.resource('dynamodb') table = dynamodb.Table('my-table') response = table.scan()
// Node.js (AWS SDK v3) も同様 import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3"; // 認証情報は自動で解決される const client = new S3Client({ region: "ap-northeast-1" }); const response = await client.send(new ListBucketsCommand({}));
認証情報の自動リフレッシュ
aws login で取得した一時認証情報は、AWS CLI/SDK によって 15分ごとに自動リフレッシュされます。
セッションの有効期限はIAMプリンシパルの設定に依存し、最大12時間です。
比較表
| 観点 | 長期アクセスキー | aws sso login |
aws login(新機能) |
|---|---|---|---|
| 初期設定 | キー発行が必要 | Identity Center + プロファイル設定 | 不要 |
| 組織での導入 | 不要 | 必要 | 不要 |
| 認証情報の寿命 | 無期限(危険) | 一時的 | 一時的 |
| リフレッシュ | 手動 | 自動 | 自動(15分ごと) |
| 漏洩リスク | 高い | 低い | 低い |
| 個人アカウント対応 | ○ | △(設定が大変) | ◎ |
| 導入の手軽さ | △ | × | ◎ |
どんな人に嬉しいのか
1. 個人開発者・学習者
# AWSアカウント作成後、すぐに開発開始できる aws login python my_first_lambda_deploy.py
アクセスキーの発行・管理という「最初のつまずき」がなくなります。
Identity Centerの設定も不要です。
2. 小規模チーム
# Identity Centerを導入していなくても安全な認証が可能 aws login
組織的なSSO基盤がなくても、各メンバーが安全にCLIを利用できます。
3. チーム開発
# 新メンバーのオンボーディング # 「アクセスキーを発行して共有」という危険な慣習が不要に aws login # 各自が自分の認証情報で作業
4. セキュリティ意識の高い組織
# 長期アクセスキーの全廃が現実的に # 監査対応も容易に aws login # 一時認証情報のみで運用
IAM管理者は、Service Control Policies (SCPs) で signin:AuthorizeOAuth2Access と signin:CreateOAuth2Token アクションを制御することで、組織全体での利用を管理で きます。
注意点・制限事項
本番環境での利用
この機能は 開発者のローカル環境 での利用を想定しています。
NG: EC2インスタンス上のアプリケーション → IAMロールを使用 NG: Lambda関数 → 実行ロールを使用 NG: CI/CDパイプライン → IAMロールまたはOIDC連携を使用
IAMユーザーへの権限付与
ルートユーザー以外で利用する場合、SignInLocalDevelopmentAccess マネージドポリシーをIAMユーザー、ロール、またはグループにアタッチする必要があります。
利用可能リージョン
すべてのAWS商用リージョンで利用可能です(中国リージョンとGovCloudを除く)。
まとめ
| Before | After |
|---|---|
| アクセスキーを発行 | aws login を実行 |
| credentialsファイルに保存 | ブラウザで認証 |
| 漏洩リスクと戦う | 一時認証情報で安心 |
| 定期ローテーション作業 | 15分ごとに自動リフレッシュ |
| Identity Center導入が必要(SSO利用時) | 導入不要 |
aws login は、Identity Centerを導入していない環境でも、安全なブラウザ認証を実現する画期的な機能です。
AWS CLI 2.32.0以降をお使いの方は、ぜひ試してみてください。