NTTテクノクロス株式会社の渡邉です。
今回はAWS CLIの新機能を試し、既存で出来なかった運用を探っていきたいと思います。
はじめに
本日のAWS CLIのアップデートでサブコマンドの「aws login」が追加になりました。
検証した結果として表題の通り、GitHub CodespacesをはじめとするWeb IDEでもAWS IAMが使いやすくなり、アクセスキー運用を減らせることが分かりました。
AWSにおけるWeb IDE事情
AWS IAMの権限を扱うことのできるWeb IDE(リモート開発環境)は、AWSでも「AWS Cloud9」というサービスがあるのですが、2024年7月25日以降では古いAWSアカウントでしか利用できない状態であり、事実上のメンテナンスフェーズ相当の状況です。
AWSは移行先としてAmazon CodeCatalystを推奨していて、確かにここでもIDEが利用できたのですが、2025年10月にこちらも新規利用が停止されてしまい、代替えにするのは難しい状況です。
一応サービスとして、「SageMaker Studio コードエディタ」もあるのですが、UIがややこしかったり、セットアップがやや複雑です。個人利用にはともかく、ハンズオンなどで他者に利用してもらうには、扱わせづらい点があります。
そのため、GitHub CodespacesなどのサードパーティのIDEを利用し、AWS IAMについては設定を色々工夫している人が多いと思います。
3rd Party Web IDEでのAWS IAM
Web IDEでAWS CLIやAWS CDKを利用する場合、AWS IAMの権限を通す必要があり、基本的に面倒です。
アクセスキーについては長期的な認証情報のため、漏洩リスクが高く、セキュリティ上の理由で利用が推奨されていないため、利用者のリスク判断で利用することになります。
IAM Identity Centerがあることを前提に置けばaws configure ssoが利用できますが、セットアップ手順が複雑で、初心者には敷居が高く、そもそも組織によってはIAM Identity Centerを導入していない・できないケースもあるでしょう。
これらの課題が、今回のaws loginで解決できそう、ということで試してみます。
aws login
一言でいうと、ブラウザでログイン中の権限でAWSのプロファイルを作る機能です。IAM 認証情報 (ルートまたは IAM ユーザー) でも、フェデレーティッドユーザーでも、ブラウザ認証を経由してCLI用の短期クレデンシャルを取得できます。
aws loginはOAuth 2.0のデバイス認証フローを使用しており、長期的なアクセスキーを発行することなく、既存のブラウザセッションを活用してCLI環境に権限を付与できます。
aws loginが必要なIAMについて、以下のアクションを使うので、組織内で制御したい時やCloudTrailを追いたい場合はこの2つをチェックしましょう。以降の検証では、Admin相当のロールでログイン済とし、この条件を満たされているものとします。
signin:AuthorizeOAuth2Accesssignin:CreateOAuth2Token
検証手順
それでは、GitHub Codespacesでaws loginの使い方を検証しましょう。
0. 前提
古い環境ではAWS CLI v2のアップデートが必要です。GitHub Codespacesを開き、公式の導入手順を参考にAWS CLIをv2.32.0以降に更新します。
aws --version
aws-cli/2.32.1 Python/3.13.9 Linux/6.8.0-1030-azure exe/x86_64.ubuntu.24
# プロファイルは何もない
aws configure list-profiles
1. ログイン
公式の手順を参考に、このようなコマンドを入力します。
aws login --remote --profile dev
--remoteオプションは、CLIの実行環境とブラウザが違う場合に指定するオプションです。GitHub Codespacesを使っている場合、ブラウザのタブA(AWSマネジメントコンソール)とタブB(GitHub Codespaces)という構成になるので、このオプションは必須です。
--profileでプロファイル名を指定して、新しくプロファイルを作ることも簡単です。
実行すると、このようにURLが表示されますのでクリックします。
aws login --remote --profile dev
Browser will not be automatically opened.
Please visit the following URL:
https://us-west-2.signin.aws.amazon.com/v1/authorize?response_type=code&client_id=arn%3Aaws%3Asignin%3A%3A%3Adevtools%2Fcross-device&state=acd40659-053c-4fac-ad31-5789dfb87a31&code_challenge_method=SHA-256&scope=openid&redirect_uri=https%3A%2F%2Fus-west-2.signin.aws.amazon.com%2Fv1%2Fsessions%2Fconfirmation&code_challenge=pXG7hTgWit-9edQ1ZA7TrlcV81BQVibK7RkMDF0dsag
Enter the authorization code displayed in your browser:
URLをクリックすると、このようにサインイン済の認証情報を選択できる画面へ遷移します。
遷移後の画面は、アカウント情報を特定できる識別子がかなり含まれており、ここでは公式ブログの画像で代替しています。
ログイン済みの認証情報を選択すると、認証が成功し、このような画面が出てきます。
「Copy verification code」をクリックでクリップボードにコピーできるので、GitHub Codespaces上の「Enter the authorization code displayed in your browser: 」へ、Verification Codeを貼り付けます。
すると、このコマンドが成功し、認証情報をAWS CLIで使えるようになったことが分かります。
aws sts get-caller-identity --profile dev
2. 確認
-
--profileオプションで指定したプロファイル(dev)が作成できています。
aws configure list-profiles
dev
- プロファイル(dev)の内容はこんな感じ。
aws configure list --profile dev
NAME : VALUE : TYPE : LOCATION
profile : dev : manual : --profile
access_key : ****************Y75H : login :
secret_key : ****************gSI4 : login :
region : us-west-2 : env : ['AWS_REGION', 'AWS_DEFAULT_REGION']
3. AWS CLI以外
この後に試したところ、作ったプロファイルではCDKのデプロイもできなかったり、Clineに指定できなかったりといった様子であった。このプロファイルはどうなっているのだろう。
試しに ~/.aws/configを開いてみる。
cat ~/.aws/config
[profile dev]
login_session = arn:aws:sts::<accountId>:assumed-role/AWSReservedSSO_AWSAdministratorAccess_xxxx/user
[profile sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start/
sso_region = ap-northeast-1
sso_account_id = xxxxxxxxxxxxx
sso_role_name = AWSAdministratorAccess
region = us-west-2
output = json
どうやらConfigのフォーマットが違う様子です。AWS CLIのプロファイルのスキーマを見てみましょう。
いつも見慣れたこのような形式や、前述のSSOとはまた違うようです。今回aws loginで設定したlogin_sessionというキーに対応していないと推測されます。対応を待つしかなさそうです。
[default]
aws_access_key_id=ASIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
aws_session_token = IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZVERYLONGSTRINGEXAMPLE
追記
AWS CDKの問題については、単に検証が早すぎたらしく、AWS SDKをアップデートすれば治る問題と考えられます。11/19にリリースされたAWS SDK v3.936.0では
credential-provider-login: add login credential provider (#7512) (2c08b1e0)
とあり、これを利用すれば解決する問題と想定されます。
まとめ
aws loginを使うことでリモート環境やWeb IDEのような環境にも、手元のマシンのブラウザでサインインしたIAM情報を使ってCLIを実行することが出来そうです。CLIのProfileについてはフォーマットが異なるため、既存のAWS CLIのプロファイルを前提とした各種エコシステムについては、これからの追従を期待する、とするのが良さそうです。
Appendix.
aws loginのProfile仕様が違うということは、他の仕様も違うか気になるところです。/.aws/を見てみましょう。
ls ~/.aws/
config login
~/.aws/configについては前述の通りですが、~/.aws/loginというディレクトリは気になります。調べてみると中にはこのようにJSONが入っていました。
ls ~/.aws/login/cache/
c055202f0b421e246102ac2801f988d1fc8eb79975287243b02198dddf40ce73.json
公式ドキュメントに書いてありました。ログイン情報のキャッシュのようです。

