AWS App Runner終了から1ヶ月｜ECS Express Mode移行の実装手順と落とし穴

AWS App Runnerの新規受付終了から、本記事執筆時点（2026年5月22日）で約1カ月が経ちました。既存ユーザーは引き続き利用できますが、新機能の追加はされません。AWSが推奨する移行先は、2025年11月にre:Invent 2025で発表されたAmazon ECS Express Mode。とはいえ、実際に移行を進めようとすると、料金体系の違いや「スケール to ゼロが無くなる」といった落とし穴があり、単純な置き換えにはなりません。

App Runnerは2021年5月に登場した、コンテナアプリを最も手軽にデプロイできるAWSサービスでした。コンテナイメージかソースコードを渡せば、ロードバランサーもオートスケーリングも自動。終了まで5年弱の道のりです。この記事では、終了から1カ月経った5月時点の現在地を整理した上で、ECS Express Modeへの実装手順、移行コストの見積もり、そして実際にやってみるとぶつかる落とし穴を順番に書いていきます。

何が起きたのか

AWS公式ドキュメントによると、AWSは「慎重な検討の結果」App Runnerへの新規顧客アクセスを終了し、「顧客が最も価値を見出すイノベーションの提供に集中する」と説明しています。

完全な停止日は発表されていません。あくまで「新規顧客の受付を終了する」という発表であり、4月30日以降もすでにApp Runnerを利用しているユーザーはサービスを使い続けることができます。ただし、新しくAWSアカウントを作ってApp Runnerを使い始めることはできなくなります。

新規受付終了＝即サービス停止ではない。ではいつ止まるのか

「新規受付が終了した」と聞いて真っ先に気になるのは、「じゃあいつ本当に使えなくなるの？」という点です。結論から言えば、現時点でApp Runnerの完全停止日は発表されていません。

AWSのサービスライフサイクルでは、サービスの終了は3段階で進みます。

App Runnerは現在①のMaintenanceフェーズに入ったばかりです。完全停止（③）に至るには、まず②のSunset告知が必要で、通常はそこから12ヶ月の猶予が設けられます。つまり、仮に明日Sunsetが告知されたとしても、最低1年は使い続けられる計算です。

では、過去に「新規受付停止」を経たAWSサービスは、実際にどうなったのでしょうか。

OpsWorksのように12ヶ月で完全停止するケースもあれば、CodeCommitやSimpleDBのように何年も「新規受付停止」のまま稼働し続けるケースもあります。App Runnerがどちらのパターンになるかは現時点では分かりませんが、少なくとも今日明日で突然止まることはなく、Sunset告知が出てからさらに12ヶ月の猶予があると考えておくのが妥当です。

既存ユーザーはどうすればいいのか

まず前提として、4月30日以降もApp Runnerがいきなり止まるわけではありません。AWSは「セキュリティと可用性への投資を継続する」と明言しています。今日明日で移行しなければならない状況ではないということです。

ただし、新機能が追加されないということは、競合サービス（Google CloudのCloud Run、Azure Container Apps等）が進化していく中で、App Runnerは現状維持のまま取り残されていくことを意味します。長期的に見れば、移行を検討すべきタイミングに来ています。

AWSが案内している移行の選択肢は大きく2つです。

1つ目は、推奨されているECS Express Modeへの移行です。App Runnerの「簡単にデプロイできる」という特長を受け継ぎつつ、ECSの柔軟性も使えるサービスです。AWSは公式の移行ガイドで、Route 53の加重ルーティングを使った段階的なトラフィック移行（10% → 25% → 50% → 75% → 100%）を推奨しています。

2つ目は、AWS CDK L3コンストラクトやCloudFormationを使った通常のECS構成への移行です。インフラの細かい制御が必要なチーム向けの選択肢になります。

移行先のECS Express Modeとは何か

ECS Express Modeは、2025年11月のre:Invent 2025で発表されたECSの新機能です。コンテナイメージとIAMロールを渡すだけで、ALB（ロードバランサー）、オートスケーリング、SSL/TLS終端、CloudWatchモニタリングまで自動でセットアップしてくれます。

App Runnerと似たコンセプトですが、決定的な違いがあります。App Runnerはインフラを完全に隠蔽していたのに対し、ECS Express Modeは自動セットアップされた全リソース（ECSクラスタ、タスク定義、ALB、セキュリティグループなど）にユーザーがアクセスして変更できます。「最初は簡単に始めて、必要に応じて細かくいじれる」という設計思想です。

注意すべき点がいくつかあります。App Runnerの大きな魅力だった「ソースコードから直接デプロイ」と「スケール to ゼロ」は、ECS Express Modeでは使えません。GitHubにコードをプッシュするだけで自動デプロイできていた環境を再現するには、GitHub Actionsの設定やDockerfileの作成が別途必要になります。また、アクセスがない時間帯にタスクをゼロにしてコストを抑える運用も、ECS Express Modeの構造上できません。

ECS Express Modeへの移行手順

App RunnerからECS Express Modeへの移行は、AWSが公式の移行ガイドで段階的なトラフィック移行を推奨しています。実務的な流れは以下のようになります。

