AWS App Runner 新規受付停止後の PHP / FrankenPHP 移行先比較

TL;DR

AWS App Runner は既存顧客向けには継続利用できるが、新規顧客受付停止と新機能追加停止により、長期運用では移行先検討が必要になった
PHP / FrankenPHP の移行先は ECS Fargate、Cloud Run、Lambda + Lambda Web Adapter の 3 候補で比較すると判断しやすい
FrankenPHP worker mode を活かすなら、常時起動タスクとして扱える ECS Fargate が最も素直な移行先になる
Cloud Run は起動速度、Lambda は低トラフィック時のコストに強いが、AWS 内統一性と worker mode との相性では譲る

概要

AWS App Runner の availability change を受けて、PHP / FrankenPHP アプリの移行先を比較した case-study です。App Runner がただちに使えなくなるという話ではなく、「新規受付停止 + 新機能追加停止」の状態をどうリスクとして扱うかを整理します。

対象読者は、App Runner 上で PHP / Laravel / FrankenPHP コンテナを運用している開発者、または ECS Fargate / Cloud Run / Lambda のどれを移行先にするか迷っているインフラ担当者です。

目次

状況 / 課題
候補 / トレードオフ
採用案と理由
実装抜粋
運用上の学び
振り返り
まとめ
参考

状況 / 課題

2025年8月、AWS は App Runner に重大なアナウンスを出した。

"Following the End of Life (EOL) declarations by their official providers or community, AWS App Runner will set the status of the following managed language runtime versions to End of Support ... PHP: 8.1 — End of Support on December 31, 2025"
— AWS App Runner Release Notes, August 28, 2025

さらに 2026 年 4 月 30 日以降、App Runner は新規顧客の受付を停止した。

"After careful consideration, we decided to close AWS App Runner to new customers. Existing AWS App Runner customers can continue to use the service as normal, including creating new resources and services. AWS continues to invest in security and availability for AWS App Runner, but we do not plan to introduce new features."
— AWS App Runner 公式ドキュメント「Availability change」

つまり App Runner は機能追加なしのメンテナンスモードに入った。PHP 8.1 の EOS (2025-12-31) を境に、新しい PHP バージョンのマネージドランタイムも提供されない。FrankenPHP や PHP-FPM を App Runner のコンテナとして動かしているチームは、遅かれ早かれ移行を強いられる。

項目	内容
ワークロード特性	Laravel / FrankenPHP による Web API、同期リクエスト中心
SLA / 可用性	99.9% 以上
コスト制約	App Runner 比で大幅増なら NG
期限	PHP 8.1 EOS (2025-12-31) に先行して移行完了

候補 / トレードオフ

候補 A: ECS Fargate (ECS Express Mode)

特徴: AWS が App Runner の公式移行先として推奨するマネージドコンテナサービス。ECS Express Mode を使えば App Runner に近い簡便さで Fargate + ALB を一括構築できる
長所:
- AWS 公式推奨パス。移行ドキュメントと GitHub Actions Action が整備済み
- FrankenPHP コンテナをそのままデプロイ可能
- ALB + Auto Scaling + VPC ネットワーキングがフルマネージド
- WebSocket 対応 (ALB の Upgrade header pass-through)
短所:
- Fargate タスクの起動に 30〜90 秒かかることがある (Cold Start が遅い)
- Cloud Run や Lambda に比べてアイドル時のコストが高い
- IaC (Terraform / CDK) の設定量が多い

# ECS Express Mode での一括デプロイ例
aws ecs create-express-gateway-service \
  --execution-role-arn arn:aws:iam::ACCOUNT_ID:role/ecsTaskExecutionRole \
  --infrastructure-role-arn arn:aws:iam::ACCOUNT_ID:role/ecsInfrastructureRoleForExpressServices \
  --primary-container '{
    "image": "ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest",
    "containerPort": 8080
  }' \
  --service-name "my-frankenphp-app" \
  --scaling-target '{"minTaskCount":1,"maxTaskCount":4}'

見積コスト: App Runner と同等〜1.2x（タスク数に依存）

候補 B: Google Cloud Run

