AWS Copilot CLIサポート終了｜2026年6月12日EOLと移行先3択

AWS Copilot CLIは、2026年6月12日にサポート終了（end-of-support）を迎えました。AWSは2026年3月6日のContainersブログでこれを告知し、GitHubリポジトリ aws/copilot-cli は現在アーカイブ済みです。名前が似ているGitHub CopilotやMicrosoft 365 Copilotとは別物で、こちらはコンテナアプリをAmazon ECSやAWS App Runnerへ配信するためのCLIです。この記事では、終了によって何が止まり何が残るのか、そして既存アプリをどこへ移すべきかを、公式発表とAWS CLIリファレンスの記述に沿って整理します。

まとめ：AWS Copilot CLI終了で押さえる5点

• 終了日は2026年6月12日。以降、AWSからの新機能・セキュリティパッチ・テクニカルサポートは提供されません。
• ツール自体は消えません。Apache-2.0のオープンソースとしてGitHubに残り、リリース資産も引き続きダウンロードできます。ただしリポジトリはアーカイブ（読み取り専用）です。
• 最終リリースはv1.34.1（2025年4月10日）。終了告知の1年近く前から更新が止まっていました。
• AWSが示す移行先は3つ。Amazon ECS Express Mode、AWS CDK、そして生成済みCloudFormationスタックの引き継ぎです。
• App Runner側も同時に縮小中。Request-Driven Web Serviceを使っていた場合は、土台のApp Runnerが2026年4月30日に新規受付を停止しているため、移行の優先度が上がります。

以下、終了の事実関係、移行先3択の判断基準、Express ModeとCDKそれぞれの具体的な移行手順の順に見ていきます。

AWS Copilot CLIの位置づけと提供していた6つのサービスパターン

コンテナ配信の設計判断を肩代わりしていたAWS公式CLI

AWS Copilot CLIは、Dockerfileを1つ渡すだけでECS on FargateやApp Runner上に本番相当の構成を立ち上げるコマンドラインツールでした。VPC、サブネット、セキュリティグループ、ECSクラスター、ロードバランサーまでを、manifest.ymlという専用の宣言ファイルから自動生成します。個別のAWSリソースをモデリングする代わりに、よくあるクラウドアーキテクチャをパターンとして提供する設計です。

AWSの終了告知は、提供していたサービスパターンを6種類として列挙しています。インターネット公開向けの Load Balanced Web Service、App Runner上で動く Request-Driven Web Service、VPC内部専用の Backend Service、Amazon SQSのキュー長で増減する Worker Service、cron式で動く Scheduled Job、CloudFrontとS3による Static Site です。公式ドキュメント上の分類ではこのうち Scheduled Job だけがサービスではなくジョブ側に置かれており、サービス5種＋ジョブ1種という数え方になります。これとは別に、CodePipelineベースのリリースパイプラインも作れました。

AWS自身が終了告知の中で、Copilotの限界を4点挙げています。インフラの可視性が低いこと、専用のマニフェスト構文を覚える必要があること、組み込みパターンを超える調整には結局CloudFormationの追記が必要だったこと、トラブルシューティングにCopilotの抽象と実リソースの両方の理解を要したことです。移行先はこの4点が解消されるかどうかで選ぶと判断しやすくなります。

GitHub Copilot・Microsoft 365 Copilotとの違い

厄介なのは、コマンド名まで同じ点です。GitHub CLIの拡張として入る copilot と、AWSが配布していた copilot は、名前が一致するだけの完全に別のバイナリです。インストール手順を検索して出てきたページが、配布元を aws/copilot-cli としているか、それとも github/gh-copilot などを指しているかで判別できます。AWS Copilot CLI側にコード補完やチャットの機能はなく、生成AIも使っていません。

サポート終了の事実関係：2026年6月12日以降に止まるもの・残るもの

公式発表の日付と終了後のサポート範囲

