【速報】AWS App Runner、4月30日で新規受付終了。移行先はECS Express Mode
AWSがApp Runnerの新規顧客への提供を2026年4月30日に終了。既存ユーザーは継続利用可能だが新機能追加はなし。推奨移行先のECS Express Modeとの違いや、取るべきアクションを解説します。
ニュース
kkm
Backend Engineer / AWS / Django
AWSがApp Runnerの新規顧客への提供を2026年4月30日に終了。既存ユーザーは継続利用可能だが新機能追加はなし。推奨移行先のECS Express Modeとの違いや、取るべきアクションを解説します。
AWSがApp Runnerの新規顧客への提供を2026年4月30日に終了します。既存ユーザーは引き続き利用できますが、新機能の追加は行われません。移行先として推奨されているのは、2025年11月にre:Invent 2025で発表されたAmazon ECS Express Modeです。
App Runnerは2021年5月に登場した、コンテナアプリケーションを最も簡単にデプロイできるAWSサービスでした。コンテナイメージかソースコードを渡すだけで、ロードバランサーやオートスケーリングの設定を一切意識することなくアプリを公開できる手軽さが売りでした。
何が起きたのか
AWS公式ドキュメントによると、AWSは「慎重な検討の結果」App Runnerへの新規顧客アクセスを終了し、「顧客が最も価値を見出すイノベーションの提供に集中する」と説明しています。
| 項目 | 内容 |
|---|---|
| 対象 | AWS App Runner |
| 新規受付停止日 | 2026年4月30日 |
| 既存ユーザー | 継続利用可能 （新規サービス作成も可） |
| 新機能の追加 | なし （セキュリティ・可用性の投資は継続） |
| 推奨移行先 | Amazon ECS Express Mode |
完全な停止日は発表されていません。あくまで「新規顧客の受付を終了する」という発表であり、4月30日以降もすでにApp Runnerを利用しているユーザーはサービスを使い続けることができます。ただし、新しくAWSアカウントを作ってApp Runnerを使い始めることはできなくなります。
新規受付終了＝即サービス停止ではない。ではいつ止まるのか
「新規受付が終了した」と聞いて真っ先に気になるのは、「じゃあいつ本当に使えなくなるの？」という点です。結論から言えば、現時点でApp Runnerの完全停止日は発表されていません。
AWSのサービスライフサイクルでは、サービスの終了は3段階で進みます。
| フェーズ | 内容 | App Runnerの現状 |
|---|---|---|
| ① Maintenance | 新規顧客の受付停止。 既存ユーザーは継続利用可。 新機能の追加なし | ← 今ここ |
| ② Sunset | サービス終了の告知。 通常12ヶ月の猶予期間あり | 未到達 |
| ③ Full Shutdown | 完全にサービスが削除され、 一切利用不可になる | 未到達 |
App Runnerは現在①のMaintenanceフェーズに入ったばかりです。完全停止（③）に至るには、まず②のSunset告知が必要で、通常はそこから12ヶ月の猶予が設けられます。つまり、仮に明日Sunsetが告知されたとしても、最低1年は使い続けられる計算です。
では、過去に「新規受付停止」を経たAWSサービスは、実際にどうなったのでしょうか。
| サービス | 新規受付停止 | 完全停止日 | 停止までの期間 |
|---|---|---|---|
| OpsWorks Stacks | 2023年5月 | 2024年5月26日 | 約12ヶ月 |
| OpsWorks for Chef | 2024年2月頃 | 2024年5月5日 | 約3ヶ月 |
| OpsWorks for Puppet | 2024年2月頃 | 2024年3月31日 | 約2ヶ月 |
| CodeStar | 2024年7月 | プロジェクト機能のみ終了 （リソースは存続） | — |
| CodeCommit | 2024年7月 | 未定 （2026年4月時点で稼働中） | 21ヶ月以上経過 |
| Cloud9 | 2024年7月 | 未定 （2026年4月時点で稼働中） | 21ヶ月以上経過 |
| SimpleDB | 2010年代前半 | 未定 （10年以上稼働中） | 10年以上 |
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 | ECS Express Mode |
|---|---|---|
| インフラの可視性 | ALB等は隠蔽 | 全リソースにアクセス可能 |
| ソースコードから 直接デプロイ | 対応 （GitHub連携） | 非対応 （CI/CDの構築が必要） |
| スケール to ゼロ | 対応 （アイドル時は低コスト） | 非対応 （最低1タスクが必要） |
| 料金モデル | 使用量ベース | 容量ベース （ALB共有で最大25サービス） |
| サイドカーコンテナ | 非対応 | 対応 |
| IaC対応 | CloudFormation | CloudFormation, CDK, Terraform |
| デプロイ方式 | ローリング | カナリアデプロイ （デフォルト） |
注意すべき点がいくつかあります。App Runnerの大きな魅力だった「ソースコードから直接デプロイ」と「スケール to ゼロ」は、ECS Express Modeでは使えません。GitHubにコードをプッシュするだけで自動デプロイできていた環境を再現するには、GitHub Actionsの設定やDockerfileの作成が別途必要になります。また、アクセスがない時間帯にタスクをゼロにしてコストを抑える運用も、ECS Express Modeの構造上できません。
移行するとコストはどう変わるのか
移行を検討するうえで避けて通れないのが料金の比較です。App Runnerと、ECS Express Modeの基盤であるAWS Fargateの東京リージョン料金を並べてみます。
| 料金項目 | App Runner | Fargate（x86） | Fargate（ARM） |
|---|---|---|---|
| vCPU（1時間あたり） | $0.0809 | $0.05056 | $0.04045 |
| メモリ（1GB/1時間あたり） | $0.00885 | $0.00553 | $0.00442 |
| スケール to ゼロ | 対応 （アイドル時はメモリのみ課金） | 非対応 （最低1タスク分の課金が発生） | |
| ロードバランサー（ALB） | 料金に含まれる | 別途必要 （月額 約$18〜25 + 従量課金） | |
単価だけを見ると、FargateはApp RunnerよりvCPUで約37%、メモリで約37%安い（x86比較）です。しかし、実際のコストはワークロードの特性によって大きく変わります。
たとえば1 vCPU・2 GBメモリの小規模Webアプリで試算してみます。
| シナリオ | App Runner | ECS Express Mode （Fargate x86） |
|---|---|---|
| 常時稼働（24h × 30日） | vCPU: $58.25 メモリ: $12.74 ALB: $0 合計: 約$71/月 | vCPU: $36.40 メモリ: $7.96 ALB: 約$20 合計: 約$64/月 |
| 日中8h稼働 +16hアイドル | 稼働: $21.50 アイドル（メモリのみ）: $8.50 ALB: $0 合計: 約$30/月 | （スケール to ゼロ不可のため 常時稼働と同額） 合計: 約$64/月 |
常時高負荷なアプリであればECS Express Modeの方がコストメリットがあります。一方、アクセスが少ない時間帯が長いアプリでは、App Runnerのスケール to ゼロが効いて大幅に安くなるケースもあります。ECS Express Modeへの移行で「単価は下がるがトータルコストは上がる」というパターンもありえるため、自分のワークロードに当てはめた試算は必須です。
料金の詳細は以下の公式ページで確認できます。
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など複数のサービスが新規受付を停止しました。
| サービス | 新規受付停止日 | 推奨移行先 |
|---|---|---|
| CodeCommit | 2024年7月 | GitHub, GitLab |
| Cloud9 | 2024年7月 | IDE Toolkits, CloudShell |
| CloudSearch | 2024年7月 | OpenSearch |
| AWS Proton | 2025年10月 | CloudFormation, CDK |
| App Runner | 2026年4月 | ECS Express Mode |
| Copilot CLI | 2026年6月（EOL） | ECS Express Mode, CDK |
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の終了を予測していた開発者は少なくありませんでした。
まとめ
App Runnerは「コンテナを最も簡単にデプロイできるサービス」として5年間提供されてきましたが、AWSのサービス整理方針の中で、ECS Express Modeにその役割を譲る形になりました。
既存ユーザーがすぐに困ることはありません。AWSのサービスライフサイクルから見ても、完全停止には「Sunset告知＋12ヶ月の猶予」が必要で、過去にはCodeCommitのように新規停止から2年近く稼働し続けている例もあります。ただ、新機能が追加されない以上、いつかは移行を考える必要があります。
移行先のECS Express Modeは「簡単さと柔軟性の両立」を目指したサービスですが、ソースコード直接デプロイやスケール to ゼロといった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