AWS App Runner入門｜コンテナWebアプリをサーバー管理ゼロでデプロイする仕組みと料金・ECS Fargateとの使い分けガイド

コンテナをAWSで動かそうとすると、タスク定義・サービス・ターゲットグループ・ALB・IAMロール・セキュリティグループ……と設定項目の多さに圧倒されることがあります。「もう少し手軽に動かしたい」というニーズに応えて2021年に登場したのがAWS App Runnerです。

App RunnerはDockerイメージかGitHubリポジトリを渡すだけで、ロードバランサー・HTTPS・オートスケーリングを含む稼働環境を自動で整えてくれるフルマネージドサービスです。

この記事では、App Runnerの仕組み・料金体系・設定手順を解説し、ECS Fargate・Elastic Beanstalkとの使い分けを整理します。コンテナWebアプリをAWSで素早く本番稼働させたいエンジニア向けの実践ガイドです。

AWS App Runnerとは？ECSやElastic Beanstalkとの違い

App Runnerは、WebアプリケーションとAPIをコンテナで実行するためのフルマネージドサービスです。開発者はアプリのコードとDockerイメージに集中でき、インフラ管理から解放されます。

App Runner登場以前のコンテナ実行サービスを整理すると、以下のとおりです。

・Amazon ECS（EC2起動タイプ）: クラスター・EC2インスタンスの管理が必要。最も自由度が高い反面、設定量が多い
・AWS Fargate: EC2管理が不要になったECS。ただしタスク定義・ALB・IAM設定は自分で行う必要がある
・AWS Elastic Beanstalk: コードをアップロードするだけの簡易PaaS。ただしコンテナ（Docker）との親和性がやや低く、細かいチューニングに限界がある
・AWS App Runner: コンテナ特化のフルマネージドPaaS。Fargateの煩雑さとElastic Beanstalkのコンテナ非親和性を同時に解消

「コンテナ特化のElastic Beanstalk」と表現するとイメージしやすいです。内部的にはFargate上で動作していますが、利用者からは「ソースを渡したら動く」という体験になります。

App Runnerのアーキテクチャと仕組み

1. ソースの指定方法

App Runnerのソースは2パターンから選べます。

・コンテナイメージ（Amazon ECR）: ECRに登録済みのDockerイメージを直接指定する。CI/CDパイプラインでビルド済みのイメージを使う本番ワークフローに最適
・ソースコードリポジトリ: GitHub/Bitbucketのリポジトリを接続し、App Runner側でビルドからデプロイまで実行する。Node.js・Python・Java・Go等に対応。開発初期のプロトタイプに便利

本番環境ではECRイメージの使用が主流です。CI/CDパイプラインでビルドしたイメージをECRにプッシュ→App Runnerが新イメージを自動検出してデプロイ、という流れが作りやすいためです。ECRの基本については「Amazon ECR（Elastic Container Registry）入門」をあわせてご覧ください。

2. App Runnerが自動で整えるもの

App Runnerがプロビジョニングしてくれる要素は次のとおりです。

・HTTPSエンドポイント: xxxxxx.ap-northeast-1.awsapprunner.com 形式のURLが自動発行される（独自ドメインへの紐付けも可能）
・SSL/TLS証明書: ACMと連携して自動発行・自動更新
・ロードバランサー: ALBに相当するレイヤーが内部で動作。複数インスタンスへのリクエスト分散も自動
・オートスケーリング: 同時リクエスト数に応じてインスタンスを自動増減
・ヘルスチェック: HTTPエンドポイントへの定期チェックが標準で有効。不健全なインスタンスは自動的に入れ替え
・ロールバック: デプロイ失敗時は前バージョンに自動ロールバック

オンプレで同等の仕組みを揃えるには、Nginx設定・Let’s Encrypt自動更新・keepalivedによる冗長化・監視スクリプトなど膨大な手間がかかっていたはずです。App Runnerはそれを数分の設定で置き換えます。

3. VPCコネクタ（プライベート接続）

デフォルトではApp RunnerのインスタンスはAWSマネージドVPC上で動作し、パブリックインターネット経由でバックエンドに接続します。自分のVPC内のRDSやElastiCacheに接続するには「VPCコネクタ」の設定が必要です。

VPCコネクタはENIを通じてサブネットに直接接続するため、NAT Gatewayは不要です。RDS側のセキュリティグループでVPCコネクタのセキュリティグループからのインバウンドのみ許可することで、アクセス経路を絞り込めます。

料金の仕組みと試算（2026年時点）

App Runnerの料金は「アクティブ（リクエスト処理中）」と「プロビジョンド（待機中）」の2段階で課金されます。

プロビジョンドインスタンスは「コールドスタートを防ぐための常時起動インスタンス」です。0に設定すると完全従量課金になる代わりに、長時間アクセスがなかった後の初回リクエストで数十秒の遅延（コールドスタート）が発生します。

月額コスト試算例（1 vCPU / 2 GB / プロビジョンド1インスタンス常時起動 / 日中8時間アクティブ / 月30日）

# アクティブ時間の料金（8時間/日 × 30日）
vCPU:   $0.064  × 8時間 × 30日 = $15.36
メモリ: $0.007  × 2GB   × 8時間 × 30日 = $3.36

# プロビジョンド時間の料金（16時間/日 × 30日、1インスタンス）
vCPU:   $0.0064 × 16時間 × 30日 = $3.07
メモリ: $0.0007 × 2GB   × 16時間 × 30日 = $0.67

# 月額合計: 約 $22.5（約3,500円/月、1ドル=155円換算）