AWSは2026年3月6日、Containersブログの記事「Announcing the end-of-support for the AWS Copilot CLI」で終了を告知しました。終了日は2026年6月12日です。この日以降、AWS Copilot CLIは新機能の追加、セキュリティ更新、AWSによるテクニカルサポートのいずれも受けられません。

一方で、ツールが動かなくなるわけではありません。AWSが明記しているのは「オープンソースプロジェクトとしてGitHub上で引き続き利用可能」という点までです。稼働中アプリケーションへの影響については、告知記事はCopilotに依存せずデプロイと管理を続ける選択肢を示すという書き方をしています。ここから実務上導ける結論は明快で、Copilotが作ったのは標準的なCloudFormationスタックである以上、デプロイ済みのアプリケーションはCopilotの終了とは独立に動き続けます。止まるのは供給側のメンテナンスであって、稼働中のインフラではありません。

最終リリースv1.34.1とアーカイブ済みリポジトリの現状

GitHub APIで確認すると、aws/copilot-cli リポジトリは archived が true、ライセンスは Apache-2.0、最新リリースは v1.34.1（2025年4月10日公開）です。その前のv1.34.0は2024年6月26日でした。告知の11か月前が最後の更新ということになり、終了の時点で実質的な開発はすでに止まっていた形です。

アーカイブ後もリリース資産の配布は続いています。2026年8月10日時点で、v1.34.1のLinux・macOS・Windows向けバイナリはいずれもGitHub Releasesから取得可能な状態です。公式ドキュメントサイト aws.github.io/copilot-cli も稼働しており、冒頭にEOLバナーが表示されます。つまり「入手できるが、脆弱性が見つかっても誰も直さない」状態です。本番のCI環境に固定バージョンで残し続ける判断は、この前提で行ってください。

App Runner縮小と重なるRequest-Driven Web Serviceへの影響

Copilotの Request-Driven Web Service は、実体としてAWS App Runnerのサービスを作るパターンでした。そのApp Runner自体が縮小フェーズに入りました。AWS公式のApp Runner製品ページには End of support notice が掲出され、2026年4月30日以降は新規顧客の受け入れを停止すること、既存サービスは引き続き稼働すること、セキュリティと可用性への投資は続けるが新機能の追加予定はないことが明記されています。代替としてAWSが名指ししているのは、Amazon ECS Express Modeです。

Request-Driven Web Serviceを使っていた場合、配信ツール（Copilot）と実行基盤（App Runner）の両方が同時にメンテナンス縮小に入ったことになります。他のパターンより移行の優先度を上げるべきなのはここです。App Runner側の終了スケジュールと判断材料はAWS App Runnerは終了する？2026年の新規受付停止・メンテナンスモード移行と移行先を解説で詳しく扱っています。

移行先3択の判断基準：Express Mode・CDK・CloudFormation引き継ぎ

3つの選択肢と向いている条件

いずれも移行先そのものに追加料金はかからず、課金対象はFargateやALBといった下層リソースだけです。コンテナから本番までの最短距離を求めるならExpress Mode、プログラミング言語で型安全にインフラを書きたい・既存のCDKスタックと統合したいならCDK、いま手を動かす余裕がないなら生成済みスタックの引き継ぎ、という対応になります。

Copilotを当面使い続けてよい条件

全員がいますぐ移行すべきかというと、そうではありません。CIから実行するCopilotのバージョンをv1.34.1に固定していて、かつ新しいサービスをCopilotで追加する予定がないなら、当面運用を続ける判断は合理的です。動いているスタックを移行のためだけに触るほうがリスクは高くなります。

先送りすべきでないのは、Request-Driven Web Serviceを使っている場合です。前述のとおり配信ツールと実行基盤の両方が同時に縮小しており、片方だけ延命しても状況は改善しません。これに次いで判断が分かれるのがコンプライアンス要件で、ツールチェーンのセキュリティ更新が求められる組織では、パッチが出ない前提のツールをビルドパイプラインに置き続けること自体が監査上の指摘対象になります。

