先に要点
- AWS CLIは AWSをコマンドで操作・自動化する公式ツール。マネジメントコンソール(GUI)でできることの大半を、再現可能でスクリプト化できる形で実行できます。
- いま最重要の時事: AWS CLI v1は2026年7月15日に保守モード入り(2027年7月15日にサポート終了)。以後v1は重大なバグ修正とセキュリティ対応のみで、新サービス・新APIは入りません。新規も既存もv2を使うのが前提です。
- v2は Pythonを同梱した単体アプリ。pipではなく公式インストーラ(macOSはpkg/Homebrew、Linuxはzip+installスクリプト、WindowsはMSI)で入れます。
- 認証は 長期アクセスキーを避け、期限付きの認証を選ぶのが定石。IAM Identity Center(SSO)の
aws configure ssoや、2025年11月に追加されたaws login(v2.32.0以降のブラウザ認証)が推奨です。 - つまずきやすいのは リージョン・プロファイル・出力形式。
--profile/AWS_PROFILE/--query/--outputを押さえると一気に扱いやすくなります。
aws s3 ls って打つやつでしょ？ ── AWS CLIは名前のとおりコマンドでAWSを触る道具ですが、「最初に何を入れて、どう認証して、どこでつまずくか」を整理しておかないと、リージョン違いや権限エラーで手が止まりがちです。
この記事では、AWS CLIを 何ができるか → v1/v2とサポート終了の時事 → インストール → 認証 → プロファイルとリージョン → 実務で効く使い方 → よくある失敗の順で、実際の運用目線で整理します。画面手順は変わりやすいので、「どの仕組みで・何を・どう安全に」動かすかを主役にします。
AWS CLIとは何か(コンソールとの違い)
AWS CLIは、ターミナルから aws コマンドでAWSのAPIを叩く公式のコマンドラインツールです。EC2の起動、S3へのアップロード、IAMユーザーの作成、CloudFormationのデプロイなど、AWSのサービスで提供されているAPIの大半を、コマンド一行〜スクリプトで実行できます。
GUIのマネジメントコンソールと比べたときの価値は、「再現性」と「自動化」に尽きます。コンソールでの作業は「画面を見ながら手で押す」ため、同じ手順を何度もやると揺れますし、記録も残りません。CLIなら同じコマンドが同じ結果を返し、シェルスクリプトやCI/CDに組み込めます。
コンソール(GUI)が向く場面
初めて触るサービスの全体像の把握、ダッシュボードでの状況確認、たまにしかやらない設定。視覚的に分かりやすい。
最初は「コンソールで覚えて、繰り返す作業からCLIに移す」のが自然です。AWSの基本用語に不安があればEC2・IAM・S3・VPCの全体像も合わせて読むと、コマンドの対象が頭に入りやすくなります。
【時事】AWS CLI v1は2026年7月15日に保守モード ── 今ならv2一択
AWS CLIには v1とv2があり、入れるなら v2です。理由は機能差だけではありません。AWSはv1を2026年7月15日に保守モード(maintenance mode)へ移行し、2027年7月15日にサポート終了(end-of-support)とすると公式に発表しています(出典は後述の参考リンク)。
保守モードの間、AWS公式は「リリースを重大なバグ修正とセキュリティ問題への対応のみに限定する」としています。新サービス・既存サービスのAPI変更・新リージョンへの追従はv1には入りません。つまりv1のまま使い続けると、新しい機能やリージョンが使えず、いずれ動かなくなる箇所が出ます。
| 項目 | AWS CLI v1 | AWS CLI v2(推奨) |
|---|---|---|
| サポート状況 | 2026年7月15日に保守モード / 2027年7月15日にサポート終了 | 継続サポート。新機能はv2に入る |
| Python | システムのPythonに依存(pipで導入) | Pythonを同梱。システムのPythonに非依存 |
| インストール | pip install awscli | OS別の公式インストーラ(pkg/MSI/zip) |
| SSO認証 | 限定的 | aws configure sso / sso-session / aws login に対応 |
| 補助機能 | 少ない | 自動補完、auto-prompt、ウィザード、yaml出力など |
自分がどちらを使っているかは aws --version で分かります。先頭が aws-cli/1.x ならv1、aws-cli/2.x ならv2です。v1を使っているなら、移行を前提に計画します。AWSは v1のアップグレード用デバッグモード(v1.44.0以降)や v1からv2へのマイグレーションツール(スクリプトの差分を検出して直す)を提供しているので、いきなり全置換せず、まず差分を洗い出すと安全です。v2はおおむねv1と後方互換ですが、一部の出力やページャの挙動が変わる点に注意します。
インストール:v2はpipで入れない
ここが最初の落とし穴です。AWS CLI v2はpipやPythonの仮想環境には入れません。v2はPythonを同梱した独立したアプリケーションとして配布され、OSごとの公式インストーラで入れます。古い記事を見て pip install awscli とやると、入るのはv1なので注意します。
インストール後は必ず aws --version で aws-cli/2.x を確認します。すでにv1が入っている環境では、PATHの優先順位で古い方が呼ばれることがあるので、バージョン表示で実際にどちらが動いているかを確かめてから設定に進みます。アップデートも同じインストーラを上書き実行するだけで、Homebrewなら brew upgrade awscli です。
認証の設定 ── 長期アクセスキーより「期限付き」を選ぶ
CLIを入れたら、次は「誰として・どの権限でAWSを叩くか」の設定です。ここでのセキュリティ判断が一番重要です。選択肢は大きく3つあり、個人の長期アクセスキーは極力避け、期限付きの認証(SSOやブラウザ認証)を使うのが現在の定石です。
アクセスキー方式(aws configure)の注意
aws configure を実行すると、アクセスキーID・シークレットアクセスキー・既定リージョン・既定出力形式を聞かれ、/.aws/credentials/.aws/config に保存されます。手軽ですが、このキーは自分で無効化するまで失効しません。誤ってGitにコミットしたりログに出したりすると、第三者に長期間悪用されます。使う場合も 権限は最小限(IAMで必要なアクションだけ)にし、不要になったら消します。ルートユーザーのアクセスキーは作らないのが鉄則です。権限設計の考え方はIAMのロール・ポリシー・権限境界の違いで整理しています。
SSO方式(aws configure sso)が現在の本番標準
組織でAWSを使うなら、IAM Identity Center(旧AWS SSO)での認証が標準です。aws configure sso を実行するとSSOのスタートURL・リージョン・登録スコープを聞かれ、ブラウザが開いて認証します。設定は ~/.aws/config に書かれ、以後は aws sso login でログインするだけで 期限付きの一時認証情報が得られます。v2.22.0以降はPKCEベースの認可がデフォルトで、sso-sessionブロックを使うとトークンの自動更新と複数アカウントの横断利用ができます。長期キーを手元に置かずに済むのが最大の利点です。
aws login(ブラウザ認証)で素早く始める
2025年11月19日のv2.32.0で追加された aws login は、マネジメントコンソールと同じサインイン方法でCLIを使い始められる新しいコマンドです。長期アクセスキーを作らずブラウザ認証だけで認証でき、サインアップ直後から手早く触れます。個人や学習でアクセスキーの管理を避けたいときに向きます。
プロファイルとリージョンの使い分け
実務でほぼ必ず必要になるのが プロファイル(複数アカウント・環境の切り替え)と リージョンの管理です。設定は2つのファイルに分かれて保存されます。
~/.aws/credentials── アクセスキーなどの認証情報。~/.aws/config── 既定リージョン・出力形式・SSO設定・名前付きプロファイル。
複数の環境(本番/検証、会社/個人)を切り替えるには 名前付きプロファイルを使います。aws configure --profile staging のように作り、コマンド側で aws s3 ls --profile staging と指定するか、環境変数 AWS_PROFILE=staging をセットします。リージョンは --region ap-northeast-1 で都度上書きできます。
| 指定方法 | 例 | 使いどころ |
|---|---|---|
| コマンド引数 | --profile prod --region us-east-1 | その1コマンドだけ明示的に切り替える |
| 環境変数 | AWS_PROFILE / AWS_REGION / AWS_DEFAULT_REGION | そのシェルセッション全体で固定する |
| 設定ファイル | ~/.aws/config の [profile prod] | 恒久的な既定値として保存する |
優先順位は コマンド引数 → 環境変数 → 設定ファイルの順で効きます。「本番のつもりが検証を、検証のつもりが本番を叩いていた」という事故はこの取り違えで起きます。破壊的な操作の前は aws sts get-caller-identity で「いま自分が誰として・どのアカウントにいるか」を確認する癖をつけると安全です。
実務で効く使い方
CLIは素のままでも使えますが、いくつかのオプションを知っているだけで効率が大きく変わります。
出力形式 --output
json(既定) / text / table / yaml / yaml-stream から選ぶ。人が読むなら table、grepするなら text が扱いやすい。
絞り込み --query
JMESPathで結果を絞れる。例: aws ec2 describe-instances --query "Reservations[].Instances[].InstanceId"。jqを挟まずに必要な値だけ取れる。
s3 と s3api
aws s3 は cp/sync など高水準で日常向け。aws s3api は低水準でAPIを細かく叩く。用途で使い分ける。
auto-prompt / ウィザード
aws --cli-auto-prompt で入力を補助。サービスによっては対話ウィザードもある。コマンドを覚えきっていなくても組み立てられる。
--dry-run
EC2など対応操作では実行前に権限と可否だけ確認できる。破壊的操作の前の安全確認に使う。
--no-cli-pager
v2は出力をページャ(less)に流す。スクリプトやログで止まると困るときは --no-cli-pager か環境変数で無効化する。
たとえば「停止中のEC2インスタンスのIDだけを一覧したい」なら、aws ec2 describe-instances --filters "Name=instance-state-name,Values=stopped" --query "Reservations[].Instances[].InstanceId" --output text のように、フィルタ(サーバー側)とquery(クライアント側)を組み合わせます。これをシェルのループに渡せば一括操作になり、コンソールでは面倒な作業が数行で済みます。
よくある失敗とハマりどころ
リージョン未設定でエラー
既定リージョンが無いと You must specify a region で止まる。aws configure で既定を入れるか --region を付ける。
プロファイルの取り違え
本番と検証を混同して操作。実行前に aws sts get-caller-identity でアカウントを確認する。
出力がページャで止まる
v2はlessに出力を流すため自動処理で固まる。--no-cli-pager や AWS_PAGER="" で無効化する。
AWS CLIに関するよくある質問
AWS CLIとAWS SDKの違いは何ですか？
AWS CLIは 人やシェルがコマンドで叩くためのツール、SDK(boto3など)は アプリのコードからAWSを呼ぶためのライブラリです。中身はどちらも同じAWSのAPIを呼んでいます。手作業の自動化やCI/CDのスクリプトならCLI、アプリケーションの機能として組み込むならSDK、と棲み分けます。
v1とv2、どちらを入れるべきですか？
v2一択です。v1は2026年7月15日に保守モードへ入り、2027年7月15日にサポート終了予定で、以後は新サービス・新APIに追従しません。新規導入はv2、既存のv1環境も移行を計画します。
アクセスキーは使ってはいけないのですか？
禁止ではありませんが、長期アクセスキーは漏洩リスクが大きいため極力避けます。チームや本番ではIAM Identity Center(SSO)、個人や学習では aws login のブラウザ認証など、期限付きの認証を優先します。どうしても長期キーを使う場合は最小権限にし、不要になり次第無効化します。
aws login と aws sso login の違いは何ですか？
aws sso login は、事前に aws configure sso で設定したプロファイルに対してSSOトークンを取得・キャッシュするコマンドです。一方 aws login(v2.32.0以降)は、事前設定を最小限にして、コンソールと同じサインインで素早く認証を始められる新しいコマンドです。組織の既存SSO運用に乗るなら前者、まず手早く触りたいなら後者が向きます。
複数のAWSアカウントを切り替えるには？
名前付きプロファイルを使います。~/.aws/config に環境ごとのプロファイルを定義し、--profile 名前 か環境変数 AWS_PROFILE で切り替えます。SSOの sso-sessionを使うと、一度のログインで複数アカウントを横断利用できます。
AWS CloudShellとの違いは？
AWS CloudShellは ブラウザ上で動く、AWS CLIが最初から入った一時的なシェル環境です。手元にインストールせずすぐ試せて認証も自動ですが、手元のスクリプトやツールチェーンとは切り離されています。日常的に自動化へ組み込むなら手元へのインストール、ちょっと試すだけならCloudShell、と使い分けます。
インストール済みかとバージョンの確認方法は？
aws --version を実行します。aws-cli/2.x.x Python/3.x ... のように表示され、先頭の番号でv1かv2かが分かります。コマンドが見つからない場合は未インストールか、PATHが通っていません。
まとめ
AWS CLIは、AWSの操作を 再現可能でスクリプト化できる形に変える基本ツールです。導入で押さえるべき要点は3つに集約できます。(1) v1は2026年7月15日に保守モード入りのためv2を使う、(2) v2はpipではなく公式インストーラで入れる、(3) 認証は長期アクセスキーを避けてSSOやaws loginの期限付き認証にする。あとはプロファイルとリージョンの取り違えに気をつけ、--query と --output で出力を整えれば、コンソールでは面倒な作業が一気に速くなります。