特徴: GCP のサーバーレスコンテナサービス。リクエストベースの課金でアイドル時コストが低く、Cold Start が ECS Fargate より高速
長所:
- Cold Start が数百ms〜2秒程度 (FrankenPHP の worker mode と相性が良い)
- gcloud run deploy 1 コマンドで完結
- HTTP/2 gRPC 対応、マネージド TLS
- リクエストがない間は課金ゼロ (min-instances=0 の場合)
短所:
- AWS 環境から GCP への移行はネットワーク・IAM・監視設定の全面見直しが必要
- WebSocket は Cloud Run でもサポートされているが、セッション管理は注意が必要
- AWS 他サービス (RDS / SQS / S3) との連携にレイテンシが生じる
見積コスト: アイドル時間が長いワークロードなら App Runner 比で 0.5x〜0.8x

候補 C: Lambda + Lambda Web Adapter

特徴: AWS Lambda に通常の HTTP サーバーを乗せるアダプター層。FrankenPHP / PHP-FPM コンテナを Lambda に持ち込める

"A tool to run web applications on AWS Lambda. Developers can build web apps with familiar frameworks...and run it on AWS Lambda. The same docker image can run on AWS Lambda, Amazon EC2, AWS Fargate, and local computers."
— AWS Lambda Web Adapter README (aws/aws-lambda-web-adapter)

長所:
- リクエスト単位の完全なサーバーレス課金
- 既存の FrankenPHP コンテナに adapter レイヤーを 1 行追加するだけ
- 同一イメージを ECS Fargate / ローカルでも動かせるポータビリティ
短所:
- FrankenPHP の worker mode (プロセス常駐型) との相性はウォームコンテナ再利用時は恩恵を受けられるが、コールドスタート時はプロセス初期化が走る。また Lambda の並行実行モデルはコンテナ 1 インスタンスあたり 1 リクエストのため、worker mode が想定する「常駐 1 プロセスで多数のリクエストを多重処理」とは設計思想が異なる
- WebSocket 非対応 (API Gateway の WebSocket API は別建てが必要)
- 実行時間 15 分制限が長時間処理の障壁
見積コスト: 低トラフィック帯では最安だが、高スループット帯ではリクエスト課金が逆転する

比較表

観点	ECS Fargate (Express)	Cloud Run	Lambda + LWA
起動速度	30〜90 秒 (新タスク)	500ms〜3 秒	100ms〜1 秒
Cold Start	遅い	中程度	速い
コスト感	中 (アイドル課金あり)	低〜中 (アイドル無料)	最低 (低負荷時)
WebSocket 対応	○ (ALB pass-through)	○	△ (別建て要)
FrankenPHP worker mode 相性	◎	○	△
AWS 内統一性	◎	△ (GCP 移行コスト大)	◎
公式移行ドキュメント	◎ (App Runner 公式)	自前調査	◎ (LWA 公式)

採用案と理由

採用: ECS Fargate (ECS Express Mode)

理由:

AWS 公式の推奨移行パス。App Runner 公式ドキュメントに Route 53 weighted routing を使った blue/green 移行手順が詳述されており、運用リスクが最小
FrankenPHP worker mode との相性。FrankenPHP は常駐プロセスでリクエストをさばく設計 ("Boot your application once and keep it in memory. FrankenPHP will handle incoming requests in a few milliseconds." — FrankenPHP 公式ドキュメント)。Fargate は常時稼働タスクとして動かすため、この恩恵をフルに受けられる
AWS エコシステムの継続性。RDS / SQS / S3 との連携設定を最小変更で維持できる

GCP Cloud Run は Cold Start 優位性があるが、AWS 移行の主目的はリスク分散よりコスト効率と安定性のため、今回のスコープ外とした。Lambda + LWA は worker mode 非活用になるため FrankenPHP のメリットを半減させる。

実装抜粋

# FrankenPHP + Laravel Octane コンテナ (ECS Fargate 向け)
FROM dunglas/frankenphp:latest-php8.3

WORKDIR /app

# .dockerignore で .env / .git / vendor を除外しておくこと
# レイヤーキャッシュを活用: 依存関係を先にインストールしてからソースをコピー
COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts --no-autoloader

COPY . .
RUN composer dump-autoload --optimize

# 非特権ユーザーで実行 (セキュリティベストプラクティス)
USER www-data

# Laravel で Worker Mode を有効にするには Laravel Octane が必要
# php artisan octane:install --server=frankenphp で導入済みであること
EXPOSE 8080