後回しにしたときに実際に効いてくるコスト

移行を後回しにする判断の本当のコストは、Copilotが止まることではありません。組織からCopilotのマニフェスト構文を読める人がいなくなることです。manifest.ymlは学習資料もコミュニティの回答も更新が止まるため、時間が経つほど「動いているが誰も触れないスタック」に近づきます。移行先の決定を待たずに着手できる対策は後述しますが、要点は、構成の意図がマニフェストにしか残っていない状態を早めに解消することです。

Amazon ECS Express Modeへの移行手順とCopilotパターンの読み替え

必要な入力3つとCLIでの作成コマンド

Amazon ECS Express Modeは2025年11月21日に発表された、ECSの簡易デプロイ経路です。追加料金はかからず、課金対象は作成された下層リソースだけになります。提供リージョンは発表時点で全リージョンとされ、AWS GovCloud（US-East・US-West）は2026年6月15日に追加されました。渡すのはコンテナイメージ、タスク実行ロール、インフラロールの3つで、ECSクラスター、タスク定義、Application Load Balancer、オートスケーリングポリシー、そしてAWS提供のドメイン名によるHTTPSエンドポイントまでが自動で構成されます。ALBは最大25サービスまで共有され、host-headerベースのリスナールールでサービス間の分離が保たれます。

AWS CLIから作る場合のコマンドは次のとおりです。API定義上の必須パラメータは --infrastructure-role-arn だけですが、開発者ガイドはタスク実行ロールも必要な入力として扱っています。省略して既定値が使われるのはサービス名（未指定ならECSが生成）とクラスター名（未指定ならdefaultクラスター）です。

aws ecs create-express-gateway-service \
  --infrastructure-role-arn "arn:aws:iam::012345678901:role/ecsInfrastructureRoleForExpressServices" \
  --execution-role-arn "arn:aws:iam::012345678901:role/ecsTaskExecutionRole" \
  --primary-container '{
    "image": "012345678901.dkr.ecr.ap-northeast-1.amazonaws.com/my-app/web:latest",
    "containerPort": 80
  }' \
  --monitor-resources DEPLOYMENT

末尾の --monitor-resources は値を取るオプションで、裸のフラグとしては渡せません。DEPLOYMENTを指定すると直近のデプロイで増減するリソースだけが、RESOURCEを指定するとサービスの全リソースが表示されます。コンソールから作る場合は、ECSコンソールのExpress Modeで作成を選び、Amazon ECRのイメージURIと2つのロールを指定します。ロールに必要な権限は管理ポリシーの AmazonECSTaskExecutionRolePolicy と AmazonECSInfrastructureRoleforExpressGatewayServices にまとまっており、コンソールから未作成のロールを生成することもできます。イメージの置き場所であるECR側の準備はAWS ECRとは？料金・ECSとの違いとDockerイメージのpush手順【2026年版】にまとめています。

Copilotの6パターンをExpress Modeへ読み替える対応関係

Load Balanced Web Service と Request-Driven Web Service は、どちらもExpress Modeで置き換えられます。前者はALB配下のFargateサービスという構成がそのまま対応し、後者はリクエスト量に応じたスケーリングをオートスケーリングメトリクスのREQUEST_COUNT_PER_TARGETで再現します。

Backend Service も移せます。Express Modeはパブリックとプライベートの両方のHTTPSリクエストを扱えるため、プライベートサブネットを指定すれば内部ALB構成のExpress Modeサービスとして組み直せます。

守備範囲から外れるのは、HTTPを受けないワークロードです。SQSのキューを処理する Worker Service とcron起動の Scheduled Job は、通常のECSサービスやECSタスクとしてCDKやCloudFormationで組み直してください。Static Site もCloudFrontとS3の構成なので、Express Modeの対象外です。Express Modeの設定項目や料金の詳細はECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説【2026年版】で扱っています。

AWS CDKへの移行：L1コンストラクトとL3コンストラクトの使い分け

CfnExpressGatewayServiceでExpress Modeをコード化する場合

