AWS CLI v1が2026年7月にメンテナンスモード入り｜v1残存確認とv2移行手順

リナックスマスター.JPの宮崎智広です。
いつもありがとうございます。

「サーバーに入っているaws-cliが、いつの間にか古いv1のままだった」
「AWS CLI v1がメンテナンスモードに入ると聞いたが、自分の運用に何が起きるのか」

2026年に入って、AWSから「AWS CLI v1をメンテナンスモードに移行する」という告知が出ました。長くLinuxサーバーを運用していると、デプロイスクリプトやcronのバックアップ処理の中に、何年も前に入れたaws-cli v1がそのまま生き残っていることがよくあります。私自身、20年以上現場でLinuxサーバーを触ってきましたが、こうした「気づかないうちに取り残されるツール」こそ、後で静かに事故を起こす原因になります。

この記事では、AWS CLI v1のメンテナンスモード移行の事実を一次情報で確認したうえで、サーバー上にv1が残っていないかをどう検出し、v2へどう安全に移行するかを、現役のLinuxサーバー管理者向けに実務手順として整理します。

AWS CLI v1メンテナンスモード移行の事実を一次情報で確認する

まず、噂や又聞きではなく、AWS公式の一次情報で事実を押さえます。

AWS Developer Tools Blogの告知によると、AWS CLI v1は2026年7月15日（July 15, 2026）にメンテナンスモードに入ります。公式原文では「When version 1 of the AWS Command Line Interface (AWS CLI v1) enters maintenance mode on July 15, 2026」と明記されています。

そして、メンテナンスモード期間が終わる2027年7月15日（July 15, 2027）にサポート終了（end-of-support）を迎えます。つまりスケジュールは次のとおりです。

・～2026年7月14日：通常サポート（新サービス対応・新リージョン対応あり）
・2026年7月15日～2027年7月14日：メンテナンスモード（クリティカルなバグ修正・セキュリティ修正のみ）
・2027年7月15日～：サポート終了。新たな更新・リリースなし（過去のリリースはパッケージマネージャ経由で入手は継続可能）

メンテナンスモード中の重要な変更として、AWSはbotocoreとs3transferをv1のコードベースに同梱（vendored）すると告知しています。これにより、standalone（単体）でインストールしたbotocoreやs3transferをアップグレードしても、v1が内部で使うバージョンには影響しなくなります。Pythonで他のアプリと依存ライブラリを共有している環境では、ここを意識しておかないと「ライブラリを上げたのにv1の挙動が変わらない」という混乱が起きます。

そしてAWSの公式な推奨は明確で、「最新のAWSサービスと機能を使い続けるためにv2への移行を推奨する」としています。日付・バージョンはいずれもAWS公式ブログおよび公式ドキュメントで確認した一次情報です。

メンテナンスモードとは何か（EOLとの違い）

ここで多くの方が混乱するのが、「メンテナンスモード」と「EOL（サポート終了）」の違いです。この2つを同じものだと誤解すると、不要な慌て方をしたり、逆に油断しすぎたりします。

・メンテナンスモード（2026年7月15日～）：ソフトウェアは生きています。クリティカルなバグ修正とセキュリティ修正は続きます。ただし、新規・既存サービスのAPI更新は行われず、新しいリージョンにも対応しません。つまり「動くが、もう進化しない」状態です。
・EOL／サポート終了（2027年7月15日～）：更新もリリースも完全に停止します。新たなセキュリティ修正も提供されません。既存のリリース成果物はパッケージマネージャやGitHub上に残りますが、AWSとしては手を入れません。

Linux管理者の感覚で言えば、メンテナンスモードはディストリビューションの「保守限定サポート期間」、EOLは「完全なサポート切れ」に近いものです。CentOS 7のときの「メンテナンス更新は続くが新機能は来ない」期間と、その後の「完全EOL」の関係を思い出すと理解しやすいでしょう。

実務上のポイントは2つです。