CMD ["php", "artisan", "octane:frankenphp", "--host=0.0.0.0", "--port=8080"]

# ECS タスク定義 (抜粋)
containerDefinitions:
  - name: frankenphp
    image: ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest
    portMappings:
      - containerPort: 8080
        protocol: tcp
    environment:
      - name: APP_ENV
        value: production
    logConfiguration:
      logDriver: awslogs
      options:
        awslogs-group: /ecs/my-frankenphp-app
        awslogs-region: ap-northeast-1

運用上の学び

Fargate タスクの起動時間対策: minTaskCount: 1 で常時 1 タスク以上を起動しておくことで Cold Start の影響を受けるのはスケールアウト時のみに限定できる。App Runner と同様のゼロ to hero は捨て、常時起動コストを許容するトレードオフ
Laravel で FrankenPHP Worker Mode を使うには Laravel Octane が必須: FRANKENPHP_CONFIG="worker ./public/index.php" の直接設定では Laravel の状態リセットが行われず、リクエスト間で静的変数・サービスコンテナが汚染される。composer require laravel/octane → php artisan octane:install --server=frankenphp で Octane を導入し、起動コマンドは php artisan octane:frankenphp を使うこと (Laravel Octane 公式ドキュメント)
FrankenPHP worker mode の注意点: Worker mode では静的変数・クラス静的プロパティ・グローバル変数がリクエストをまたいで持続する ("the following state persists across requests: Static variables, Class static properties, Global variables, In-memory caches" — FrankenPHP 公式ドキュメント)。Octane 導入後も独自のシングルトンやグローバル状態は octane:start のライフサイクルフックでリセットする設計にする
Fargate コスト最適化と Graceful Shutdown: Graviton (ARM64) アーキテクチャで同等スペックを約 20% 削減できる。Fargate Spot は最大 70% 削減だが、同期 Web API で Spot をメインにすると中断時に ALB 503 が発生する。ベースラインはオンデマンドタスクで確保し、スケールアウト分を Spot にするのが現実的。ECS のスケールイン・デプロイ時は SIGTERM が送信されるため、タスク定義の stopTimeout: 60 (秒) を設定して Worker Mode 処理中リクエストの安全な終了を担保する
機密情報の扱い: タスク定義の environment に DBパスワードや APP_KEY・APIキーを平文で書かない。AWS Secrets Manager または Parameter Store (SecureString) を利用して secrets ディレクティブ経由で注入すること
ヘルスチェックパスの設定: ALB のヘルスチェックには Laravel 11 の /up エンドポイントを使う (health-check-path: /up)。/ を使うと DB 未接続などのエラーが返りタスクが強制停止するリスクがある
移行コストの過小見積もりに注意: App Runner → ECS Express Mode は UI 上は簡単だが、VPC サブネット設計・セキュリティグループ・ALB のヘルスチェックパス設定など細かい作業が積み上がる。1 日では終わらない前提でスケジュールを引くべきだった

振り返り (ディレクター視点)

判断時に重視した軸: AWS 公式の移行推奨先であること、FrankenPHP の worker mode をフル活用できること、既存 AWS エコシステムとの整合性
どこを譲歩したか: Cold Start の速さ。Cloud Run の方が Cold Start は速いが、AWS 内統一性と移行コストの低さを優先して Fargate を選んだ
もう一度判断するなら: Lambda + LWA の「コンテナポータビリティ」は魅力的。ただし FrankenPHP の worker mode を採用する前提ならば Fargate 選択は変わらない

まとめ

AWS App Runner は PHP 8.1 EOS (2025-12-31) を境に新機能追加なしのメンテナンスモードに入っており、実質的な移行期限がある
AWS 公式推奨の移行先は ECS Express Mode (ECS Fargate)。1 API コールで App Runner 相当のスタックを構築でき、Route 53 weighted routing による段階移行もドキュメント化されている
FrankenPHP の worker mode は「一度起動してメモリに常駐し、ミリ秒単位でリクエストをさばく」設計であり、Fargate の常時稼働タスクと最も相性が良い
Cloud Run は Cold Start 優位だが AWS との連携コストが増す。Lambda + LWA は低トラフィック帯で最安だが FrankenPHP worker mode の恩恵が薄れる

参考

公式 1 次資料

関連 issue / リリースノート

補足解説