1. コンテナイメージをECRに置く

App Runnerでソースコード直接デプロイを使っていた場合、まずDockerfileを書いてECR（Elastic Container Registry）にイメージをプッシュする工程が必要になります。すでにイメージベースで運用していた場合はそのまま使えます。aws ecr get-login-password でログインして docker push、これは普通のECS運用と同じ手順です。

2. ECSクラスタとExpress Modeサービスを作成

マネジメントコンソールから「Amazon ECS」→「Create cluster」と進み、起動モードで「Express」を選択。あとはコンテナイメージのECR URI、CPU（vCPU単位）、メモリ（GB単位）、リスナーポートを指定すれば、ALB・セキュリティグループ・ターゲットグループ・CloudWatchロググループまでが自動でプロビジョニングされます。CDKやCloudFormationを使いたい場合はExpress Mode用のL3コンストラクトが2025年12月にリリースされており、IaCで管理することもできます。

3. Route 53で加重ルーティングを構成

既存のApp RunnerのカスタムドメインとECS Express ModeのALB DNS名を、同じレコードに加重ルーティングで設定します。AWSが推奨しているのは 10% → 25% → 50% → 75% → 100% の段階移行。最初の10%で動作確認、CloudWatchでエラーレートとレイテンシを比較しながら段階的に上げていきます。問題が出たら即座に元の重みに戻せば旧App Runnerに戻ります。

4. CI/CDを再構築する

App Runnerの「GitHub連携で自動デプロイ」がなくなるので、GitHub ActionsかCodePipelineで代替します。AWSが公開しているamazon-ecs-deploy-express-serviceアクションを使うのが最短経路で、cluster-nameとservice-nameを指定すれば、ECRへのプッシュからカナリアデプロイまで一通り回せます。

5. App Runner側を切り離す

トラフィックが100%ECS Express Modeに乗ったら、App Runner側のオートスケーリングを最小にしてから数日間モニタリング。問題が出ないことを確認したら、App Runnerサービスを削除します。CloudWatchのカスタムメトリクスやVPCコネクタも忘れずに片付けておくと、後から「使ってないのに課金されている」を防げます。

移行でぶつかる5つの落とし穴

公式手順通りに進めても、実際に作業してみないと気づきにくい点がいくつかあります。事前に把握しておくと作業見積もりがブレません。

スケール to ゼロが消える

前のセクションでも触れたとおり、ECS Express Modeは最低1タスクを常時起動します。社内の管理画面や開発環境のように「夜間や週末は誰も触らない」アプリケーションをApp Runnerで運用していた場合、Fargate Spot（最大70%引き）を組み合わせるか、Lambdaへ移すか、を移行と同時に判断する必要が出てきます。Fargate Spotは中断のリスクがあるので、本番のWebサービスには使えません。

25サービス共有ALBの制限

ECS Express Modeは1台のALBを最大25サービスで共有してコストを抑える設計です。一見お得ですが、同じALBに乗る他サービスの障害がトラフィックに影響する可能性があります。本番系と検証系を同じALBに乗せると、検証側の事故で本番が遅くなる、といったケースが起こり得ます。重要度の高いサービスは独立したALBを別途用意するのが現実的です。

VPC設定が継承されない

App RunnerでVPCコネクタを使ってRDSやElastiCacheにアクセスしていた場合、ECS Express ModeではVPC・サブネット・セキュリティグループを明示的に設定し直す必要があります。同じVPCを指定しても、セキュリティグループのルールはApp Runner→ECSで微妙に違うので、PrivateLinkやNAT Gateway経由の通信は移行直後に必ず疎通確認してください。

カナリアデプロイの挙動

ECS Express Modeはデフォルトでカナリアデプロイになります。新リビジョンをデプロイすると、まず10%のトラフィックが新コンテナに流れ、ヘルスチェックを経て段階的に100%に上がっていく。App Runnerのローリングデプロイに慣れていると、デプロイの完了タイミングが想定より遅く感じるはずです。ヘルスチェックパスを明示的に設定しておかないと、思わぬところで失敗判定されてロールバックが発生します。

監視・ログの粒度が変わる

App Runnerは「リクエスト数」「レスポンスタイム」「アクティブインスタンス数」など、Webサービス向けのメトリクスをまとめてくれていました。ECSではCPU/メモリ使用率は出ますが、アプリケーションレイヤのメトリクスはX-RayやService Connectを有効にしないと取れません。CloudWatchダッシュボードも作り直しになるので、移行前のメトリクス取得項目を一覧化しておくと作業が楽になります。

移行するとコストはどう変わるのか

移行を検討するうえで避けて通れないのが料金の比較です。App Runnerと、ECS Express Modeの基盤であるAWS Fargateの東京リージョン料金を並べてみます。

単価だけを見ると、FargateはApp RunnerよりvCPUで約37%、メモリで約37%安い（x86比較）です。しかし、実際のコストはワークロードの特性によって大きく変わります。

たとえば1 vCPU・2 GBメモリの小規模Webアプリで試算してみます。

