コンテナ化したWebアプリを手軽にデプロイしたいが、ECSやFargateの設定は手間が多い。AWS App Runnerは、こうした課題に対してAWSが提供するフルマネージドなコンテナ実行サービスです。
ソースコードまたはコンテナイメージを渡すだけで、ビルド・デプロイ・スケーリング・ロードバランシング・TLS終端までをAWSが自動で処理します。2021年5月のリリース以降、VPCコネクタ・WAF連携・IPv6対応などが順次追加され、本番環境でも採用実績が増えています。
AWS App Runnerの基本的な仕組み
App Runnerは内部的にAWS FargateとECSの基盤上で動作しています。利用者がFargateやECSを直接操作する必要はなく、AWSがインフラ層を完全に管理します。
デプロイのソースは2種類あります。
| ソース種別 | 対応リポジトリ・レジストリ | 備考 |
|---|---|---|
| ソースコード | GitHub、Bitbucket | マネージドランタイムで自動ビルド |
| コンテナイメージ | Amazon ECR、Amazon ECR Public | 任意の言語・フレームワークを利用可能 |
ソースコードからデプロイする場合、App Runnerが内部でコンテナイメージをビルドします。対応するマネージドランタイムは以下のとおりです。
- Node.js
- Python
- Java（Corretto）
- .NET
- PHP
- Ruby
- Go
コンテナイメージからデプロイする場合は、言語やフレームワークの制約はありません。Dockerイメージとしてビルドできるものであれば何でも動かせます。
デプロイの流れ
- GitHubリポジトリまたはECRリポジトリを指定
- ビルド設定（ランタイムバージョン、ビルドコマンド、起動コマンド）を構成
- インスタンスのvCPU・メモリサイズを選択
- App Runnerがビルド → デプロイ → HTTPS公開まで自動実行
自動デプロイを有効にすると、ソースコードのプッシュやECRへのイメージプッシュをトリガーに再デプロイが走ります。月額1ドル/アプリケーションの追加費用が発生します。
スケーリングの仕組み
App Runnerのオートスケーリングはリクエスト数ベースです。CPU使用率やメモリ使用率ではなく、同時リクエスト数（コンカレンシー）で判断されます。
設定パラメータは3つあります。
- Max Concurrency: 1インスタンスあたりの最大同時リクエスト数（デフォルト100）
- Max Size: スケールアウト時の最大インスタンス数
- Min Size: トラフィックがなくてもプロビジョニングしておく最小インスタンス数
同時リクエスト数がMax Concurrencyを超えると新しいインスタンスが起動し、トラフィックが減るとMin Sizeまで縮小します。Min Sizeのインスタンスは「プロビジョニング済み」状態として待機し、リクエストが来た際にミリ秒単位で応答を開始します。
料金体系と月額シミュレーション
App Runnerの課金は「アクティブ時」と「プロビジョニング時（アイドル）」で異なります。
リージョン別の単価
| 課金項目 | 米国東部（バージニア北部） | 東京リージョン |
|---|---|---|
| vCPU（アクティブ時） | $0.064 / vCPU時間 | $0.081 / vCPU時間 |
| メモリ（アクティブ時） | $0.007 / GB時間 | $0.009 / GB時間 |
| メモリ（プロビジョニング時） | $0.007 / GB時間 | $0.009 / GB時間 |
| ビルド料金 | $0.005 / ビルド分 | $0.005 / ビルド分 |
| 自動デプロイ | $1.00 / アプリ / 月 | $1.00 / アプリ / 月 |
アイドル状態（プロビジョニング済み）のインスタンスにはvCPU課金が発生せず、メモリ課金のみです。CPUはスロットルされた状態で待機しています。課金単位は1秒単位で、vCPUリソースには最低1分の最低課金があります。
月額料金シミュレーション（東京リージョン）
ケース1: 開発・テスト用アプリ（低トラフィック）
- 構成: 1 vCPU / 2 GB メモリ
- 1日のアクティブ時間: 2時間（それ以外はプロビジョニング状態）
- インスタンス数: 1
| 項目 | 計算 | 月額 |
|---|---|---|
| vCPU（アクティブ） | 0.081 × 1 vCPU × 2時間 × 30日 | $4.86 |
| メモリ（アクティブ） | 0.009 × 2 GB × 2時間 × 30日 | $1.08 |
| メモリ（プロビジョニング） | 0.009 × 2 GB × 22時間 × 30日 | $11.88 |
| 合計 | 約$17.82（約2,700円） |
ケース2: 軽量なAPI（中トラフィック）
- 構成: 1 vCPU / 2 GB メモリ
- 1日のアクティブ時間: 8時間
- プロビジョニングインスタンス: 1
| 項目 | 計算 | 月額 |
|---|---|---|
| vCPU（アクティブ） | 0.081 × 1 vCPU × 8時間 × 30日 | $19.44 |
| メモリ（アクティブ） | 0.009 × 2 GB × 8時間 × 30日 | $4.32 |
| メモリ（プロビジョニング） | 0.009 × 2 GB × 16時間 × 30日 | $8.64 |
| 合計 | 約$32.40（約4,900円） |
ケース3: 本番Webアプリ（高トラフィック）
- 構成: 2 vCPU / 4 GB メモリ
- 1日のアクティブ時間: 12時間、ピーク時に2インスタンスにスケール
- プロビジョニングインスタンス: 1
| 項目 | 計算 | 月額 |
|---|---|---|
| vCPU（アクティブ・1台分） | 0.081 × 2 vCPU × 12時間 × 30日 | $58.32 |
| vCPU（アクティブ・スケールアウト分） | 0.081 × 2 vCPU × 4時間 × 30日 | $19.44 |
| メモリ（アクティブ・全体） | 0.009 × 4 GB × 12時間 × 30日 + 0.009 × 4 GB × 4時間 × 30日 | $17.28 |
| メモリ（プロビジョニング） | 0.009 × 4 GB × 12時間 × 30日 | $12.96 |
| 合計 | 約$108.00（約16,200円） |
※ 日本円は1ドル=150円で換算。実際のレートにより変動します。
App Runnerに無料枠はあるのか
2026年2月時点で、App Runner専用の無料枠は提供されていません。インスタンスが存在する限り、最低でもプロビジョニング状態のメモリ課金が発生します。サービスを「一時停止（Pause）」すれば全課金を停止できるため、使わない期間は一時停止が有効です。
ECS・Fargate・Lambda・Amplifyとの使い分け
AWS内のコンテナ関連サービスは複数あり、用途によって最適な選択肢が異なります。
5サービス比較表
| 比較項目 | App Runner | ECS + Fargate | ECS + EC2 | Lambda | Amplify Hosting |
|---|---|---|---|---|---|
| インフラ管理 | 完全不要 | VPC・サブネット等の設定が必要 | EC2インスタンス管理が必要 | 完全不要 | 完全不要 |
| デプロイ単位 | Webアプリ / API | タスク定義 | タスク定義 | 関数単位 | フロントエンドアプリ |
| スケーリング基準 | 同時リクエスト数 | CPU/メモリ/リクエスト数 | CPU/メモリ | リクエスト数 | CDNベース |
| ゼロスケール | 不可（最小1インスタンス） | Fargate単体では不可 | 不可 | 可能 | — |
| 最大実行時間 | 制限なし（常時稼働） | 制限なし | 制限なし | 15分 | — |
| WebSocket | 非対応 | 対応 | 対応 | API Gateway経由で制限あり | 非対応 |
| VPCリソース接続 | VPCコネクタ経由 | VPC内で直接 | VPC内で直接 | VPC設定で対応 | 非対応 |
| GPU | 非対応 | 対応 | 対応 | 非対応 | — |
| コスト感（低トラフィック） | やや高い | 高い | 中程度 | 安い | 安い |
| コスト感（高トラフィック） | 中程度 | 中程度 | 安い | 高くなりやすい | — |
| 学習コスト | 低い | 高い | 非常に高い | 中程度 | 低い |
選定フローチャート
Lambdaが適するケース:
- リクエスト処理が15分以内に完了する
- トラフィックが不定期でゼロになる時間が長い
- イベント駆動のバッチ処理が中心
App Runnerが適するケース:
- 常時稼働するWebアプリ・APIを手軽にデプロイしたい
- VPC・サブネット・ALBなどのインフラ設計をスキップしたい
- チームにAWSインフラの専門家がいない
- HTTPベースのリクエスト・レスポンス型通信が中心
ECS + Fargateが適するケース:
- ネットワーク構成を細かく制御したい（サービスメッシュ、ALBルール等）
- サイドカーコンテナが必要（ログ収集エージェント、プロキシ等）
- Blue/Greenデプロイやカナリアリリースを厳密に制御したい
- GPUインスタンスが必要
Amplify Hostingが適するケース:
- React / Next.js / VueなどのSPAやSSRフロントエンドアプリが中心
- バックエンドAPIは別サービスで既に存在する
App RunnerはECSに比べて「高い」のか
「App Runner 高い」という検索ワードが一定の検索ボリュームを持っています。結論から言えば、App Runnerの単価自体はFargateとほぼ同等です。「高い」と感じる主な原因は、ゼロスケールができない点にあります。
Fargateでもタスクが1つ動いていれば同程度のコストがかかりますが、ECSはDesired Count=0でタスクを完全に停止できます。App Runnerは最小1インスタンスのプロビジョニング状態が維持されるため、メモリ分の課金が常時発生します。
トラフィックがほぼゼロの時間が長い場合は、Lambdaまたはサービスの一時停止機能を活用するのが費用対効果の高い選択です。逆に、一定量のトラフィックが常時あるアプリケーションでは、App Runnerの運用コスト削減効果がインフラ管理工数の面で大きなメリットになります。
Google Cloud Run・Azure Container Appsとの比較
AWSに限定しない場合、類似サービスとして他社クラウドの選択肢も存在します。
| 比較項目 | AWS App Runner | Google Cloud Run | Azure Container Apps |
|---|---|---|---|
| ゼロスケール | 不可 | 可能 | 可能 |
| 最小課金単位 | 秒（vCPU最低1分） | 100ミリ秒 | 秒 |
| 低トラフィック時のコスト | メモリ課金が常時発生 | ゼロなら$0 | ゼロなら$0 |
| GPU対応 | 非対応 | 対応 | 対応（プレビュー） |
| マルチコンテナ | 非対応 | サイドカー対応 | サイドカー対応 |
| ソースデプロイ | GitHub / Bitbucket | Cloud Source / GitHub / Bitbucket | GitHub / Azure Repos |
| 対応リージョン数 | 11 | 30以上 | 20以上 |
| VPN/プライベート接続 | VPCコネクタ | VPCコネクタ / Serverless VPC Access | VNet統合 |
| カスタムドメイン | 対応（サブ/ルート/ワイルドカード） | 対応 | 対応 |
最大の違いはゼロスケールの有無です。Cloud RunとAzure Container Appsはトラフィックがゼロのとき完全にインスタンスを停止でき、課金もゼロになります。アクセス頻度が低い社内ツールやテスト環境では、この差が月額コストに直結します。
一方、App RunnerはAWSエコシステム（RDS、DynamoDB、SQS、S3など）との連携がスムーズな点で優位性があります。既にAWSを主要なクラウドとして利用しているチームであれば、IAMやVPCコネクタを通じたリソース連携の手軽さが選定理由になります。
VPCコネクタの設定とRDS接続
App RunnerからRDSやElastiCacheなどのVPC内リソースに接続するには、VPCコネクタが必要です。
VPCコネクタの仕組み
App Runnerのコンテナインスタンスは、AWSが管理するVPC上で動作しています。利用者のVPCとは分離されているため、プライベートサブネット内のRDSに直接アクセスできません。VPCコネクタを設定すると、App Runnerのインスタンスから利用者のVPC内のサブネットに対してENI（Elastic Network Interface）が作成され、プライベート通信が可能になります。
設定の注意点
NAT Gatewayが必要になるケース: VPCコネクタを設定するとApp Runnerのアウトバウンド通信がVPCを経由するようになります。そのため、外部API（Stripe、SendGrid、Shopifyなど）への通信にはNAT GatewayまたはVPCエンドポイントが必要です。NAT Gatewayを設置しないと、外部への通信が失敗します。
S3アクセスにはVPCエンドポイントを推奨: VPCコネクタ利用時にS3へアクセスする場合、S3のゲートウェイ型VPCエンドポイントを設定すると、NAT Gateway経由のデータ転送料金を節約できます。
セキュリティグループの設定: VPCコネクタに紐づけるセキュリティグループのアウトバウンドルールで、RDSのポート（MySQL: 3306、PostgreSQL: 5432）への通信を許可します。RDS側のセキュリティグループではApp Runnerのセキュリティグループからのインバウンドを許可します。
VPCコネクタの制限
- 1アカウント・1リージョンあたりVPCコネクタは最大10個
- VPCコネクタ自体に追加料金はなし（AZ間データ転送料は発生）
- VPCコネクタを後から追加・変更可能
WebSocket非対応への対処
App RunnerはWebSocket接続に対応していません（GitHub Roadmap Issue #13で機能リクエスト中）。チャットやリアルタイム通知など双方向通信が必要な場合は、以下の代替手段を検討してください。
- ECS + Fargate + ALB: WebSocketをネイティブにサポートするALBとの組み合わせが最も安定した選択肢です
- API Gateway WebSocket API + Lambda: サーバーレスでWebSocketを実現する場合に有効です
- SSE（Server-Sent Events）の検討: サーバーからクライアントへの一方向プッシュで済む場合、App Runner上でHTTPベースのSSEを利用できる可能性がありますが、接続の長時間保持に関する制約に注意が必要です
「App Runner WebSocket」は検索されやすいキーワードですが、2026年2月時点ではサポートされていないため、WebSocketが要件に含まれる場合はApp Runner以外のサービスを選定すべきです。
App Runnerの制限事項
サービス選定の際に把握しておくべき制限事項をまとめます。
コンピューティング
- vCPU: 0.25〜4 vCPU
- メモリ: 0.5〜12 GB
- GPU非対応
- Linuxコンテナのみ（Windowsコンテナ非対応）
- マルチコンテナ（サイドカー）非対応
スケーリング
- 最小インスタンス数1（ゼロスケール不可）
- オートスケーリング設定は1アカウントあたり10個まで
- 1サービスあたりのインスタンス数上限はサービスクォータで制御
ネットワーク
- WebSocket非対応
- デフォルトポートは8080
- 受信はHTTPS（App RunnerがTLS終端）のみ。TCP/UDPの直接受信は不可
- IPv6はパブリックエンドポイントのみ対応
- カスタムドメインはサブドメイン・ルートドメイン・ワイルドカードに対応
デプロイ
- サービス作成後にソース種別の変更不可（コードベース ↔ イメージベースの切り替え不可）
- ECR Publicイメージからの自動デプロイ非対応
- 別AWSアカウントのECRリポジトリからの自動デプロイ非対応
- サービス名・暗号化設定は作成後に変更不可
サービスクォータ（デフォルト値、引き上げ可能）
| リソース | デフォルト上限 |
|---|---|
| サービス数 | 30 / リージョン |
| オートスケーリング設定数 | 10 |
| 接続数（ソースコード連携） | 10 |
| VPCコネクタ数 | 10 |
| VPCインバウンド接続 | 1 / サービス |
対応リージョン
2026年2月時点で、App Runnerは以下の11リージョンで利用できます。
- 米国東部（バージニア北部 / オハイオ）
- 米国西部（オレゴン）
- アジアパシフィック（東京 / シンガポール / シドニー / ムンバイ）
- 欧州（アイルランド / フランクフルト / ロンドン / パリ）
大阪リージョンには対応していないため、国内の冗長構成を組む場合はシンガポールなど近隣リージョンとの組み合わせを検討する必要があります。
実務での導入判断ポイント
App Runnerを選ぶべきシーン
- プロトタイプの高速立ち上げ: VPCやALBの設計をスキップし、コードを書いたらすぐにHTTPSで公開したい場合
- 社内向けWebアプリ: 大規模トラフィックは不要だが、安定稼働と最低限のセキュリティ（TLS、WAF連携）が求められる場合
- マイクロサービスの一部: 特にインフラの複雑さを増やしたくない小規模なAPIサービス
- インフラ専任者がいないチーム: アプリケーション開発に集中したい2〜5人規模のチーム
- ML推論エンドポイント（GPU不要の場合）: 学習済みモデルをAPIとして公開する用途。GPUが不要な軽量推論であればApp Runnerで手軽にデプロイできます
App Runnerから卒業するタイミング
以下のいずれかに該当する場合は、ECS + Fargateへの移行を検討するタイミングです。
- WebSocketによる双方向通信が必要になった
- サイドカーコンテナが必要になった（ログ収集エージェント、サービスメッシュプロキシ等）
- ネットワーク構成をきめ細かく制御したい（ALBのルーティングルール、複数ターゲットグループ等）
- Blue/Greenデプロイやカナリアリリースを厳密に制御したい
- GPUインスタンスが必要になった
- ゼロスケールを実現してコストを最小化したい（ECS Desired Count=0）
App Runnerはコンテナイメージベースのデプロイに対応しているため、同じDockerイメージをECS + Fargateで動かす形での移行はスムーズに行えます。
まとめ
AWS App Runnerは、コンテナ化されたWebアプリやAPIをインフラ設計なしでデプロイできるフルマネージドサービスです。料金は東京リージョンでvCPU $0.081/時間・メモリ $0.009/GB時間で、低トラフィックの開発用途なら月額3,000円前後から運用できます。
ECS/Fargateとの最大の違いは運用負荷の低さです。VPCやALBの設計が不要なため、アプリケーション開発に集中できます。一方、ゼロスケール不可・サイドカー非対応・GPU非対応といった制約があるため、要件が拡大した場合にはECS + Fargateへの移行パスを考慮しておくことが重要です。
Google Cloud RunやAzure Container Appsと比較するとゼロスケールに対応していない点がコスト面での弱点ですが、AWSサービスとの連携のしやすさやIAMベースのセキュリティモデルは、既にAWSを利用しているチームにとって大きな利点です。