1つ目は、2026年7月15日を過ぎても、既存のv1スクリプトが即座に止まるわけではないということ。AWSも「v1向けに作られたスクリプトやワークフローはこの期間も引き続き動作する（AWSサービス側が根本的な変更をしない限り）」と説明しています。慌てて一晩で移行する必要はありません。

2つ目は、とはいえ放置すれば確実に取り残されるということ。新サービスや新リージョンのコマンドはv1では使えなくなっていきます。新機能を使おうとして「v1では未対応」に突き当たる場面が、移行のきっかけになるケースが多いです。計画的に、サポート終了の2027年7月より十分手前で移行を済ませておくのが王道です。

サーバー上にv1が残っていないかを検出する手順

移行の第一歩は「どのサーバーにv1が残っているか」を正確に把握することです。長く運用しているサーバー群では、導入経路（pip・OSパッケージ・公式bundle）がバラバラなことが多く、思わぬところに古いv1が潜んでいます。次の手順で確実に洗い出します。

1. バージョンを確認する

最も基本的なのがaws --versionです。

$ aws --version
aws-cli/1.27.155 Python/3.9.16 Linux/5.15.0-x86_64

出力がaws-cli/1.x.xで始まっていればv1です。v2なら次のようにaws-cli/2.x.xになります。

$ aws --version
aws-cli/2.27.41 Python/3.11.6 Linux/5.10.205-x86_64

v2はPythonインタプリタを同梱しているため、aws --versionの出力に出るPythonバージョンも、システムのPythonとは独立した同梱版になります。

2. 実体のパスを確認する

どのawsコマンドが呼ばれているかをwhichとシンボリックリンクの追跡で確認します。

$ which aws
/usr/local/bin/aws
$ ls -l /usr/local/bin/aws
lrwxrwxrwx 1 root root 49 ... /usr/local/bin/aws -> /usr/local/aws-cli/v2/current/bin/aws

リンク先が/usr/local/aws-cli/v2/...を指していればv2の公式bundle導入です。一方、/usr/bin/awsがOSパッケージや/usr/local/binのpip導入を指している場合は、v1が混在している可能性が高いです。

3. pip導入のv1を検出する

最も見落としやすいのが、pipで入れたv1です。aws --versionでv2が出ても、別のPython環境にpip版v1が残っていることがあります。

$ pip list 2>/dev/null | grep -i awscli
awscli                    1.27.155
$ pip3 show awscli

pip listにawscliが出てきたら、それはpip導入のv1です（v2はpipでは配布されていません）。virtualenvやpyenv配下、システムpython、ユーザーローカル（~/.local）など、複数のPython環境がある場合はそれぞれで確認してください。

4. 複数台を一括で棚卸しする

管理対象サーバーが複数あるなら、Ansibleやシェルのforループ＋sshで一括確認すると漏れがありません。

for h in web01 web02 batch01; do
  echo "=== $h ==="
  ssh "$h" 'aws --version 2>&1; which aws; pip list 2>/dev/null | grep -i awscli'
done

この棚卸しで「どのサーバーに、どの経路で、どのバージョンが入っているか」を一覧化してから移行に着手するのが、事故を防ぐ近道です。

v2への移行手順と破壊的変更の注意

残存しているv1を把握したら、いよいよv2へ移行します。AWS公式の推奨は「v1をアンインストールしてからv2を導入する」シンプルな方法です。

移行の基本手順（公式推奨）

1. まず後述する破壊的変更を確認し、既存スクリプトに影響がないか洗い出す
2. v1をアンインストールする（pip導入ならpip uninstall awscli、OSパッケージなら該当パッケージを削除）
3. aws --versionでバージョンが出力されなくなることを確認する（出力が残るならv1がどこかに残存している）
4. v2を公式zipから導入する

Linuxへのv2インストール（x86_64・公式手順）

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip
$ sudo ./aws/install

