AWS App Runnerは終了する？2026年の新規受付停止・メンテナンスモード移行と移行先を解説

「AWS App Runner 終了」という検索が増えているのは、2026年3月31日にAWSがApp Runnerを新規顧客に開放しないと発表したためです。ただし「サービス即終了」ではありません。2026年4月30日以降は新規顧客が使えなくなり、App Runnerはメンテナンスモードへ移行しますが、既存顧客はこれまで通り利用でき、新しいサービスの作成も続けられます。本記事では、この提供状況変更が実際に何を意味するのか、既存ユーザーは継続と移行のどちらを選ぶべきか、AWSが推奨する移行先「Amazon ECS Express Mode」への具体的な手順までを、AWS公式の一次情報に基づいて整理します。

まとめ：App Runnerの提供状況変更の要点

• 「終了」ではなく「新規受付停止＋メンテナンスモード」。2026年4月30日以降、新規顧客はApp Runnerを利用できない。
• 既存顧客は継続利用でき、新規リソース・サービスの作成も可能。AWSは運用・サポート・セキュリティ更新を継続する。
• 新機能の追加は行われない。可用性とセキュリティへの投資のみ継続する。
• 完全終了（Sunset／EOL）の日付は未発表。将来的な終了に備え、新規プロジェクトは他サービスで始めるのが安全。
• AWS推奨の移行先はAmazon ECS Express Mode（2025年12月提供開始）。単一APIでApp Runner相当の環境を用意でき、サービス自体の追加料金はない。

以下で、発表内容の正確な意味・既存ユーザーの判断基準・代替サービス比較・移行手順を順に見ていきます。

AWS App Runnerの提供状況変更（2026年4月30日 新規受付停止）

AWSは2026年3月31日、複数サービスのライフサイクル変更の一環としてApp Runnerの提供状況変更を発表しました。公式のWhat’s New（AWS Service Availability update）では「2026年4月30日以降、新規のお客様にはご利用いただけなくなります」と明記され、同時にApp Runnerは「メンテナンス（Maintenance）」ステータスへ移行します。この変更はApp Runner単体ではなく、AWS全体でのサービスポートフォリオ整理の一環として発表されました。

「終了」と「メンテナンスモード」の違い

検索で使われる「終了」という語は、正確には2つの段階に分かれます。今回のApp Runnerはメンテナンスモード（新規受付停止）であり、完全停止を意味するSunset（EOL）ではありません。AWS公式ドキュメント（App Runner availability change）は、既存顧客について「引き続きサービスを通常どおり利用でき、新しいリソースやサービスの作成も含まれる」と述べています。つまり、いま動いているApp Runnerサービスが4月30日で止まるわけではなく、既存アカウントであればその後も新しいApp Runnerサービスを立ち上げられます。AWSはセキュリティと可用性への投資を続ける一方、新機能は追加しないと明言しており、Sunset日は現時点で未発表です。

App Runner新規停止の背景（ECS Express Modeとの機能重複）

背景にあるのは、2025年12月に登場したAmazon ECS Express Modeとの機能重複です。App Runnerは「コンテナやソースを渡すだけで公開できる手軽さ」を売りにしていましたが、同じ設定不要の公開体験をECSの機能セット上で提供するECS Express Modeが用意されたことで、ほぼ同じ役割の製品が2つ並ぶ状態になりました。AWSは重複プロダクトを維持するより、ECS Express Modeへ集約する判断を下したとみられます。実際、公式の移行ガイドもApp RunnerからECS Express Modeへの移行だけを案内しており、AWSの中でApp Runnerの後継はECS Express Modeだと位置づけられていると読み取れます。

AWS App Runnerの概要（Fargate上のフルマネージド実行環境）

AWS App Runnerは、コンテナイメージまたはソースコードを渡すだけで、ビルド・デプロイ・オートスケール・HTTPS公開までを自動で行うフルマネージドのアプリケーション実行サービスです。KubernetesやECSのようなクラスター設計・ロードバランサー設定を意識せずにWebアプリやAPIを数分で公開できる点が評価され、スタートアップやPoC、小〜中規模のWebサービスで使われてきました。裏側はFargate上で動作し、常時稼働型のHTTPサービスに向いています。主な機能は次の通りです。

