2026 年 4 月 30 日 ― この日を境に、AWS App Runner は新規受付を停止し、メンテナンスモードへと移行します。既存のサービスが即座に停止するわけではありませんが、「コンテナを一番カジュアルに本番運用できる AWS のマネージドサービス」という立ち位置は、事実上その役割を終えたと考えてよいタイミングです。
同時発表された Amazon RDS Custom for Oracle の 1 年後終了など、AWS はここ数年で「エッジだがエコシステム全体で代替が揃ったサービス」を整理する動きを強めています。2020 年代前半に App Runner を採用した SaaS 事業者・社内ツール・検証環境の運用者は、今この瞬間に「どのくらい時間的余裕があるうちに、どこへ移すか」を決める必要があります。
本記事では、App Runner 撤退の背景と意味を整理したうえで、現実的な移行先として挙がる ECS/Fargate・Google Cloud Run・AWS Lambda（+ API Gateway）・AWS Lightsail Containers の 4 候補を、運用負荷・コスト構造・向いているワークロードの軸で比較します。後半では、実際に移行プロジェクトを進める際の 3 フェーズと、発注側が押さえておくべき見積もりポイントを実務レベルで解説します。
App Runner が担ってきた役割 ― なぜ「消える」のか
App Runner は 2021 年に登場した、コンテナイメージまたは GitHub リポジトリからアプリを即座にデプロイできるマネージドサービスです。Fargate 上に構築されていますが、ユーザーは VPC・クラスタ・サービス・タスク定義などを意識せず、コンテナ 1 つをそのまま HTTPS で公開できました。「ECS/Fargate はハードルが高い」「Lambda だとランタイム制約やコールドスタートで厳しい」といった “コンテナの最短デプロイ” のニーズに応える位置づけでした。
しかし登場から数年を経て、次の 3 つの構造変化が進みました。
- ECS/Fargate 側の UX が大幅改善：ECS コンソールのウィザードと Copilot CLI が揃い、「VPC もロードバランサも全部よろしく」が可能に
- Google Cloud Run の存在感拡大：リクエストベース課金・Pub/Sub 連携・eventarc などで「コンテナ x イベント駆動」の主導権を獲得
- Lambda のコンテナイメージ対応が成熟：10GB までのイメージと snapstart でコールドスタートを改善、マネージド Lambda Web Adapter で HTTP サービスも自然に載せられるように
結果として、App Runner が獲得していた「初心者向けの入り口」「カジュアルな本番運用」「CI/CD が楽」という独自価値は、エコシステム全体に吸収されました。撤退は必然だったと言えます。
メンテナンスモードとは実際何が起きるのか
AWS が「メンテナンスモード」と呼ぶフェーズでは、以下のような扱いになります。
- 新規サービス作成の停止：AWS Management Console および API での新規作成が不可に
- 既存サービスは稼働継続：実行は止まらないが、重要度の低い機能改善は入らない
- セキュリティパッチは提供：深刻な脆弱性には対応される見込み
- 正式な終了日（EOL）は別途アナウンス：経験則で 1〜2 年後が目安
つまり「明日動かなくなる」のではなく、「明確な賞味期限の上で機能が腐っていく」状況です。パスワードリセットのメールが届かなくなったり、新しい AWS リージョンで利用できなかったり、小さな不便が積み重なります。
代替候補 4 つを実務目線で比較する
App Runner から移行する場合、第一候補に上がるのは次の 4 つです。
| サービス | 課金モデル | コールドスタート | VPC / 内部リソース連携 | 運用負荷 | 向いているワークロード |
|---|---|---|---|---|---|
| ECS on Fargate | vCPU 時間 × メモリ | なし（常時稼働可） | VPC ネイティブ | 中 | 常時稼働・複数サービス運用 |
| Google Cloud Run | リクエスト + vCPU 時間 | あり（min-instances で回避可） | VPC コネクタ | 低 | リクエスト駆動・検証環境 |
| AWS Lambda + API Gateway | リクエスト + GB 秒 | あり（SnapStart で緩和） | VPC 選択可 | 低〜中 | イベント駆動・軽量 API |
| AWS Lightsail Containers | 固定月額 | なし | 限定的 | 低 | 小規模・料金予見性重視 |
ECS on Fargate ― App Runner の正統な後継
App Runner は内部で Fargate を使っていたので、「同じレイヤー・より多機能」の後継と捉えられます。
- 強み：AWS 内の他サービス（ALB・CloudFront・Route 53・Secrets Manager など）とシームレスに連携。ECS Copilot CLI や Blueprints for ECS を使えば、App Runner 並みの一発デプロイも実現可能
- 弱み：タスク定義・サービス・クラスタなど抽象レイヤーが 1 段多い。ロードバランサや IAM ロールを明示的に組み立てる必要がある
- コストの目安：常時稼働 0.5 vCPU / 1GB で月 15〜20 USD 程度（Tokyo リージョン）。App Runner の同スペックとほぼ同等
こんなチームに勧めたい：すでに AWS 中心のインフラを持ち、ALB の前段配置や VPC 内部 RDS との連携が必要。CloudWatch や X-Ray での可観測性を活かしたい場合。
Google Cloud Run ― App Runner に最もコンセプトが近い
「コンテナ 1 つを公開するだけ」という DX の近さで言えば、Cloud Run が最も App Runner に近い体験です。
- 強み：リクエスト単位の課金でアイドル時コストが極小。Revision ベースのトラフィック分割でカナリアリリースが標準機能。Eventarc・Pub/Sub との統合で非同期処理にも強い
- 弱み：AWS 内リソース（RDS・S3 など）との連携は VPC Peering や PrivateLink 相当を自前で組む必要あり。マルチクラウドになるのでアクセス管理も 2 系統に
- コストの目安：リクエスト 100 万 / 月 + vCPU 秒 50 万で 5〜10 USD 程度。低トラフィック環境では圧倒的に安い
こんなチームに勧めたい：データベースやストレージも含めて AWS に縛られていない、または新規サービスで GCP 側の BigQuery / Vertex AI を使う予定がある。
AWS Lambda + API Gateway ― 軽量 API なら最適解
アプリが「HTTP リクエストを受けて処理を返す」シンプルな形であれば、Lambda はとても良い選択です。
- 強み：アイドル時の課金ゼロ。SnapStart でコールドスタートを緩和。Lambda Web Adapter で Express / Flask / Django などを最小改修で載せられる
- 弱み：実行時間 15 分上限、メモリ上限 10GB、同時実行数の制御が必要。常時接続 WebSocket はネイティブ非対応（API Gateway WebSocket API 別）
- コストの目安：月 100 万リクエスト・平均 200ms 処理で 1〜3 USD 程度。スパイク性ワークロードには最強
こんなチームに勧めたい：社内ツールやフォーム処理など、リクエスト頻度が読めず、サーバーを常時立てる必要がない場合。
AWS Lightsail Containers ― “分かりやすい固定月額” が欲しいとき
見落とされがちですが、Lightsail にもコンテナ対応があります。
- 強み：月額固定で予算の読みやすさが圧倒的。コンソールが簡素で、インフラ未経験者でも触れる
- 弱み：スケーリング機能が限定的。VPC 統合が弱く、RDS などへのプライベート接続にひと工夫必要
- コストの目安：Nano（0.25 vCPU / 512MB）で月 7 USD。Large でも月 90 USD 程度
こんなチームに勧めたい：社内のランディングページや低トラフィック SaaS。クラウドコストの稟議が厳しく、固定額 で社内を通したいケース。
参考：スタートアップ観点での選択
スタートアップの MVP を開発する場合、「コスト最小化」と「将来の拡張性」のバランスが特に悩ましくなります。弊社がこの 1 年で構築したプロジェクトの傾向としては、スタートアップの MVP 開発費用ガイド でも触れたように、検証期は Cloud Run、スケール期に ECS/Fargate という移行経路が最もコスト効率が良いケースが増えています。さらに、フロントエンドを SSG + CDN に寄せてバックエンドのコンテナ負荷を最小化する Jamstack × ヘッドレス CMS 導入事例 のアプローチと組み合わせると、コンテナの稼働時間自体を圧縮できます。
どう選ぶか ― 3 つの判断軸
4 候補を並べたうえで、実務で効く選び方は次の 3 つの軸で考えると整理しやすくなります。
軸 1：トラフィック特性（常時 vs 突発）
- 常時稼働・定常負荷 → ECS/Fargate または Lightsail
- リクエスト駆動・突発スパイク → Cloud Run または Lambda
App Runner は両方の中間に位置していたため、この軸が最初の分かれ道です。月次の CloudWatch メトリクスから平均 / 最大 / 最小の RPS を取得し、アイドル時間の長さを先に測定しましょう。
軸 2：運用体制（社内スキル × 可観測性）
- AWS 中心の運用チームが存在 → ECS/Fargate
- コンテナ初心者 or ランニング運用人員が薄い → Cloud Run または Lightsail
- オブザーバビリティを CloudWatch / X-Ray で統一したい → ECS/Fargate または Lambda
AI エージェントを運用支援に組み込む構想があるなら、AWS DevOps Agent マルチクラウド対応の解説のとおり、AWS 外（GCP 含む）のリソースも監視対象に取れる時代になりました。「AWS に閉じる必要性」は以前より下がっています。
軸 3：コストの予見性
- 固定額で経理処理したい → Lightsail Containers
- 従量課金だが絶対額を最小化 → Cloud Run または Lambda
- スペックを上げて安定性重視 → ECS/Fargate
移行の最大の失敗は「移行先で想定外にコストが跳ねる」ことです。必ず移行元 30 日の請求書を基準値に、移行先の料金シミュレーターで 2〜3 シナリオの試算を行ってください。
移行プロジェクトの進め方 ― 3 フェーズで安全に
App Runner からの移行は、技術的な置き換えだけでなく 運用プロセスの移し替え を含むプロジェクトです。次の 3 フェーズで進めると破綻しません。
フェーズ 1：評価（1〜2 週間）
- 現行 App Runner サービスの棚卸し：サービス数、CPU / メモリ設定、接続先リソース、CI/CD のフック、カスタムドメイン・証明書
- 移行候補の選定：上記 3 軸で 4 候補のうち第一・第二候補を決定
- リスク評価：DB 接続、固有 IP 要件、Cold Start 許容度、ログ保管要件
評価フェーズの成果物は、A4 1〜2 枚の「現行構成図 × 移行先構成図」で十分です。ここで迷っているサービス（例：月末だけ利用されるバッチ系）は第二候補扱いにして、後回しにします。
フェーズ 2：設計・構築（2〜4 週間）
- IaC 化：Terraform か AWS CDK でインフラをコード化。移行先を手動構築すると、次の EOL 時にも同じ苦労を繰り返します
- CI/CD の再設計：GitHub Actions なら公式の OIDC 連携でシークレット不要の運用へ
- ステージング環境の並走：App Runner と新環境を 1〜2 週間並走させ、アプリケーションログと応答時間を比較
特に注意したいのが、App Runner 独特の 環境変数管理（設定は Auto scaling 単位） と ヘルスチェックのパス / 間隔。移行先で同じ挙動を再現できないと、最初のデプロイでアラート地獄になります。
フェーズ 3：切替・撤去（1〜2 週間）
- DNS 切替：Route 53 の加重ルーティングで 10% → 50% → 100% と段階的に
- モニタリング期間：最低 1 週間の並走 + 2 週間の観察期間
- 旧環境の撤去：App Runner サービスの削除と、ACM / Route 53 の関連レコード整理
新旧 2 系統を持つ期間のコストは発生しますが、「即 100% 切替で問題発覚 → 巻き戻し」のダウンタイム損失に比べれば、安い保険です。
よくある落とし穴 3 つ
- ヘルスチェック仕様の違い：App Runner のデフォルトは
/への TCP チェック。ALB や Cloud Run は HTTP コードの詳細を見るため、アプリ側で/healthzを実装し直す必要があります - CI/CD の権限設計漏れ：GitHub Actions の OIDC 設定を忘れて、アクセスキーを Secrets に埋め込んだまま放置されるケースが多い。こうした CI/CD 経路の放置は、2026 年サプライチェーン攻撃まとめ で整理した依存ライブラリ経由の事故と並ぶ、移行プロジェクトで典型的なセキュリティ負債です。移行の機会に CI/CD 権限を最小権限・短命トークンへ作り直すことを推奨します
- ログ・メトリクスのフォーマット：CloudWatch Logs と GCP Cloud Logging で構造化ログの JSON キーが微妙に違う。ダッシュボード再構築の工数を見積もりに必ず計上する
まとめ ― 2026 年中に動いた方がいい 3 つの理由
AWS App Runner は 2026 年 4 月 30 日で新規受付を停止し、ECS/Fargate・Google Cloud Run・AWS Lambda・Lightsail Containers のいずれかへの移行が必要になります。
急ぐべき理由は 3 つあります。
- 機能が更新されなくなる：新しい AWS リージョンや、深いエコシステム連携の恩恵を受けられない
- 人材市場の観点：「App Runner 運用経験」は数年後に採用要件として機能しなくなり、若手エンジニアの興味も離れる
- 移行プロジェクトは常に想定より時間がかかる：4〜6 週間のプロジェクトで計画し、余裕を持って完了させるのが 2026 年後半までの現実的な目安
弊社 GleamHub では、App Runner から ECS/Fargate・Cloud Run への移行プロジェクトを、現行構成のヒアリング → アーキテクチャ設計 → IaC 化 → CI/CD 構築 → 切替運用まで をワンストップで支援しています。同時に、Amazon S3 Files が変える中小企業のファイル管理で取り上げた、ストレージ層のクラウド化も含めた全体最適の提案が可能です。
「まだ動いているからそのままで」が一番コストの高い選択になる前に、評価フェーズだけでも着手することを強くお勧めします。
