AWS App Runnerは、AWSの2026年3月31日発表でMaintenanceへ移るサービスの一つとして示されました。2026年4月30日以降、新規顧客はApp Runnerへアクセスできない一方、既存顧客は通常利用を続けられます。
この話題で大切なのは、「App Runnerが明日止まる」と読むことではありません。既存サービスを急いで壊さないこと、新規プロジェクトでは別の入口を選ぶこと、移行が必要ならECS Express Modeで何を先に棚卸しするかを分けることです。
3行まとめ
このテーマをもう少し広げて見るなら、Amazon Cognitoがマルチリージョンレプリケーション対応：ログイン基盤のDRで確認すべきこと と Amazon Bedrock AgentCore Identityが既存Secrets Manager参照に対応：AIエージェントの認証情報管理で確認すべきこと も合わせて確認してください。App Runnerから移行先を検討するときに、アプリ本体だけでなくログイン基盤の可用性も合わせて確認するためです。
既存サービスは継続利用でき、AWSの運用とサポートも続きます。まず設定と依存関係を記録します。
2026年4月30日以降の新規顧客はApp Runnerを前提にせず、ECS Express Modeなどを検討します。
コンテナイメージ、IAMロール、ALB、DNS weighted routing、ロールバック方針を先に確認します。
Maintenanceは即停止ではありませんが、新機能追加がない前提で長期計画を見直します。
- AWS App RunnerはMaintenance扱いになり、2026年4月30日以降は新規顧客に開かれていません。既存顧客は新規リソースやサービス作成を含め、通常利用を続けられるとAWSドキュメントで説明されています。
- MaintenanceはSunsetやFull Shutdownではありません。ただしAWSはApp Runnerに新機能を追加する予定はないとしており、新規開発や長期ロードマップでは代替案を見ておく必要があります。
- AWSは移行先としてAmazon ECS Express Modeを案内しています。移行判断では、コンテナイメージ、IAMロール、ALB、DNS weighted routing、カスタムドメイン、基盤リソース課金を先に確認します。
本文の確認日は2026年6月3日です。Amazon Watch JapanはAmazon.com, Inc.および関連会社と提携していない独立サイトであり、この記事は投資助言ではありません。
App Runnerは何が変わったのか
- 2026年3月31日
AWS Service Availability Updatesで、App RunnerがMaintenance対象として示されました。
- 2026年4月30日以降
Maintenance対象サービスは、新規顧客からアクセスできない扱いになります。
- 既存顧客の扱い
既存顧客は新規リソースやサービス作成を含め、通常利用を続けられます。
- 今後の見方
AWSは運用とサポートを続ける一方で、新機能追加は予定していないと説明しています。
既存サービスの継続利用と、新規案件での採用判断は別の論点として読みます。
AWSは2026年3月31日、「AWS Service Availability Updates」として複数サービスや機能の提供条件変更を発表しました。その中で、App RunnerはMaintenanceへ移る対象として列挙されています。
発表の骨子は、Maintenance対象サービスは2026年4月30日以降、新規顧客がアクセスできなくなるというものです。一方で、すでに使っている顧客は継続利用でき、AWSは運用とサポートを続けます。
ここを一文で「App Runner終了」とまとめてしまうと、読者の判断を誤らせます。既存利用者の運用、これからApp Runnerを採用しようとしていた新規案件、将来の移行計画は、それぞれ別の問題です。
既存利用者は通常利用できる
根拠
App Runner個別のavailability changeドキュメントでは、既存のApp Runner顧客は通常どおりサービスを使い続けられると説明されています。そこには、新規リソースや新規サービスの作成も含まれます。
つまり、すでにApp Runnerを使っているチームは、すぐに本番サービスを止める必要があるという読み方ではありません。短期的には、現在の構成を把握し、運用監視、コスト、ログ、ドメイン、証明書、デプロイ手順を再確認する段階です。
注意点
ただし同じドキュメントで、AWSはApp Runnerのセキュリティと可用性への投資は続ける一方、新機能を導入する予定はないとしています。既存運用が安定していても、今後の要件追加をApp Runner上で待つ前提は置きにくくなりました。
新規顧客はApp Runnerを前提にしない
条件
2026年4月30日以降にApp Runnerを使い始める新規顧客は、App Runnerを前提にアーキテクチャを組まない方が自然です。社内テンプレート、Terraformモジュール、CI/CDの標準、PoCの設計書にApp Runnerが残っている場合は、先に前提を見直します。
代替は一つに決まりません。AWSがApp Runner移行先として案内しているのはECS Express Modeですが、要件によっては通常のAmazon ECS on Fargate、AWS Lambda、Elastic Beanstalk、あるいは別のコンテナ基盤が候補になります。
App Runnerに期待していた価値が「コンテナをすばやく公開すること」ならECS Express Modeを最初に見る価値があります。一方、細かいネットワーク制御、既存ECS運用との統合、特殊なスケーリング、イベント駆動の処理が主目的なら、最初から別の選択肢を比較した方が早い場合もあります。
Maintenance、Sunset、Full Shutdownを分けて読む
App RunnerはMaintenanceとして扱われており、Sunset日やFull Shutdownとは別の段階です。
AWSのLifecycle Changesドキュメントでは、サービスや機能の提供条件変更をMaintenance、Sunset、Full Shutdownなどの言葉で整理しています。App Runnerの今回の扱いを読むときは、この用語の違いが重要です。
Maintenanceは、既存顧客が使い続けられる一方で、新規オンボーディングができず、機能追加も行われない段階です。AWSは対象サービスの運用とサポートを続けますが、読者側は代替案の学習と検討を始めるべき状態です。
Sunsetは、既存利用者が代替へ移行する計画を立てる段階です。AWSの説明では、Sunsetサービスには通常、終了までのタイムラインが示されます。Full Shutdownは、サービスや機能がAWSポートフォリオから完全に取り除かれ、利用もサポートもできなくなる段階です。
Maintenanceは「すぐ止まる」ではない
誤読しやすい点
App Runnerについて、現時点で読むべき結論は「すぐ止まる」ではありません。既存顧客は利用を継続できます。運用中の本番サービスを、見出しだけを理由に急いで移し替えるのは危険です。
むしろ最初にやることは、現在のApp Runner利用がどれだけ複雑かを把握することです。独自ドメイン、ACM証明書、環境変数、ヘルスチェック、スケーリング、VPCコネクタ、ログ、CI/CD、障害時の復旧手順が分かっていれば、維持するにも移行するにも判断しやすくなります。
ただし長期の新規開発には向きにくい
評価基準
Maintenanceのもう一つの意味は、新機能を待つ前提でロードマップを組みにくいことです。App Runner上に新しい機能要求を積み上げるより、今後の拡張はECS Express Modeや通常のECS、Lambdaなどで考えた方が、調達、運用、セキュリティレビューの説明がしやすくなります。
既存App Runnerを短期維持し、新規開発はECS Express Modeで始める。あるいは、影響が小さいサービスからECS Express Modeへ段階移行する。こうした分け方が現実的です。
公式発表・発表会カテゴリで追うような一次発表は、What’s New、製品ドキュメント、Lifecycle関連ページで役割が違います。今回も、発表ページだけでなく個別ドキュメントまで見ると、既存利用者の扱いを落ち着いて確認できます。既存App Runner利用者が今日確認すること
初動は移行日を決めることではなく、維持と移行のどちらにも使える情報をそろえることです。
既存利用者がまず持つべき問いは、「いつ移行するか」ではなく、「移行しても維持しても困らない情報がそろっているか」です。App Runner個別ドキュメントの移行手順でも、最初のステップは既存サービス設定の確認です。
最低限、次の項目を棚卸しします。
| 確認項目 | 見る場所 | 移行時に効く理由 |
|---|---|---|
| コンテナイメージ | App Runnerサービス設定、ECR、外部レジストリ | ECS Express Modeはコンテナイメージを使ってサービスを作る |
| アプリケーションポート | App Runnerサービス設定、アプリ設定 | ALBターゲットやヘルスチェックの前提になる |
| 環境変数 | App Runner設定、Secrets管理 | そのまま移すものと見直すものを分ける |
| カスタムドメイン | App Runnerドメイン設定、DNS | DNS weighted routingで段階移行できるかを左右する |
| ACM証明書 | ACM、App Runnerドメイン設定 | ECS Express Mode側で同じホスト名を扱う場合に必要 |
| ヘルスチェック | App Runner設定、アプリのルート | 移行先で正常判定がずれると切り替えに失敗する |
| スケーリング | App Runner設定、実トラフィック | ECS Express Modeのmin/max task数やALB設計に影響する |
| ログと監視 | CloudWatch Logs、アラーム | 移行後の障害比較とロールバック判断に使う |
「維持」と「移行準備」を分ける
条件
App Runnerが既存利用者に閉じられていない以上、すべてのサービスをすぐ移行対象にする必要はありません。短期的には維持でよいサービスもあります。
たとえば、内部ツール、低トラフィックのAPI、要件変更が少ないサービス、独自機能を必要としない小規模アプリは、まず監視と運用手順を確認すれば足ります。逆に、今後VPC、認証、ALB制御、複数サービスの統合、細かいスケーリングが必要になりそうなサービスは、早めに移行候補へ入れるべきです。
ここで大事なのは、移行を「怖い作業」にしないことです。棚卸しをしておけば、半年後に要件が変わったときも、現在の設定を探すところから始めずに済みます。
ソースコードデプロイの利用者は特に注意する
確認項目
App Runnerは、ソースコードから直接デプロイする使い方もできました。ECS Express Modeへ移る場合、ここはそのままではありません。ECS Express Modeはコンテナイメージをデプロイするため、ソースコードデプロイを使っていたチームは、Dockerfileでイメージを作り、ECRなどのレジストリへpushする工程を追加します。
AWSの移行ドキュメントでは、GitHub Actionsでビルド、ECRへのpush、ECS Express Modeへのデプロイをつなげる流れが示されています。App Runnerの自動デプロイ体験を再現したい場合は、GitHub ActionsのOIDC、IAMロール、ECR権限、ECS Express Mode用のロールを先に整えます。
この部分は、単なるサービス選定ではなく開発フローの変更です。アプリのコードよりも、CI/CD、権限、監査、リリース承認の担当者を早めに巻き込んだ方が進めやすくなります。
新規プロジェクトはECS Express Modeをどう見るか
コンテナイメージ、ポート、CPU、メモリ、環境変数、Secrets、公開またはprivate HTTPSの要件を整理します。
ECSサービス、タスク、ロードバランサー、AWS提供ドメインなど、必要な基盤リソースを確認します。
スケーリング、ログ、メトリクス、ヘルスチェック、権限管理が自社の運用に合うかを見ます。
追加料金なしはECS Express Mode機能の追加料金を指し、FargateやALBなどの基盤リソース課金は確認します。
新規案件では、運用の単純さだけでなく、ECSとして管理する範囲と基盤リソースの費用を合わせて判断します。
AWSはApp Runnerからの移行先として、Amazon ECS Express Modeを案内しています。ECS Express Modeは、Amazon ECSでコンテナ化アプリケーションを素早く起動するための機能です。
AWSの発表では、WebアプリケーションやAPIなどのコンテナ化アプリを素早く立ち上げ、運用しやすくすることが狙いとして説明されています。各Express ModeサービスにはAWS提供のドメイン名が割り当てられ、publicまたはprivate HTTPSリクエストを扱い、トラフィックに応じてスケールします。
App Runnerと同じものではありません。ECS Express Modeは、ECSの上で必要なリソースを作る入口です。作られるリソースは自分のAWSアカウント内に残り、要件が変われば直接アクセスして調整できる余地があります。
何を入力し、何が作られるのか
根拠
App Runner移行ドキュメントでは、ECS Express Modeを作るときに、コンテナイメージと2つのIAMロールを渡す形が説明されています。そこから、ECS service on Fargate、Application Load Balancer、ターゲットグループ、ヘルスチェック、auto scaling、security groups、networking、default URLなどが作られます。
これはApp Runnerの「細部を意識せずに公開できる」体験に近い入口です。一方で、ALBやFargateなどのAWSリソースが作られるため、ネットワーク、ログ、コスト配賦、タグ付け、権限設計はECS側の運用として見ます。
資料・確認ログにまとめているような公式ドキュメント確認の流れで、ECS Express ModeのDeveloper Guide、IAMロール、作成されるリソース、削除時の注意点をチーム内で確認しておくと、PoCから本番へ移す判断がしやすくなります。「追加料金なし」をどう読むか
注意点
AWSはECS Express Modeについて、機能そのものの追加料金はないと説明しています。ただし、作られた基盤リソースが無料になるという意味ではありません。Fargate、Application Load Balancer、データ転送、ログ、ECR、Route 53、ACM周辺の利用状況は、通常どおりコスト確認が必要です。
App Runnerでは料金構造が比較的単純に見えていたチームほど、ECS Express Mode移行後のコスト見積もりを早めに出すべきです。ALBが複数サービスで共有される場合もありますが、アプリの構成、トラフィック、リージョン、ログ量で見え方は変わります。
「追加料金なし」は採用を急ぐ合図ではなく、料金比較の入口です。App Runner維持、ECS Express Mode、通常のECS on Fargateを並べ、月額だけでなく運用工数、障害時の調査しやすさ、権限設計、将来拡張まで含めて比べます。
App Runnerから移行するなら最初の論点はDNSとコンテナ
- 1現行設定を確認
App Runnerのサービス設定、ポート、環境変数、IAM、ドメイン、ログを棚卸しします。
- 2コンテナイメージを準備
既存イメージを使うか、ソースコードデプロイからDockerfileとECR pushへ移します。
- 3ECS Express Modeを作成
同じアプリケーションを新しいサービスとして立ち上げ、ヘルスチェックとログを確認します。
- 4ドメインとDNSを設定
カスタムドメイン、証明書、Route 53、weighted routingの設定を確認します。
- 5段階的にトラフィックを移す
少量のトラフィックから始め、エラー率、レイテンシー、ログを比較します。
- 6完了後に削除
十分に確認してから、App Runner側のサービス削除や関連リソース整理を行います。
カスタムドメインがある場合はDNS weighted routingで段階移行しやすく、デフォルトURL運用ではURL変更の影響確認が先になります。
AWSのApp Runner移行ガイドは、blue/green deploymentに近い考え方で、App RunnerとECS Express Modeを同時に走らせながらDNSで段階的にトラフィックを移す流れを示しています。
典型的なステップは、既存App Runner設定の確認、同じコンテナイメージを使ったECS Express Modeサービス作成、必要に応じたカスタムドメイン設定、DNS routingによるトラフィック移行、移行完了後のApp Runnerサービス削除です。
カスタムドメインがあるなら段階移行しやすい
ロールバック条件
App Runnerサービスでapp.example.comのようなカスタムドメインを使っている場合、同じホスト名に対してApp RunnerとECS Express Modeの両方を並行稼働させ、Route 53のweighted routingでトラフィック比率を変える方法が取れます。
最初はApp Runner側の重みを100にし、ECS Express Mode側を小さく始めます。レスポンス、ログ、エラー率、レイテンシ、ヘルスチェックを見ながら比率を上げます。問題が出た場合は、DNSの重みを戻してロールバックします。
Route 53を使っていない場合でも、利用中のDNS providerに同等のトラフィック管理機能があるかを確認します。単純なCNAME切り替えだけだと、段階移行や即時ロールバックが難しくなる場合があります。
デフォルトURLだけで使っている場合は別の注意がある
確認項目
App RunnerのデフォルトURLだけでサービスを公開していた場合、ECS Express Mode側には別のendpointができます。同じホスト名を共有して段階移行する仕組みがないため、クライアント、API呼び出し元、Webhook、監視設定、許可リストを新しいendpointへ移す計画が必要です。
この場合は、移行前に独自ドメインを整備するか、利用者や接続先にendpoint変更を案内するかを選びます。小さな内部ツールなら単純な切り替えで済むこともありますが、外部連携があるAPIでは影響範囲の洗い出しが欠かせません。
移行完了後の削除は最後にする
ECS Express Mode側が本番トラフィックを正しく処理し、十分な確認期間を過ぎたら、App Runner側のweighted recordを削除またはweight 0にし、カスタムドメイン関連付けを外し、不要になったApp Runnerサービスを削除します。
ここで急いではいけません。移行が成功したように見えても、低頻度のWebhook、夜間バッチ、特定リージョンからの通信、古いクライアントだけがApp Runner側を参照していることがあります。ログとDNSの状態を確認してから、不要リソースの削除に進みます。
AWSの移行ドキュメントは、App Runnerサービス削除に加えて、App Runner向けweighted routing record、不要なECRイメージ、App Runner専用IAMロールなどの整理にも触れています。削除はコスト削減のために必要ですが、本番確認より前に行う作業ではありません。
どの読者が急ぐべきか
優先度は、App Runner固有の体験への依存度、新規開発の有無、ドメイン移行の難しさで変わります。
今回のApp Runner変更で、すべての読者が同じ速度で動く必要はありません。優先度は、新規開発があるか、既存サービスがどれだけApp Runner固有の体験に依存しているか、移行難度がどれくらい高いかで変わります。
| 読者タイプ | 優先度 | 最初の行動 |
|---|---|---|
| これからApp Runnerで新規案件を始める予定だったチーム | 高い | ECS Express Modeや通常のECSを前提に設計を見直す |
| ソースコードデプロイに依存している既存利用者 | 高い | コンテナイメージ化、ECR、CI/CD、IAMロールを棚卸しする |
| 独自ドメインで外部向けAPIを運用しているチーム | 中から高 | DNS weighted routing、ACM証明書、ロールバック計画を確認する |
| 低トラフィックで変更予定の少ない内部ツール | 中 | 維持しつつ、設定と削除不可リソースを記録する |
| App Runnerを使っていないAWS利用者 | 低から中 | 社内テンプレートや標準設計にApp Runnerが残っていないか確認する |
急ぐべきなのは新規案件とソースコードデプロイ
評価基準
新規案件でApp Runnerを使うつもりだったチームは、いま設計を直した方が後戻りが少なくなります。アクセスできないサービスを前提に標準化を進めると、PoC、セキュリティレビュー、見積もり、IaCの作り直しが発生します。
ソースコードデプロイを使っている既存利用者も、早めに準備した方がよいグループです。コンテナイメージ化は、Dockerfileを足すだけでは終わりません。ビルド環境、脆弱性スキャン、ECR、IAM、GitHub ActionsのOIDC、デプロイ承認、ロールバック手順まで含めて開発運用の変更になります。
慌てなくてよいが、記録は残す
条件
一方で、App Runner上で安定稼働しており、短期の機能追加を必要としていないサービスは、今すぐ移行しなくてもよい可能性があります。ただし、何も記録しないまま放置するのは避けたいところです。
Maintenanceのサービスは、新しい機能で課題を解決する余地が限られます。将来の担当者が困らないように、現在の設定、利用リージョン、料金、デプロイ手順、連絡先、依存するドメイン、削除してはいけないリソースを残しておきます。
この種の公式発表は、<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月の重要トピックまとめ</a>のような月次ページで継続的に追うと、発表日と実際の運用影響を分けて見やすくなります。
AWSサービス更新を読むときの実務チェック
- 1発表ページを確認
対象サービス、発表日、適用日、新規顧客と既存顧客の扱いを確認します。
- 2個別ドキュメントを読む
availability changeのページで、既存利用、制約、サポート方針、移行先を確認します。
- 3Lifecycle Changesを照合
Maintenance、Sunset、Full Shutdownのどれに当たるのかを確認します。
- 4移行先と料金を見る
Developer Guide、料金ページ、基盤リソースの課金、運用要件を確認します。
対象サービス、日付、既存顧客と新規顧客の扱い、移行先、料金を同じメモに残すと判断がぶれにくくなります。
App Runnerの件は、AWS利用者にとって一つの教訓にもなります。新サービス追加だけでなく、既存サービスのMaintenance、Sunset、Full Shutdownも、アーキテクチャ判断に直結します。
AWSの更新を読むときは、次の順番で見ると混乱しにくくなります。
公式ページを読む順番
確認項目
- 発表ページで、対象サービス、日付、新規顧客と既存顧客の扱いを確認する。
- 個別サービスのavailability changeドキュメントで、移行先、既存利用、制約、サポート方針を確認する。
- Lifecycle Changesで、Maintenance、Sunset、Full Shutdownの意味を確認する。
- 移行先のDeveloper Guideで、実際に作られるリソース、IAM、料金、削除時の注意を確認する。
- 社内のIaC、CI/CD、監視、DNS、証明書、コスト配賦に影響するかを確認する。
社内メモに残す内容
判断材料
ここまで見ると、「ニュースとして知る」から「運用判断に使う」へ変わります。App Runnerの場合、発表ページだけではなく個別ドキュメントまで読むことで、既存利用者は継続できること、ただし新機能追加は見込めないこと、ECS Express Mode移行ではDNSとコンテナ化が焦点になることが分かります。
読了後に更新通知を受け取りたい場合は、<a href="https://amzn-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>でAmazon/AWSの公式発表、サービス更新、月次まとめの更新を追えます。本文の判断材料を置き換えるものではなく、一次情報を見に行くきっかけとして使ってください。
次に読むなら
参照した主な情報源
確認日: 2026年6月3日 Asia/Tokyo。
- AWS: AWS Service Availability Updates
https://aws.amazon.com/about-aws/whats-new/2026/03/aws-service-availability/
- AWS Documentation: AWS App Runner availability change
https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html
- AWS Documentation: AWS Lifecycle Changes
https://docs.aws.amazon.com/general/latest/gr/service-lifecycle.html
- AWS: Announcing Amazon ECS Express Mode
https://aws.amazon.com/about-aws/whats-new/2025/11/announcing-amazon-ecs-express-mode
- AWS Documentation: Create your first Express Mode service using the AWS CLI
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-getting-started.html
- AWS News Blog: AWS Weekly Roundup: AWS DevOps Agent & Security Agent GA, Product Lifecycle updates, and more (April 6, 2026)
https://aws.amazon.com/blogs/aws/aws-weekly-roundup-aws-devops-agent-security-agent-ga-product-lifecycle-updates-and-more-april-6-2026/