常時高負荷なアプリであればECS Express Modeの方がコストメリットがあります。一方、アクセスが少ない時間帯が長いアプリでは、App Runnerのスケール to ゼロが効いて大幅に安くなるケースもあります。ECS Express Modeへの移行で「単価は下がるがトータルコストは上がる」というパターンもありえるため、自分のワークロードに当てはめた試算は必須です。

料金の詳細は以下の公式ページで確認できます。

• ▸AWS App Runner Pricing
• ▸AWS Fargate Pricing

AWS Copilot CLIも6月にサポート終了

App Runnerと関連して、AWS Copilot CLIも2026年6月12日にサポートを終了します。Copilot CLIはECSやApp Runner上でのコンテナアプリのビルド・リリースを簡素化するツールでした。

AWSはCopilot CLIの終了理由として、独自のCLIツールとマニフェスト構文の学習コスト、インフラの可視性の限界、カスタマイズの制約を挙げています。終了後もGitHubのオープンソースプロジェクトとしてはコードが残りますが、AWSからのセキュリティアップデートや新機能は提供されません。

App Runner、Copilot CLI、そして2026年10月にサポートが完全終了するAWS Proton。コンテナ周辺の「簡易デプロイ系」サービスが、ECS（+Express Mode）とCDKに集約されつつある流れが見えてきます。

2024年から続くAWSのサービス整理

App Runnerの新規受付停止は、AWSが2024年から進めているサービスポートフォリオの整理の一環です。2024年7月にはCodeCommit、Cloud9、CloudSearchなど複数のサービスが新規受付を停止しました。

AWSのサービス数は200を超えており、似た機能を持つサービスが複数存在する状態が長く続いていました。コンテナの簡易デプロイだけでも、App Runner、Copilot CLI、Elastic Beanstalk、Proton、Lightsail Containersと選択肢が乱立していた時期があります。GitHubのApp Runnerロードマップでは、2024年後半から機能追加がほぼ停止していたことが開発者コミュニティから指摘されており、今回の発表は予兆があったとも言えます。

開発者コミュニティの反応

App Runnerの終了に対する開発者の反応は、「やっぱりか」という声が大半です。GitHubのロードマップIssueでは、2025年初頭から「2024年は機能改善がたった2件。2023年は17件あったのに」「HTTP/2サポートがバックログに放置されすぎてHTTP/3が要求される事態になっている」といった不満の声が上がっていました。

一方、ECS Express Modeに対しては期待と懸念が混在しています。「App Runner並の簡単さでECSを使えるのは歓迎」という声がある一方、Hacker Newsでは「スケール to ゼロができない時点でApp Runnerの代替にはならない」「Cloudflare Containersの方が使用量課金で合理的」といった指摘も出ています。

ECS Express Modeが発表された2025年11月の時点で、App Runnerの終了を予測していた開発者は少なくありませんでした。

終了から1カ月、これから何を見ておくか

App Runnerは「コンテナを最も簡単にデプロイできるサービス」として5年間提供されてきましたが、AWSのサービス整理方針の中で、ECS Express Modeにその役割を譲る形になりました。既存ユーザーが今日明日でサービスが止まる、ということはありません。AWSのサービスライフサイクルから見ても、完全停止にはSunset告知から12カ月の猶予が必要で、過去にはCodeCommitのように新規停止から2年近く稼働し続けている例もあります。

ただし、新機能が止まった以上、いつかは移行を判断するタイミングが来ます。実際にECS Express Modeへ動かしてみると、スケール to ゼロが消えること、ALB共有のリスク、VPC設定の引き直し、カナリアデプロイの挙動変化など、料金単価以外の要素で運用設計が変わってくる箇所が多い。長期にApp Runnerに乗せていたチームほど、移行作業の見積もりは厚めに取っておくほうが安全です。DevelopersIOの解説記事やPublickeyの紹介記事は、移行検討の入り口として役立ちます。

AWSのサービス整理はまだ続きます。「便利だが他サービスと機能が重なっている」ものは今後も統廃合の対象になりえます。使っているサービスがいつ終了対象に入っても困らないよう、コンテナイメージベースのポータブルな構成を意識しておくことが、結局のところ一番の備えになります。

参照元

• ▸ AWS App Runner availability change - AWS公式ドキュメント
• ▸ AWS Service Lifecycle - AWS General Reference
• ▸ Announcing Amazon ECS Express Mode - AWS What's New（2025年11月21日）
• ▸ Build production-ready applications using Amazon ECS Express Mode - AWS Blog
• ▸ AWS App Runner Pricing
• ▸ AWS Fargate Pricing
• ▸ Announcing the end of support for the AWS Copilot CLI - AWS Containers Blog
• ▸ App Runner Roadmap Issue #274 - GitHub
• ▸ ECS Express Modeを利用できるようになりました - DevelopersIO
• ▸ Amazon ECS Express Mode提供開始 - Publickey
• ▸ AWS Introduces ECS Express Mode - InfoQ（2025年12月）
• ▸ ECS Express Mode discussion - Hacker News