この「設定不要で公開できる」体験がApp Runnerの本質であり、その体験をECSの上で再現したものがECS Express Modeにあたります。ECS全体像はAWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違いで、実行基盤のFargateはAWS Fargateとは？EC2との違い・料金で解説しています。

既存ユーザーが今すべき判断（継続か、移行か）

今回の変更で既存App Runnerが即座に使えなくなるわけではないため、慌てて全サービスを移す必要はありません。判断は「新機能への依存度」と「Sunset未定というリスクをどう見るか」で分かれます。

当面はそのまま使い続けてよいケース

既存のApp Runnerサービスが安定稼働しており、追加の新機能を必要としないなら、当面は移行を急ぐ必要はありません。既存顧客は新規サービスの作成も引き続き可能なため、稼働中システムの延長や小さな追加であればApp Runner上で完結できます。AWSがセキュリティと可用性を継続保証している点も、短期的には継続利用を後押しします。

早めに移行を検討すべきケース

一方で、次に当てはまる場合は早めの移行計画をおすすめします。第一に、新しいAWSアカウントを増やす予定がある組織です。2026年4月30日以降に新規で開設したAWSアカウント（新規顧客）はApp Runnerを一切使えないため、標準スタックにApp Runnerを据え続けると新規案件で詰まります。第二に、App Runnerに今後の機能改善を期待していたプロジェクトです。新機能は追加されないため、機能面での成長は見込めません。第三に、長期運用が前提のミッションクリティカルなサービスです。Sunset日が未発表である以上、いつ終了予告が出ても慌てないよう、移行先の検証だけでも先に済ませておく価値があります。

App Runnerの移行先・代替サービス比較

App Runnerの代替は用途で選び分けます。AWSが公式に後継と位置づけるのはECS Express Modeですが、要件次第では他サービスの方が適します。「App RunnerとECSの違い」で迷う場合も、この表の運用の手間と用途で判断できます。

迷ったらECS Express Modeが第一候補です。App Runnerの手軽さを最も忠実に引き継ぎつつ、必要になればECSの豊富な機能へ地続きで拡張できるためです。ネットワークやサイドカーなど細かな制御が最初から必要ならECS on Fargate、Next.jsなどフロント中心ならAWS Amplify Hosting、リクエスト単位で完結する処理ならLambda、という順で検討します。逆に、常時稼働のHTTPサービスをLambdaへ無理に寄せると起動遅延やタイムアウトで不利になりやすい点は避けたい失敗パターンです。

ECS Express Modeへの移行手順

AWS公式ガイドは、App RunnerとECS Express Modeを同時稼働させ、DNSで少しずつトラフィックを寄せるblue/green方式を推奨しています。無停止で切り替えられ、問題があればDNSの重みを戻すだけでロールバックできるのが利点です。ECS Express Modeとは何か（AWS ECSの新機能）で基礎を押さえたうえで、次の流れで進めます。

コンテナイメージからの移行

既にECRなどにコンテナイメージがある場合は、App Runnerと同じイメージでExpress Modeサービスを作成します。単一のCLIコマンドで、Fargate上のECSサービス・Application Load Balancer・オートスケール・ネットワークまで一括でプロビジョンされます（プロビジョニングは通常3〜5分）。

aws ecs create-express-gateway-service \
  --execution-role-arn arn:aws:iam::123456789012:role/ecsTaskExecutionRole \
  --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRoleForExpressServices \
  --primary-container '{"image":"123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest","containerPort":8080,"environment":[{"name":"ENV","value":"production"}]}' \
  --service-name my-application \
  --health-check-path "/" \
  --scaling-target '{"minTaskCount":1,"maxTaskCount":4}' \
  --monitor-resources

必要なIAMロールはecsTaskExecutionRole（タスク実行用）とecsInfrastructureRoleForExpressServices（Express Modeの基盤プロビジョニング用）の2つです。作成後はデフォルトURLで動作確認し、App Runnerと同じ環境変数・ポート・スケール値を移してから本番トラフィックを寄せます。

ソースコード型からの移行

