AWS App Runner: 現在の状況、料金、代替手段
AWS App Runner は新規顧客の受付を終了しましたが、既存のサービスは引き続き稼働しています。 AWS は新規顧客の受付終了日を 30 April 2026 に設定し、コンテナ化されたアプリケーションには Amazon ECS Express Mode を推奨しています。すでに App Runner を利用している場合は、本番トラフィックを移す前に要件と移行先の選択肢を評価してください。AWS の告知。
Lizard が公開したこのガイドでは、9 September 2026 時点の製品状況と関連する料金ソースを確認しています。この案内では、方針変更とサービス終了を区別しています。発表では、既存のサービスが受付終了日に停止しなければならないとは書かれていません。
App Runner の機能
App Runner は、対応するソースリポジトリまたはコンテナイメージから HTTP サービスまでを管理された形で提供します。ルーティングやサービスのスケーリングといったインフラ作業を処理します。一方で、アプリケーション側では引き続き、データベース接続、シークレット、ヘルスチェック、リリースプロセスが必要です。
既存ユーザーにとっての価値は、すでに構築済みのワークフローにある場合があります。AWS アカウントには、そのサービスを取り巻くレジストリ、データベース、権限、ネットワークが存在しているかもしれません。コンピュート層だけを置き換えても、それらの依存関係まで置き換わるわけではありません。
現在のサポート方針を理解する
AWS はセキュリティと可用性への投資は継続すると述べていますが、App Runner の新機能は予定していません。新規顧客として利用開始が必要な新しいアプリケーションには、別の手段が必要です。既存ユーザーは、移行を計画する前に、自分のアカウント、要件、AWS のガイダンスを確認する必要があります。
これを Heroku の製品方針変更と混同しないでください。どちらもホスティングの見直しのきっかけになり得ますが、方針は異なります。
App Runner の課金の仕組み
App Runner では、プロビジョニング済み容量とアクティブ容量を区別します。サービスは、トラフィックを待機している間もプロビジョニング済みメモリの料金が発生することがあります。アクティブなコンピュート、ソースビルド、その他の AWS リソースでも料金が加算される場合があります。正確な単価はリージョンと設定によって異なります。App Runner の料金。
見積もりでは、項目を分けてください。
| Input | Why it matters |
|---|---|
| リージョンとサービス設定 | 適用される単価とリソースサイズを決定します |
| プロビジョニング済みメモリと課金時間 | リクエスト待機中が必ずしも無料とは限りません |
| アクティブなコンピュートと継続時間 | トラフィックによってコンピュート使用量が発生します |
| スケーリング動作 | 複数のアクティブインスタンスがあると、合計リソース量が増えます |
| ソースビルドとデプロイオプション | ビルド料金はランタイムとは別です |
| データベース、ネットワーク、ログ | これらは AWS の請求書の別項目に現れる場合があります |
各リソースのメーターを確認せずに、すべてを丸 1 か月分で掛け算するのは避けてください。また、リクエスト数が 0 だからといってアイドル時のコストを 0 にしないでください。AWS の料金例は、計算式にどの項目を含めるべきか確認するのに役立ちます。
どの置き換え先を評価すべきか
| オプション | 含める理由 | What changes |
|---|---|---|
| ECS Express Mode | AWS が App Runner からの推奨移行先として挙げています | 作成される ECS リソース、権限、ネットワークを確認してください |
| ECS with Fargate | AWS 内でタスクをより直接的に制御できます | デプロイとサービス設定をより多く自分で管理します |
| Cloud Run | HTTP コンテナ向けのマネージドなワークフローです | クラウドアカウント、ID、ネットワーク、周辺のデータサービスが変わります |
| Lizard | 一般的な Web サービス、ワーカー、マネージドなデータサービス | 設定、デプロイワークフロー、AWS 外へ移すデータがあればその移行 |
| Railway または Render | 複数サービスのアプリケーション向けマネージドワークフロー | リソースモデル、請求、統合が変わります |
ECS Express Mode はセットアップ作業を減らせますが、それでもアカウント内で作成されるリソースとコストを理解する必要があります。App Runner 相当の請求額だと決めつけるのではなく、まず AWS の関連する 移行ガイダンス と Fargate の料金 を確認してください。
より広く選択肢を比較するには、PaaS providers を参照してください。イメージのパッケージングとランタイムの挙動の違いについては、container as a service を参照してください。
データベースの判断は分けて考える
HTTP サービスを移すときに、同時にデータベースまで移す必要はありません。データベース接続の安全性を保てて、レイテンシが許容範囲なら、先に新しいランタイムをテストできます。プロバイダー間またはリージョン間のトラフィックは、レイテンシとコストの両方を変える可能性があります。
データベースも移行する場合は、拡張機能、ロール、接続数制限、リストア時間をテストしてください。単に import コマンドが完了したかではなく、アプリケーションレベルの読み書きを確認してください。切り替え中の書き込みをどう扱うか、新しいアプリが失敗した場合にどう復旧するかを決めておいてください。
確認項目を明確にした移行手順
- イメージまたはソースのリビジョン、ランタイム設定、IAM 依存関係、シークレット、接続先サービスを記録します。
- 候補のホスト上に分離されたテスト用コピーをデプロイします。想定するポートとヘルスエンドポイントを設定します。
- テストデータを接続し、重要なフローを実行します。ログイン、書き込み、ファイル処理、各種コールバックを確認します。
- レイテンシ、スケーリング、エラーを観測できる程度に負荷試験を行います。実際のメーターから請求額を見積もります。
- 最終的なデータとトラフィックの切り替えを準備します。証明書とドメインの確認、監視、ロールバック判断の時点を含めてください。
Lizard では、Git デプロイガイド でソースデプロイを扱っており、設定リファレンス では再現可能な設定を説明しています。アプリにバックグラウンド処理もある場合は、Web プロセスに無理に押し込まず、別のワーカーとして設定してください。
FAQ
AWS App Runner は終了しましたか? 一般的なサービス終了は、引用した告知では示されていません。AWS は新規顧客を制限しつつ、既存サービスの運用を継続しており、セキュリティと可用性に関する対応も継続しています。
AWS は代わりに何を推奨していますか? AWS は ECS Express Mode を挙げています。切り替える前に、アプリのネットワーク、権限、デプロイ要件と照らし合わせて評価してください。
アイドル状態の App Runner サービスには料金がかかりませんか? そうとは限りません。プロビジョニング済みメモリは課金対象のままである可能性があります。自分のリージョンに対する料金ページの、プロビジョニング済みとアクティブの各項目を使ってください。
アプリケーションだけ移行できますか? はい、既存の依存先に安全に到達できるなら可能です。その構成を本番運用で維持する前に、ネットワーク経路、レイテンシ、転送料金をテストしてください。
Lizard はそのまま置き換えられますか? 一般的なアプリケーションサービスは実行できますが、設定、クラウド固有の統合、データアクセスは引き続き確認が必要です。トラフィックを移す前に、まずコピーでテストしてください。
AI で構築。Lizard で公開。
本番公開にプラットフォームチームは必要ありません。クラウド全体が、1 つの CLI コマンドですぐ使えます。
- ワークスペース
- —
- サービス
- —
- アドオン
- —
- デプロイ
- —