AWS CLI/SDK認証の新時代:aws login で変わる開発体験

記事タイトルとURLをコピーする

神奈川県からこんにちは、アプリケーションサービス部の千葉です。

AWS re:Invent 2025(のちょっと前で、ホントは11/19なのですが)に発表された「Console認証情報のCLI/SDK利用」機能は、AWS開発者の認証体験を大きく変える可能性を秘めています。
本記事では、従来の認証方法との違いを具体的なコード例とともに解説します。

「ブラウザ認証でCLI」は前からあったのでは?

「ブラウザで認証してAWS CLIを使う」と聞いて、「それ、前からあったよね?」と思った方もいるかもしれません。

確かにaws sso login コマンドは以前から存在していました。
しかし、今回発表された aws login は全く別物です。

aws sso loginaws 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
  1. コマンド実行後、ブラウザが自動で開く
  2. AWSコンソールの認証画面でログイン(MFA含む)
  3. 認証完了後、一時認証情報が自動的に設定される

認証後の利用

# すぐに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:AuthorizeOAuth2Accesssignin: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以降をお使いの方は、ぜひ試してみてください。

千葉 哲也 (執筆記事の一覧)

アプリケーションサービス部

コーヒーゼリーが好きです。