App Runnerをソースコード連携（ビルドパック自動ビルド）で使っていた場合は注意が必要です。Express Modeはコンテナイメージを前提とするため、リポジトリにDockerfileを追加してイメージをビルドし、ECRへプッシュする工程を挟みます。App Runnerの「pushで自動デプロイ」体験は、GitHub Actions（aws-actions/amazon-ecs-deploy-express-service）を使い、mainブランチへのpushでイメージのビルド・ECRプッシュ・Express Modeへのデプロイを自動化することで再現できます。

Route 53加重ルーティングによる段階移行

カスタムドメインを使っている場合は、Route 53の加重ルーティングで無停止移行できます。同じホスト名に対してApp Runner向けとExpress Mode向けの2レコードを重み付きで用意し、Express Modeの重みを段階的に上げます。AWSの推奨は「Express Mode 10 / App Runner 90」から始め、動作確認しながら25/75→50/50→75/25→100/0と進める手順です。切り替え後もDNS伝播とロールバックに備え、App Runnerサービスは24〜48時間ほど残しておき、問題がなければaws apprunner delete-serviceで削除します。デフォルトURLのみでカスタムドメインが無い場合は共通ホスト名が作れないため、段階移行ではなく新エンドポイントへ切り替える形になります。

App Runnerの料金と移行後のコスト

App Runnerの料金は従量課金で、リクエストを処理する「アクティブインスタンス」のvCPU時間・メモリ時間に加え、待機用の「プロビジョニング済みインスタンス」の低額料金、そしてアウトバウンド転送量で構成されます。ゼロスケール時はアクティブ課金が発生しないため、アイドルの多い小規模サービスではコストを抑えられました。ただし新規顧客はApp Runnerを開始できないため、これから使う場合は移行先の料金で考える必要があります。

移行先のECS Express Modeは、サービス自体への追加料金はなく、裏側で作られるAWSリソース（Fargateのタスク、Application Load Balancerなど）の実費のみを支払う仕組みです。ALBが常時起動する分、極小トラフィックではApp Runnerのゼロスケールより割高になる場合があるため、常時稼働の有無で試算を分けるのが実務的です。料金単価は改定されることがあるため、確定値は必ずAWS公式の料金ページで確認してください。

よくある質問（FAQ）

AWS App Runnerはいつ終了しますか？

完全終了（Sunset／EOL）の日付は未発表です。決まっているのは2026年4月30日以降に新規顧客が利用できなくなり、メンテナンスモードへ移行することだけです。既存サービスがこの日で停止するわけではありません。

既存のApp Runnerサービスは使えなくなりますか？

いいえ。既存顧客は引き続き通常どおり利用でき、新しいApp Runnerサービスやリソースの作成も可能です。AWSは運用・サポート・セキュリティ更新を継続します。ただし新機能の追加は行われません。

App Runnerの代わりに何を使えばいいですか？

AWSはAmazon ECS Express Modeへの移行を推奨しています。App Runnerの手軽さを引き継ぎつつ、ECSの機能セットへ拡張できます。細かな制御が要ればECS on Fargate、フロント中心ならAmplify Hosting、イベント処理ならLambdaも選択肢です。

App RunnerとECSの違いは何ですか？

App Runnerはクラスターやロードバランサーを意識せず数分で公開できる手軽さが強みで、ECSは起動タイプやネットワークを細かく制御できる本格的なコンテナオーケストレーションです。両者の中間として、ECSの上でApp Runner並みの運用の少なさを再現するのがECS Express Modeです。

ソースコード連携のApp Runnerも同じように移行できますか？

Express Modeはコンテナイメージ前提のため、ソース型はDockerfileでのイメージ化が追加で必要です。GitHub Actionsを使えば、pushで自動ビルド・デプロイするApp Runner相当の体験を再現できます。

関連記事

• ECS Express Modeとは何か – AWS ECSの新機能でコンテナデプロイを自動化して容易化する機能
• AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】
• AWS Fargateとは？EC2との違い・料金をわかりやすく解説【2026年版】
• AWS Amplify Hostingとは？料金・特徴とS3+CloudFront/App Runnerとの違い