小規模APIであれば月数千円で運用できます。ECS Fargateと比較した場合、ALBの固定費（$16/月～）がないため、小規模サービスではApp Runnerが有利なケースが多いです。一方、アクティブインスタンスが常時多数必要な大規模サービスではFargateのほうが割安になる場合があります。

なお、独自ドメイン割り当て自体は無料ですが、リクエスト料金（月100万件超で$0.10/100万件）とビルド料金（ソースコードからのビルド時はビルド時間分の課金）も試算に含めてください。

ECS Fargate・Elastic Beanstalkとの比較と使い分け

使い分けの判断基準は「設定に割ける工数」と「スケール要件」の2軸です。PoCや社内ツール、月間リクエストが少ないAPIであればApp Runner一択です。大規模サービスや複数コンテナのサイドカー構成（ロギングサイドカー、Envoyサイドカー等）が必要なケースはECS Fargateが適切です。

ECS FargateとECS全般については「AWS Fargate入門」と「Amazon ECS入門」を、CI/CDとの連携については「CI/CDとは何か？」をあわせてご覧ください。

ECRイメージからのデプロイ手順

1. IAMアクセスロールの準備

App RunnerがECRからイメージをプルするためのIAMロールが必要です。マネジメントコンソールからサービスを作成する際に「新しいサービスロールを作成」を選ぶと自動で作成されます。事前にCLIで作成する場合は、以下の信頼ポリシーを設定します。

# IAMロールの信頼ポリシー（App RunnerがECRにアクセスするため）
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Service": "build.apprunner.amazonaws.com"
    },
    "Action": "sts:AssumeRole"
  }]
}
# アタッチするマネージドポリシー: AmazonEC2ContainerRegistryReadOnly

2. App Runnerサービスの作成（AWS CLI）

# AWS CLI: App Runnerサービスの作成（ECRイメージ指定）
aws apprunner create-service \
  --service-name my-api \
  --source-configuration '{
    "ImageRepository": {
      "ImageIdentifier": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-api:latest",
      "ImageRepositoryType": "ECR",
      "ImageConfiguration": {
        "Port": "8080"
      }
    },
    "AutoDeploymentsEnabled": true,
    "AuthenticationConfiguration": {
      "AccessRoleArn": "arn:aws:iam::123456789012:role/AppRunnerECRAccessRole"
    }
  }' \
  --instance-configuration '{"Cpu":"1 vCPU","Memory":"2 GB"}' \
  --health-check-configuration '{"Protocol":"HTTP","Path":"/health","Interval":10}' \
  --region ap-northeast-1

3. 独自ドメインの設定

App Runnerが発行するデフォルトのエンドポイントは xxxxxx.ap-northeast-1.awsapprunner.com 形式です。サービス詳細の「カスタムドメイン」タブから独自ドメインを追加できます。Route 53でホストゾーンを管理している場合、必要なCNAMEレコードが自動で追加されます。証明書の発行・検証は数分で完了します。

応用・実務Tips

Tip 1: シークレットの安全な注入
App RunnerはAWS Secrets ManagerおよびSSM Parameter Storeと連携し、シークレット値を環境変数として注入できます。Dockerイメージにパスワードやトークンを埋め込む必要がなく、ローテーションもAWS側で管理できます。

Tip 2: VPCコネクタでRDSに接続する
VPCコネクタを作成する際は「最低2つのサブネット」（マルチAZ推奨）を指定します。RDS側のセキュリティグループに「VPCコネクタのセキュリティグループからのインバウンド許可」を追加することで接続が確立します。

Tip 3: プロビジョンドインスタンスでコールドスタートを防ぐ
夜間など長時間無通信の後にアクセスが来るとコールドスタートが発生します。オートスケーリング設定で「最小インスタンス数」を1以上に設定することで回避できます。追加コストは月数ドル程度です。

Tip 4: デプロイ前のローカル動作確認
App Runnerはコンテナ起動時に CMD または ENTRYPOINT を実行します。ローカルで docker run -p 8080:8080 <image> を実行し、指定ポートでHTTPレスポンスが返ることを必ず確認してからデプロイしてください。起動直後にクラッシュするイメージはデプロイ失敗になります。

よくあるトラブルと対処法

デプロイが「OPERATION_FAILED」になる
サービス詳細の「ログ」タブ→「デプロイメントログ」を確認します。多い原因は①コンテナが指定ポートでHTTPを返さない、②ECRへのIAMアクセス権不足、③コンテナ起動直後にクラッシュ（環境変数の設定漏れ等）の3つです。

VPC内のRDSに接続できない
VPCコネクタが設定されているか確認します。RDS側のセキュリティグループに「VPCコネクタのセキュリティグループ（sg-xxxxxx）からポート5432（またはMySQL 3306）のインバウンドを許可」するルールが追加されているかを見直してください。

初回アクセスが異常に遅い
コールドスタートが原因です。オートスケーリング設定の「最小インスタンス数」を確認してください。0の場合はアイドル後にインスタンスがシャットダウンするため、応答まで30～60秒かかることがあります。

ECRのlatestタグ更新後に自動デプロイされない
App Runnerサービスの設定で「自動デプロイ有効化」がオンになっているか確認します。ECRリポジトリ側の設定ではなく、App Runnerサービス設定内の項目であることに注意してください。

本記事のまとめ

AWS App Runnerは、コンテナWebアプリを最小の設定コストで本番稼働させたいケースに非常に有効です。ALB・SSL証明書・オートスケーリングの設定を省略できるため、開発者の生産性が大きく上がります。

まずはECRにイメージをプッシュして、App Runnerサービスを作成してみてください。設定が完了すればHTTPSエンドポイントが数分で手に入ります。コンテナをAWSで使い始める最初の一歩として、App Runnerは最適な選択肢です。