CDKからExpress Modeを作るときは、aws_ecs モジュールのL1コンストラクト CfnExpressGatewayService を使います。リクエスト数に応じたスケーリングを設定すれば、CopilotのRequest-Driven Web Serviceと同等の挙動になります。

from aws_cdk import Stack, aws_ecs as ecs
from constructs import Construct

class EcsExpressStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        ecs.CfnExpressGatewayService(
            self, "ExpressGatewayService",
            execution_role_arn=f"arn:aws:iam::{self.account}:role/ecsTaskExecutionRole",
            infrastructure_role_arn=f"arn:aws:iam::{self.account}:role/ecsInfrastructureRoleForExpressServices",
            primary_container=ecs.CfnExpressGatewayService.ExpressGatewayContainerProperty(
                image=f"{self.account}.dkr.ecr.{self.region}.amazonaws.com/my-app/web:latest"
            ),
            cpu="1024",
            memory="2048",
            scaling_target=ecs.CfnExpressGatewayService.ExpressGatewayScalingTargetProperty(
                min_task_count=1,
                max_task_count=10,
                auto_scaling_metric="REQUEST_COUNT_PER_TARGET",
                auto_scaling_target_value=1000
            )
        )

L1コンストラクトはCloudFormationリソースの薄いラッパーなので、Express Mode側で使えるプロパティをそのまま指定できます。ここで指定を省くと、API定義上の既定値であるCPUUtilizationを指標とした目標値60が適用されます。上のコードはこれをリクエスト数ベースへ切り替えたもので、閾値1000はターゲットあたりのリクエスト数です。アプリの処理能力に合わせて調整してください。

ApplicationLoadBalancedFargateServiceで細かく制御する場合

VPCの構成やログ保持期間まで自分で決めたい場合は、aws_ecs_patterns のL3コンストラクト ApplicationLoadBalancedFargateService を使います。これはCopilotのLoad Balanced Web Serviceに相当する構成を、型定義を保ったまま組み立てるものです。VPCとサブネットの構成、ALBのリスナールール、CloudWatch Logsの保持期間、タスクロールの権限まで、すべてコード側で指定できます。Python、TypeScript、Java、C#、Goから選べるので、アプリ本体と同じ言語でインフラを書き、同じリポジトリでバージョン管理できます。

Express ModeとL3コンストラクトのどちらを選ぶかは、既定値を受け入れられるかで決まります。ALBのリスナールールやサブネット配置に要件があるならL3コンストラクト、なければExpress Modeです。同じ構成をExpress ModeならCLIの1コマンドで作れるのに対し、L3コンストラクトではVPCとクラスターの定義を含めて30行前後のコードになります。ECSやFargateの基礎的な構成要素についてはAWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】とAWS Fargateとは？EC2との違い・料金をわかりやすく解説【2026年版】を参照してください。

既存Copilot環境の当面の運用とインストール手順

アーカイブ後もバイナリを入手できる経路

既存環境の保守目的でCopilot CLIが必要な場合、GitHub Releasesから直接取得できます。入手できるのは最終版のv1.34.1です。

curl -Lo copilot https://github.com/aws/copilot-cli/releases/download/v1.34.1/copilot-linux
chmod +x copilot
sudo mv copilot /usr/local/bin/copilot
copilot --version

latestではなくバージョンを明示したURLにしているのは意図的です。開発が止まったツールでは latest 経由の暗黙アップデートに利点がなく、CI環境では取得先を固定したほうが再現性を保てます。アーキテクチャ別の資産名にも注意が必要で、Apple Siliconのmacは copilot-darwin-arm64、ARM系Linuxは copilot-linux-arm64 を選びます。無印の copilot-darwin と copilot-linux はx86_64版です。各バイナリには .asc の署名と .md5 が併置されているので、パッチが出ない前提で使う以上、取得後の検証は済ませておいてください。

移行前に手元へ保全しておく生成物と設定