ARM（aarch64）サーバーの場合はファイル名をawscli-exe-linux-aarch64.zipに変えます。デフォルトでは/usr/local/aws-cliにインストールされ、/usr/local/binにシンボリックリンクが作られます。

すでにv2が入っていて更新する場合は--updateを付けます。

$ sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update

どうしてもv1とv2を併存させたい移行期間中は、OSのシンボリックリンクやエイリアス機能で片方を別名（例：aws2）にして共存させることも公式に認められています。

スクリプトを壊す主な破壊的変更

v2は同じawsコマンドですが、v1との間にスクリプトを壊しうる破壊的変更があります。AWS公式ドキュメントから、特にLinuxの自動処理で問題になりやすいものを挙げます。

・出力がデフォルトでpager（less）経由になる：v2は出力をOSのページャ（Linuxではless）に通します。cronやパイプ処理ではこれで詰まることがあります。AWS_PAGER=""環境変数か、コマンドに--no-cli-pagerを付けて無効化します。
・タイムスタンプ出力がISO 8601形式に標準化：v1はサービスごとにバラバラな形式でしたが、v2は統一されます。出力をパースしているスクリプトは要注意。旧挙動に戻すには設定ファイルでcli_timestamp_format=wire。
・バイナリパラメータがデフォルトでbase64エンコード文字列：v1挙動に戻すには--cli-binary-format raw-in-base64-outを指定します。
・http://・https:// で始まるパラメータの自動取得を廃止：v1のcli_follow_urlparamは削除されました。URLの中身を渡したい場合は、curlでローカルに落としてからfile://で参照します。
・aws ecr get-login が廃止：aws ecr get-login-passwordに置き換わりました。Dockerログインを自動化しているスクリプトは書き換えが必要です。
・us-east-1のS3が真のリージョナルエンドポイントに：v1はグローバルなs3.amazonaws.comを使っていましたが、v2はs3.us-east-1.amazonaws.comを使います。
・S3署名はSigV4のみ、api_versions設定は非対応（常に最新API）など、細かい挙動差も多数あります。

特に「pager」「タイムスタンプ」「ecr get-login」の3つは、既存の運用スクリプトを静かに壊しやすい代表格です。移行時は本番に当てる前に、検証環境で主要なスクリプトを一通り流して確認してください。

Linuxサーバー管理者が今やるべきこと

最後に、現役のLinuxサーバー管理者としての教訓を整理します。

AWS CLI v1のメンテナンスモード移行で一番怖いのは、「即座に止まらない」がゆえに後回しにされ、棚卸しされないまま放置されることです。サーバー運用では、こうした「動いているから触らないツール」が一番事故を起こします。

今やるべきことは次の3つに集約されます。

1. 棚卸し：管理対象の全サーバーでaws --version・which aws・pip listを回し、v1がどこに、どの経路で残っているかを一覧化する。pip導入のv1が一番見落とされやすい。
2. 影響調査：v1を呼んでいるスクリプト（デプロイ・バックアップ・監視・cron）を洗い出し、pager・タイムスタンプ・ecr get-loginなどの破壊的変更に当たる箇所を特定する。
3. 計画的移行：サポート終了の2027年7月より十分手前で、検証環境で動作確認したうえでv2へ切り替える。慌てて一晩でやるより、影響を見極めてから着実に進めるほうが安全。

こうした「公式の一次情報を確認し、自分のサーバーの実態を棚卸しし、破壊的変更を踏まえて計画的に移行する」という一連の動きは、AWS CLIに限らず、ミドルウェアやディストリビューションのEOL対応すべてに共通する基本動作です。日頃からこの型を身につけておくと、どんなバージョン移行にも落ち着いて対応できるようになります。

---

• 次のページへ：Homebrew 6.0.0公開｜サードパーティtap信頼確認でセキュリティ強化、Linuxユーザーの対応
• 前のページへ：Steam DeckはなぜLinuxで成功したか｜SteamOS・Proton・ValveのLinux投資を技術解説
• この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る