AWS CLIの解説記事の多くは、zipやmsiをダウンロードして展開する手順で止まっています。AWSは公式ドキュメントで、Linux・macOS・Windowsのいずれもインストールスクリプトを推奨方式に位置づけ、更新はaws updateで行う形に整理しました。同時に、AWS CLI v1はメンテナンスモードへ移行し、サポート終了日も公表されています。この記事では、v2のインストールをOS別・CPUアーキテクチャ別に整理し、バージョン固定やDockerでの実行、アンインストールまでを含めた導入手順が解説の対象です。そのうえで認証情報の設定、--queryによる出力の絞り込み、v1を使い続けている環境の移行判断を、AWS公式ドキュメントの記述と対応させながら順に解説します。
まとめ｜AWS CLI v2を先に入れてv1依存を洗い出す進め方
これから導入するなら選択肢はv2だけです。v1は2026年8月5日にメンテナンスモードへ入り、2027年7月15日にサポート終了を迎えるとAWS CLIのGitHubリポジトリに明記されました。メンテナンスモード中のリリースは重大なバグ修正とセキュリティ修正だけに絞られ、新サービスや新リージョンへの対応は入りません。
導入手順は3つに整理できます。インストールスクリプトでv2を入れ、認証はIAM Identity Centerのセッション設定に寄せ、既存スクリプトのうちv1固有の書き方をしている箇所を洗い出して直す。この順序なら、認証情報の配布方法を変える作業と移行作業を一度で終えられます。
インストール方式の選び方も先に結論を書きます。個人の端末はインストールスクリプト、版をそろえたいサーバーやCIはzip・pkg・msiのいずれかで版を指定、端末に入れたくない場面はDockerの公式イメージ。この3通りで、ほとんどの導入先を説明できます。
移行で壊れやすいのは4か所に集中します。aws ecr get-loginの廃止、タイムスタンプ出力のISO 8601統一、バイナリ引数のbase64既定化、そしてus-east-1でのS3エンドポイント変更です。CI上でこれらに依存した処理があると、コマンド自体は成功したまま後続のパース処理が落ちます。
AWS CLIでできる操作とマネジメントコンソールとの使い分け
AWS CLIは、AWSの各サービスAPIをコマンドとして呼び出す統合クライアントです。画面から行う操作のほとんどは同じ結果をコマンドで得られますが、コンソールと同じ作業をコマンドに置き換えること自体に価値はありません。
マネジメントコンソールでは再現しにくい反復作業とCLIの守備範囲
CLIが効くのは、同じ操作を条件だけ変えて何度も実行する場面です。たとえば「タグにEnv=stgを持つEC2インスタンスをすべて停止する」という作業は、コンソールでは対象の絞り込みとチェックを人が繰り返します。CLIなら絞り込み条件を引数に書けるため、実行内容がそのまま手順書になります。
逆に、初回のネットワーク設計やIAMロールの初期作成をCLIで進めると、途中経過が画面に残らず、レビューがしづらくなります。コマンドライン操作そのものの前提はCLIとGUIの使い分けで整理しています。判断の軸は「一度きりか、繰り返すか」です。繰り返さない設計作業はコンソール、繰り返す運用作業はCLI。
調査と復旧でCLIが効く場面と実行証跡を確実に残す運用上の書き方
障害対応でもCLIは強力です。CloudWatch Logsの直近10分を追うaws logs tailのように、v2で追加された高レベルコマンドは調査用途に向いています。結果を標準出力で受け取れるので、そのままチケットに貼れる形で証跡が残ります。
ただし復旧作業をCLIで進めるときは、実行したコマンドと出力をセットで記録してください。コンソール操作はCloudTrailに残りますが、どういう意図でその引数を選んだかは残りません。監視や計装まで含めた全体設計はAWSオブザーバビリティの実装で扱っています。
AWS CLI v2のインストール手順とaws updateによる更新の実際
公式ドキュメントのインストール手順は、Linux・macOS・Windowsのすべてでインストールスクリプトを推奨方式として先頭に置いています。日本語の解説記事に多いzip展開やmsi実行も引き続き使えますが、更新方法が変わるため、新規に入れるならスクリプト方式を選びます。
推奨されたインストールスクリプトの実行手順と導入先ディレクトリ
スクリプトはダウンロード・署名検証・インストールを1コマンドで実行します。既定では現在のユーザー向けにインストールされ、LinuxとmacOSは$HOME/.local/share/aws-cliに本体、$HOME/.local/binにシンボリックリンクが作られます。Windowsは%LOCALAPPDATA%\Programs\Amazon\AWSCLIV2が配置先です。全ユーザー向けに入れる場合だけ管理者権限が要り、Linuxでは/usr/local/aws-cli、WindowsではProgram Files配下へ入ります。
# Linux ・ macOS（現在のユーザーへ導入）
curl -fsSL https://awscli.amazonaws.com/v2/install.sh | bash
# Linux ・ macOS（全ユーザーへ導入。sudo が必要）
curl -fsSL https://awscli.amazonaws.com/v2/install.sh | sudo bash -s -- --system
# Windows（PowerShell・現在のユーザーへ導入）
irm https://awscli.amazonaws.com/v2/install.ps1 | iex
# Windows（管理者のPowerShell・全ユーザーへ導入）
irm 'https://awscli.amazonaws.com/v2/install.ps1' -OutFile install.ps1; try { .\install.ps1 -System } finally { Remove-Item install.ps1 }配置先を変えたい場合、LinuxとmacOSはXDG_DATA_HOMEとXDG_BIN_HOMEを事前に設定します。パスに空白が含まれるとインストールが失敗するため、共有サーバーへ入れるときは配置先の命名に注意してください。指定できるオプションの一覧は、スクリプトに--help（Windowsは-Help）を渡すと表示されます。
WindowsとLinuxでのバージョン確認とaws updateでの更新手順
導入後はaws --versionで確認します。出力にはCLI本体のバージョン、埋め込みPythonのバージョン、OS情報が並びます。v2はPythonを内包しているため、システム側にPythonを入れる必要はありません。
$ aws --version
aws-cli/2.27.41 Python/3.11.6 Linux/5.10.205-195.807.amzn2.x86_64
# 更新（全ユーザー導入なら sudo または管理者権限のシェルで実行）
$ aws updateインストールスクリプト・Linuxのコマンドラインインストーラ・macOSのpkg・Windowsのmsiのいずれかでインストールしていればaws updateが使えます。全ユーザー向けか現在のユーザー向けかという導入形態は、更新の前後で変わらず、そのまま引き継がれる仕組みです。最新版の番号はv2のCHANGELOGで確認でき、2026年10月初旬時点では2.37系が先頭に並んでいます。
v1とv2が併存したときのパス衝突とaws –versionでの切り分け
v1とv2は同じawsというコマンド名を使うため、pipで入れたv1が残っていると、v2を入れてもv1が呼ばれ続けます。Amazon Linuxでyum版が同梱されている場合も同じ症状が起きます。
切り分けは2手で済みます。aws --versionの出力がv1系ならv2が呼ばれていません。次にwhich aws（Windowsではwhere aws）で実体の場所を見て、pipのsite-packages配下やyum管理下を指していれば、その旧版を削除してからシェルを開き直します。Amazon Linuxではsudo yum remove awscliで同梱版を外すことが公式手順に書かれています。
OS別にAWS CLIをインストールする方法とバージョン固定・削除の手順
インストールスクリプトだけで済まない場面もあります。CPUアーキテクチャの違い、全ユーザー向けの配布、版の固定、コンテナでの実行、そして削除です。いずれも公式のインストール手順に方式ごとの記述があるので、導入先ごとの選び方を先に表で示します。
| 導入先 | 推奨の入れ方 | 版を固定する方法 | 全ユーザー向けの配置先 |
|---|---|---|---|
| Linux x86_64 | install.sh | zipに版番号を付与 | /usr/local/aws-cli |
| Linux ARM | install.sh | aarch64版zipに版番号 | /usr/local/aws-cli |
| macOS | install.sh | pkgで導入 | /usr/local/aws-cli |
| Windows | install.ps1 | msiで導入 | Program Files配下 |
| CI・コンテナ | 公式イメージ | イメージのタグ | 不要 |
Linuxのx86とARMで分かれるzipインストーラとバージョン指定の書き方
インストールスクリプトはx86_64とARMの両方に対応しますが、構成管理ツールから入れる場合や版を固定したい場合はコマンドラインインストーラ（zip）を使います。zipはアーキテクチャごとにファイル名が分かれており、Graviton系のEC2やARM版のコンテナで選ぶファイルはaarch64版です。版を指定するときはファイル名の末尾にハイフンと版番号を付ける、と過去リリースのインストール手順に書かれています。
# Linux x86_64 に最新版を入れる
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
# Linux ARM に版を固定して入れ直す（2.37.8 は 2026年10月初旬時点の最新版）
curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64-2.37.8.zip" -o "awscliv2.zip"
unzip -u awscliv2.zip
sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --updateすでに入っている環境を上書きするときは--updateを付け、既存のシンボリックリンクと導入先を--bin-dirと--install-dirで指定します。展開時の上書き確認で自動化が止まらないよう、unzip -uを使う点も公式手順どおりです。ダウンロードしたzipはGnuPGで署名を照合でき、手順ページに載っている検証用公開鍵の有効期限は2027年7月1日です（2026年10月時点の記載）。
snapパッケージ（snap install aws-cli --classic）も公式に提供されていますが、自動で更新される代わりにマイナーバージョンを選べません。版を固定したいチームには向かない、と公式手順にも明記されています。
macOSのpkgとWindowsのmsiで全ユーザー向けに入れる手順と確認
社内の共用端末やビルド用のMacへ入れるなら、pkgを使った全ユーザー向けの導入が管理しやすい方式です。sudo installerで入れると/usr/local/aws-cliに配置され、/usr/local/binへシンボリックリンクが作られます。インストールのログは/var/log/install.logに残ります。
# macOS（全ユーザー向け）
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /
which aws
aws --version
# Windows（管理者のコマンドプロンプト・全ユーザー向け・画面を出さずに導入）
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi /qn
aws --versionWindowsのmsiは管理者権限が必要で、/qnを付けると画面を出さずに入ります。資産管理ツールから一斉配布するならmsi、開発者が自分の端末に入れるならinstall.ps1、と分けておくと権限申請の手間が減ります。WSL上のLinuxで使う場合はWindows向けではなくLinux向けの手順で入れ、認証情報もWSL側のホームにある.awsを参照する点に注意してください。WSLの環境構築そのものはWSLで開発環境を構築する手順で扱っています。
Dockerの公式イメージで端末へ入れずにAWS CLIを実行する方法
端末にインストールしたくない場合や、CIのジョブごとに版をそろえたい場合は、公式イメージを使う方法が選択肢です。公式のDocker実行手順は、Docker Hubのamazon/aws-cliよりも、レート制限が緩く複数リージョンに複製されているAmazon ECR Publicのpublic.ecr.aws/aws-cli/aws-cliを推奨しています。コンテナからはホストのファイルが見えないため、認証情報は~/.awsを/root/.awsへマウントして渡します。
# 版の確認（対話用に -it を付ける）
docker run --rm -it -v ~/.aws:/root/.aws public.ecr.aws/aws-cli/aws-cli --version
# スクリプトから呼ぶ場合は -it を外し、作業ディレクトリを /aws にマウントする
docker run --rm -v ~/.aws:/root/.aws -v "$(pwd)":/aws public.ecr.aws/aws-cli/aws-cli s3 ls出力をパイプで渡すときに-itを付けているとエラーの原因になるため、スクリプトでは外します。タグをlatestのままにすると実行のたびに版が変わり得るので、CIでは版番号のタグを指定してください。自前のイメージにCLIを組み込む場合の書き方はDockerfileの書き方と主要命令を参照してください。
インストール後にawsが見つからないときの確認順とアンインストール手順
「command not found」になる原因の多くはPATHです。インストールスクリプトで現在のユーザー向けに入れると$HOME/.local/binにリンクが作られるため、このディレクトリがPATHに含まれていないシェルでは見つかりません。まずターミナルを開き直し、それでも見つからなければwhich aws（Windowsはwhere aws）とPATHの中身を確認します。PATHの設定方法はOSごとに違うので、環境変数のLinux・Windowsでの設定方法で手順を確認してください。
削除は公式のアンインストール手順のとおり、入れたときと同じ方式で行います。zipで入れた場合はシンボリックリンク2つ（awsとaws_completer）と導入先ディレクトリを消し、snapならsnap remove aws-cli、Windowsはコントロールパネルの「プログラムと機能」から削除します。
# zip（コマンドラインインストーラ）で入れた場合の削除例
which aws # 例: /usr/local/bin/aws（--bin-dir の場所）
ls -l /usr/local/bin/aws # リンク先が --install-dir の場所
sudo rm /usr/local/bin/aws /usr/local/bin/aws_completer
sudo rm -rf /usr/local/aws-cli~/.awsフォルダは各言語のAWS SDKとも共有される設定です。CLIを入れ直すだけなら残しておき、SDKを使うツールがほかに残っていないと確かめてから消してください。
認証情報の設定手順とIAM Identity Centerを選ぶ判断基準
インストールの次は認証です。入門記事の多くはIAMユーザーを作ってアクセスキーをaws configureに貼る流れを示しますが、組織で使うなら選ぶべきはIAM Identity Centerです。
aws configureで設定される認証情報ファイルの中身と保存場所
aws configureを実行すると、アクセスキーIDとシークレットアクセスキーが~/.aws/credentialsに、リージョンと出力形式が~/.aws/configに書き込まれます。Windowsでは%USERPROFILE%\.aws\配下です。設定ファイルの仕様には、プロファイル名を付けた複数環境の書き分けや、環境変数との優先順位も定義されています。
この方式は長期の認証情報が平文でディスクに残る仕組みです。個人の検証環境なら許容できますが、業務の共有端末やCIランナーに置く判断は別に考える必要があります。長期キーを置かずに手元の端末だけで認証を済ませるなら、CLI 2.32.0で追加されたaws loginコマンドの実行手順とsso loginとの使い分けも認証方法を選ぶ際の選択肢です。IAMのユーザーとロールの違いはAWS IAMの権限設計で整理しています。
IAM Identity Centerを使うsso-session設定の書き方
IAM Identity Centerを使うと、CLIはブラウザ経由でサインインし、一時的な認証情報をキャッシュして使う仕組みです。ディスクに長期キーを置かずに済みます。設定はaws configure ssoのウィザードで作れますが、生成される中身を知っておくと手で書けます。
[profile dev]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = SampleRole
region = ap-northeast-1
output = json
[sso-session my-sso]
sso_region = ap-northeast-1
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:accessこの形にしておくと、複数プロファイルから同じsso-sessionを再利用でき、トークンの自動更新も効きます。サインインはaws sso login --profile dev、破棄はaws sso logoutです。公式の設定手順によれば、バージョン2.22.0以降はPKCE認可が既定になり、ブラウザのない端末では--use-device-codeを付けてデバイス認可へ切り替えます。
長期アクセスキーを開発者へ配らない運用と権限設計の失敗パターン
失敗が集中するのは、開発者ごとにIAMユーザーを作ってアクセスキーを配る運用です。退職や異動のたびに回収が必要になり、キーの棚卸しが追いつかなくなります。EC2やECS上で動かす処理にアクセスキーを埋めるのも同じ問題を生みます。インスタンスプロファイルやタスクロールを使えばキーは不要です。
GitHub ActionsなどのCIから叩く場合は、OIDCによる一時認証情報の取得に寄せます。ワークフロー側の設定例はGitHub ActionsとTerraformでAWSのCI/CDを構築する手順で、OIDCのロール引き受けまで含めて示しています。判断としては、人が使うCLIはIAM Identity Center、マシンが使うCLIはロール引き受けかOIDC。長期キーを使ってよいのは、この2つがどちらも使えない外部環境からの一時的な接続に限られます。既存環境の初期設計を見直す場合はAWS環境構築の手順で全体像を確認してください。
–queryと–outputで出力を絞るコマンド設計と自動化の注意点
CLIの結果をそのままスクリプトへ渡すと、JSONの階層が深くて扱いにくくなります。v2は出力の整形をコマンド側で完結できるので、jqへ渡す前に絞り込む書き方を覚えると、後続の処理を短くすることが可能です。jq側のフィルタの書き方はjqコマンドの使い方｜JSONの抽出・整形・CSV変換を実行例で覚えるにまとめています。
–queryでJMESPathを使い必要な項目だけを取り出す書き方
--queryはJMESPathという問い合わせ言語で応答を絞ります。EC2の一覧から必要な3項目だけを取り出すなら、次の書き方で1行1インスタンスのタブ区切りが得られます。
aws ec2 describe-instances \
--filters Name=tag:Env,Values=stg Name=instance-state-name,Values=running \
--query "Reservations[].Instances[].[InstanceId,InstanceType,PrivateIpAddress]" \
--output text絞り込みには--filtersと--queryの2系統があり、役割が違います。--filtersはAPI側で絞るため転送量と実行時間が減り、--queryは受け取った応答をクライアント側で整形します。対象を減らす条件は--filtersへ、項目を減らす指定は--queryへ。この使い分けを守ると、対象が数千件ある環境でも実行時間が伸びません。
ページャと終了コードがスクリプト実行で詰まる原因と回避の設定
v2は既定で出力をOSのページャ（LinuxとmacOSはless、Windowsはmore）へ流す仕様です。対話操作では読みやすい一方、cronやCIで実行するとページャの終了待ちで処理が止まったように見えることがあります。回避は環境変数AWS_PAGERを空にするか、aws configure set cli_pager ""で無効にします。
終了コードの扱いも変わりました。v2は全コマンドで返却コードの一貫性が高められ、252・253・254が追加されています。set -eを効かせたシェルスクリプトでは、0以外をすべて異常として扱うと想定外の停止を招くことがあるため、判定したい条件を明示してください。CloudFormationのデプロイで変更がなかった場合、v1は失敗扱いでしたが、v2は0を返します。旧来の--no-fail-on-empty-changesetを前提にした分岐は、そのままでは意図と逆に働きます。
AWS CLI v1のメンテナンスモード移行とサポート終了までの猶予
ここからがv2の解説記事にほとんど載っていない部分です。v1は現時点でまだ動きますが、更新の中身が変わりました。「動いているから問題ない」と判断すると、対応が必要になった時点で猶予が短くなります。
メンテナンスモード入りで止まるAPI更新と新リージョンへの対応
AWS CLIのGitHubリポジトリには、v1が2026年8月5日にメンテナンスモードへ入り、2027年7月15日にサポート終了を迎えると記載されています。メンテナンスモード中のリリースは重大なバグ修正とセキュリティ修正に限定され、新規サービスや既存サービスのAPI更新、新リージョンへの対応は取り込まれません。
実装面の変更も告知済みです。AWS Developer Tools Blogの告知によれば、botocoreとs3transferはv1のコードベースへ同梱される形に変わり、単体パッケージ側の更新はv1へ自動的には反映されなくなります。botocoreを直接参照している社内ツールがある場合、依存の解決結果が従来と変わる可能性があります。なおv1のPython 3.9対応は2026年4月29日に終了しており、現在の対応範囲はPython 3.10以降です。
v1を残しているCI環境の棚卸しとサポート終了までの移行計画
棚卸しの起点は、CIのコンテナイメージとサーバーの構成管理コードです。pip install awscliと書かれた行、Amazon Linuxのyum版に依存した記述、Dockerfileでバージョンを固定している箇所。この3つを検索すれば、v1が残っている場所はおおむね洗い出せます。
移行の期限は2027年7月15日ですが、実務では新リージョンや新サービスの利用が決まった時点が実質的な期限になります。AWS関連ツールのEOLは他にも進行しており、たとえばAWS Copilot CLIは2026年6月12日にサポートが終了しました。移行先の考え方はAWS Copilot CLIサポート終了と移行先3択で整理しています。
v1からv2への破壊的変更で壊れる既存スクリプトの具体的な修正箇所
v1とv2はコマンド名が同じなので、入れ替えただけでは変化に気づきません。公式の移行ガイドには十数項目の破壊的変更が並びますが、既存スクリプトが実際に壊れるのは限られた箇所です。
ecr get-loginの廃止とget-login-passwordへの書き換え
コンテナのビルドパイプラインで最も多く踏むのがこれです。v2ではaws ecr get-loginが削除され、aws ecr get-login-passwordへ置き換わりました。旧コマンドはdocker loginの完全なコマンド文字列を返す仕様で、パスワードがプロセス一覧やシェル履歴に残る問題がありました。
# v1 の書き方（v2 では削除済み）
$(aws ecr get-login --no-include-email)
# v2 での書き方（パスワードを標準入力へ渡す）
aws ecr get-login-password --region ap-northeast-1 \
| docker login --username AWS --password-stdin \
111122223333.dkr.ecr.ap-northeast-1.amazonaws.com置き換え先のget-login-passwordはv1の1.17.10以降でも使えます。移行を段階的に進めるなら、v1のまま先にこの書き換えだけ済ませておくと、v2へ切り替える日の作業が減ります。
タイムスタンプとS3エンドポイントの既定変更で壊れる処理の直し方
残りの変更は、コマンドが成功したまま後続処理だけが壊れるため見つけにくい種類です。主要な4点と対処を並べます。
| 変更点 | v1の挙動 | v2の既定 | 戻し方 |
|---|---|---|---|
| タイムスタンプ | API応答のまま | ISO 8601へ統一 | cli_timestamp_format=wire |
| バイナリ引数 | UTF-8バイト列 | base64文字列 | –cli-binary-format |
| S3のus-east-1 | グローバル向け | リージョン別向け | リージョンに aws-global |
| S3のチェックサム | CRC32（1.37.0以降） | CRC64NVME | –checksum-algorithm |
影響が出やすいのは日付のパースです。v1の出力形式を前提に文字列を切り出している集計スクリプトは、v2に変えた瞬間に値がずれます。またv2はhttp://で始まる引数の中身を取得しなくなったため、ポリシーファイルをURLで渡していた処理は、ファイルへ落としてfile://で渡す形に直します。api_versions設定による旧APIバージョンの指定も廃止されました。
AWS CLIを運用に組み込む条件とIaCに任せるべき領域の線引き
CLIで何でも自動化できてしまうため、本来はIaCで管理すべき構成までシェルスクリプトに溜まっていく現場は珍しくありません。どこで線を引くかを決めておかないと、数年後に読めない運用スクリプトが残ります。
CLIで書くべき運用作業とTerraformに寄せるべき構成管理の境界
境界の判断軸は「その操作の結果を、あとから状態として比較したいか」です。VPC・サブネット・IAMロール・RDSのように、あるべき姿を定義して差分を見たいものはIaCの領域です。TerraformやCloudFormationなら、実物と定義がずれたときに検出できます。既存リソースを後からコード化する手順はterraform importで既存リソースをコード化する方法にまとめています。
一方、スナップショットの取得、ログの抽出、特定インスタンスの再起動、S3への一括アップロードのように、実行した時点で完結して状態を持たない操作はCLIが向きます。「作るのはIaC、触るのはCLI」という役割の違いを覚えておけば、どちらを使うかの判断で迷う場面はほぼなくなるはずです。検証用のデータベースを作って壊すような一時的な環境もCLIの守備範囲で、その実例はAWS CLIでAuroraクラスターを作成・検証・削除する手順にまとめています。CLIでaws ec2 create-vpcを書き始めたら、それはIaCへ移すべき兆候です。
受託開発の現場でAWS CLIの採用を見送る条件と代替の選び方
採用を見送る条件も明示しておきます。ひとつは、操作する人がAWSの権限管理を理解していない体制のまま、運用作業だけをCLIへ移す場合です。CLIは確認ダイアログを挟まないため、削除系コマンドの事故がそのまま本番に届きます。この状態ではコンソール操作と承認フローを残したほうが安全です。
もうひとつは、複数アカウントを跨いで日常的に操作する場合です。プロファイルの取り違えによる誤操作が起きやすく、CLI単体では防げません。IAM Identity Centerでアカウントごとに権限セットを分け、それでも運用が重いならAWSコンソール側の運用に戻す判断が現実的です。設計段階から権限とデプロイ経路を含めて整えたい場合は、AWS・Google Cloud・Azureのインフラ構築で構成の設計から運用体制の設計までを請けています。既存環境の棚卸しからでも着手できます。
よくある質問
AWS CLIのインストールと運用でよく寄せられる質問をまとめます。
AWS CLI v1とv2はどちらをインストールすべきですか？
新規に入れるならv2です。v1は2026年8月5日にメンテナンスモードへ移行し、2027年7月15日にサポートが終了します。メンテナンスモード中は新サービスや新リージョンへの対応が入らないため、これから構築する環境ではv1を選ぶ理由がありません。v1が動いている既存環境についても、サポート終了までに移行計画を立てておくことが必要です。v2はPythonを内包しているので、システム側のPythonバージョンを気にせず導入できます。導入したCLIでサービスの一覧やリージョン提供状況を引く手順はAWSのサービスをCLIで数え、利用状況を確認する手順にまとめています。
aws configureで設定した認証情報はどこに保存されますか？
アクセスキーIDとシークレットアクセスキーはホームディレクトリ配下の.aws/credentialsに、リージョンと出力形式は同じ階層の.aws/configに保存されます。Windowsではユーザープロファイル配下の同名フォルダです。いずれも平文で保存されるため、共有端末やCIランナーへ長期キーを置く運用は避け、IAM Identity Centerによる一時認証情報かロールの引き受けへ切り替えてください。
AWS CLIとAWS SDKやTerraformはどう使い分けますか？
アプリケーションのコードからAWSを呼ぶならSDK、構成を定義して差分管理するならTerraformやCloudFormation、その場限りの運用作業と調査ならCLIという分担になります。CLIでインフラを作り込むと、作成順序や設定値がスクリプトの中にしか残らず、再現とレビューが難しくなります。作るのはIaC、触るのはCLIという線引きが実務では扱いやすい基準です。
AWS CLIのバージョンを固定して運用したい場合はどうしますか？
Linuxではコマンドラインインストーラのzipを使い、ファイル名の末尾に版番号を付けて取得すると、インストールするバージョンを指定できます。snapパッケージは自動更新される仕様で、マイナーバージョンの選択に対応していないため、固定したいチームには向きません。CI環境では、公式のDockerイメージを版番号のタグで指定するか、自前のコンテナイメージ側でバージョンを明示し、更新のタイミングを検証と合わせて管理する方法が扱いやすくなります。
CI上でAWS CLIの実行が止まったように見えるのはなぜですか？
v2は既定で出力をOSのページャへ流すため、対話端末のない環境では処理が停止したように見えることがあります。環境変数AWS_PAGERを空文字にするか、aws configure set cli_pager ""で無効化すると解消します。あわせて、v1では失敗扱いだったCloudFormationの空変更セットがv2では成功扱いに変わっている点も、CIの分岐条件を見直す対象です。
関連記事
- CLIとは？コマンドライン操作の仕組みとGUIとの使い分けを実装視点で解説：コマンドライン操作そのものの前提を確認したい場合に読む記事です。
- AWS IAMとは？権限設計のベストプラクティスを実装者目線で解説：CLIの認証情報を配る前に、ユーザーとロールの設計を整理できます。
- AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計：CLIで触る前段の、環境そのものの初期設計を扱っています。
- terraform importで既存リソースをコード化する手順：CLIで作ってしまった構成をIaCへ移す手順を具体的に解説しています。
- AWS Copilot CLIサポート終了｜2026年6月12日EOLと移行先3択：AWS関連ツールのEOL対応をまとめて棚卸しするときの参考になります。
- AWS S3の使い方｜CLIでのバケット作成から権限設計・署名付きURLまでの実装手順：S3を対象にしたCLI操作の具体例と設定値を確かめたい場合に
- aws s3 cpの使い方｜再帰コピー・フィルタ・ストリーム転送と終了コードの実装手順：aws s3 cpの引数と終了コードをスクリプトに組み込むときの確認用に
- aws loginコマンドの実行手順とsso login・アクセスキーとの使い分け：インストール後の認証を長期キーなしで始めたい場合に読む記事です。
- aws sts get-caller-identityの使い方｜アカウントID取得・認証元の判別とエラー別の直し方：設定後に、どのアカウントへ誰として接続しているかを確かめる手順です。