移行先を決める前でも、Copilotが作った資産の棚卸しは先に済ませられます。copilot app ls でアプリケーション一覧、copilot svc ls でサービス一覧、copilot svc status で稼働状況を確認できます。あわせて、リポジトリ直下の copilot ディレクトリに置かれた manifest.yml も保全してください。CPU・メモリ・ポート・環境変数・スケーリング設定といった、いまの構成の意図はここにしか残っていません。移行先でパラメータを埋めるときの元データになります。

そのうえで、CloudFormationコンソールから該当スタックのテンプレートをエクスポートし、リポジトリへコミットします。前述のとおり生成物は標準のCloudFormationスタックなので、テンプレートが手元にあればCopilotなしで更新を継続でき、AWSが挙げる「Copilotリソースの引き継ぎ」がそのまま成立します。ECSのデプロイをより宣言的に管理し直したい場合は、ecspressoとは｜ECSデプロイをコードで管理する仕組みと導入手順を解説で扱っているようなサードパーティのデプロイツールも選択肢に入ります。

よくある質問

AWS Copilot CLIのサービス終了はいつですか？

2026年6月12日です。AWSは2026年3月6日にContainersブログの記事「Announcing the end-of-support for the AWS Copilot CLI」で告知しました。この日以降、AWSからの新機能追加、セキュリティパッチ、テクニカルサポートは提供されません。ツール自体はApache-2.0のオープンソースとしてGitHubに残ると明記されています。なお、デプロイ済みアプリケーションの停止についてはAWSの告知に言及がありませんが、Copilotの生成物は標準のCloudFormationスタックなので、Copilotの終了によって稼働が止まることはありません。

終了後もAWS Copilot CLIをインストールできますか？

できます。aws/copilot-cli のリポジトリはアーカイブされましたが、GitHub Releasesの資産は引き続き配布されており、2026年8月10日時点でもダウンロード可能な状態です。入手できるのは最終リリースのv1.34.1（2025年4月10日）だけで、以降の版は出ません。セキュリティ上の問題が見つかっても修正版は提供されないため、新規プロジェクトでの採用は避け、既存環境の保守に限定してください。

AWS CopilotとGitHub Copilotは何が違いますか？

開発元も用途も別の製品です。AWS Copilot CLIはAWSが提供していたコンテナアプリの配信ツールで、ECSやApp Runnerへのデプロイを担当します。GitHub CopilotはGitHubのAIコード補完サービス、Microsoft 365 CopilotやCopilot StudioはMicrosoftの業務向けAI製品です。探しているのがAIによるコード補完なら、この記事の対象ではありません。

移行先はECS Express ModeとAWS CDKのどちらを選ぶべきですか？

標準的なWebアプリケーションやAPIであればECS Express Modeです。コンテナイメージと2つのIAMロールを渡すだけで、ALB・オートスケーリング・HTTPSまで自動構成され、追加料金もかかりません。複数サービスにまたがる構成、既存CDKスタックとの統合、コンプライアンス要件による細かい制御が必要ならAWS CDKが適します。両者は排他ではありません。CDKからCfnExpressGatewayServiceでExpress Modeを作る組み合わせも選べます。

Copilotで作った既存のインフラは移行時にどうなりますか？

そのまま残ります。Copilotが生成していたのは標準的なCloudFormationスタックで、AWSも移行の選択肢として、生成済みテンプレートを自チームで引き継ぐ方法を挙げています。移行を決める前でも、CloudFormationコンソールからテンプレートをエクスポートし、あわせてcopilotディレクトリのmanifest.ymlを保全しておけば、マニフェスト構文への依存を先に切り離せます。

関連記事

• ECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説【2026年版】
• AWS App Runnerは終了する？2026年の新規受付停止・メンテナンスモード移行と移行先を解説
• AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】
• AWS Fargateとは？EC2との違い・料金をわかりやすく解説【2026年版】
• AWS ECRとは？料金・ECSとの違いとDockerイメージのpush手順【2026年版】