コンテナデプロイの簡素化 - AWS App Runner で実現するゼロ設定デプロイ

App Runner の位置づけとコンテナデプロイの課題

コンテナ化された Web アプリケーションを AWS にデプロイする場合、従来は ECS (Elastic Container Service) や EKS (Elastic Kubernetes Service) を使用するのが一般的でした。しかし、これらのサービスはクラスター管理、タスク定義、サービス定義、ロードバランサー、ターゲットグループ、セキュリティグループなど多数のリソースを設定する必要があり、インフラの知識が求められます。AWS App Runner は 2021 年にリリースされたフルマネージドのコンテナアプリケーションサービスで、これらの複雑さを完全に抽象化します。ソースコードリポジトリ (GitHub) またはコンテナイメージ (ECR) を指定するだけで、ビルド・デプロイ・スケーリング・ロードバランシング・ TLS 終端のすべてを App Runner が自動的に処理します。開発者はアプリケーションコードに集中でき、Dockerfile さえあればインフラの知識なしに本番環境へデプロイできます。なお、App Runner は新規顧客向けの受付を終了しており、既存顧客のみ継続利用できます (2026 年 8 月時点)。新規のコンテナデプロイでは ECS (Express Mode) などが受け皿になります。

デプロイ方法とソース設定

App Runner は 2 つのソースタイプをサポートします。1 つ目はコンテナイメージソースで、ECR (パブリックまたはプライベート) のイメージを指定します。ECR へのイメージプッシュを検知して自動デプロイする設定も可能です。2 つ目はソースコードリポジトリで、GitHub リポジトリを接続し、App Runner がビルドからデプロイまでを一貫して実行します。マネージドランタイムを選択すれば、buildspec.yml 不要でビルドコマンドと起動コマンドを指定するだけで動作します (対応ランタイムは次節で扱います)。

# CloudFormation での App Runner サービス定義
Resources:
 AppRunnerService:
 Type: AWS::AppRunner::Service
 Properties:
 ServiceName: my-web-app
 SourceConfiguration:
 AuthenticationConfiguration:
 AccessRoleArn: !GetAtt AppRunnerAccessRole.Arn
 AutoDeploymentsEnabled: true
 ImageRepository:
 ImageIdentifier: !Sub '${AWS::AccountId}.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest'
 ImageRepositoryType: ECR
 ImageConfiguration:
 Port: '8080'
 RuntimeEnvironmentVariables:
 - Name: NODE_ENV
 Value: production
 InstanceConfiguration:
 Cpu: '1024'
 Memory: '2048'

インスタンス設定では vCPU (0.25 / 0.5 / 1 / 2 / 4) とメモリ (0.5 〜 12 GB) を組み合わせて選択します。ECS Fargate のようにタスク定義・サービス定義・ ALB ・リスナー・ターゲットグループを個別に設定する必要がなく、1 つのリソース定義でデプロイが完結します。

GitHub 連携とソースコードデプロイの実践

ソースベースデプロイでは GitHub リポジトリを接続し、App Runner がコードから自動的にコンテナイメージをビルドしてデプロイします。対応するマネージドランタイムは Python、Node.js、Java (Corretto)、Go、.NET、PHP、Ruby など複数用意されており、いずれかを選択すると Dockerfile を書かずにデプロイが完了します。ランタイムのバージョンは追加とサポート終了が随時あるため、着手時に公式ドキュメントで現行の対応状況を確認してください。リポジトリのルートに apprunner.yaml を配置することで、ビルドコマンド、起動コマンド、ランタイムバージョン、環境変数を宣言的に定義でき、インフラ設定をコードと一緒にバージョン管理できます。GitHub 連携では自動デプロイと手動デプロイを選択できます。自動デプロイを有効にすると、指定ブランチへの push を検知してビルドとデプロイが自動実行され、CI/CD パイプラインを別途構築する必要がありません。手動デプロイを選択した場合はコンソールまたは API から明示的にデプロイをトリガーします。自動ビルドの料金は 1 分あたり 0.005 USD で、頻繁な push を行うリポジトリではビルド料金が蓄積する点に注意が必要です。加えて、自動デプロイを有効にしたアプリケーション 1 つあたり月 1 USD の固定料金がかかります (2026 年 8 月時点・東京リージョン)。

カスタムドメインとオブザーバビリティ

カスタムドメインの設定はコンソールからドメイン名を入力し、DNS プロバイダー (Route 53 または外部 DNS) に CNAME レコードを追加するだけで完了します。ACM (AWS Certificate Manager) 証明書が自動的に発行・更新され、設定した独自ドメインで HTTPS アクセスが可能になります。VPC コネクタ利用時は ENI (Elastic Network Interface) が作成されるため、指定するサブネットに十分な IP アドレス空間を確保する必要があります。オブザーバビリティ面では、X-Ray トレーシングを有効にすることでリクエストのレイテンシとエラーの分散トレースを可視化できます。CloudWatch にはアクセスログとアプリケーションログが自動送信され、メトリクスとして HTTP 2xx/4xx/5xx カウントやレスポンスタイムが記録されます。ヘルスチェックは HTTP パスまたは TCP で設定でき、異常インスタンスの自動置換が行われます。

自動スケーリングとコスト構造

App Runner はリクエスト数に基づく自動スケーリングを標準で提供します。Auto Scaling Configuration で同時リクエスト数の閾値 (デフォルト 100)、最小インスタンス数 (1 〜 25)、最大インスタンス数 (最大 25) を設定できます。トラフィックが減少するとインスタンスを自動的に削減し、最小インスタンス数まで縮退します。一時停止 (Pause) 機能を使うとコンピューティング容量がゼロになり、停止している間の課金は発生しません。ここから料金の構造を整理します (2026 年 8 月時点・東京リージョン。月額はいずれも 730 時間換算)。単価は vCPU あたり 0.0809 USD/時、メモリ 1 GB あたり 0.00885 USD/時です。アクティブなインスタンスには vCPU とメモリの両方が課金され、プロビジョニング済み (待機中) のインスタンスにはメモリ料金のみが課金されます。この待機中のメモリ課金が、最小インスタンス数を 1 以上に保ってコールドスタートを避ける構成の下限コストになります。たとえば 1 vCPU / 2 GB メモリの構成を常時稼働させると約 72.0 USD/月です。同じ東京リージョンで ECS Fargate の同等構成 (1 vCPU / 2 GB) を常時稼働させると約 45.0 USD/月で、これに ALB のコストが加わります。ALB は固定料金が 0.0243 USD/時 (約 17.7 USD/月)、加えて LCU (ロードバランサーキャパシティユニット) が 0.008 USD/時なので、小規模で常時 1 LCU を消費する想定なら合計約 23.6 USD/月です。つまり常時フル稼働の総額は Fargate + ALB が約 68.6 USD/月、App Runner が約 72.0 USD/月で、単価だけを見れば App Runner が安くなるわけではありません。App Runner のコスト面の強みが出るのは、トラフィックに波がある場合です。夜間や休日のアクセスがほぼ無いサービスなら待機中はメモリ料金だけ (2 GB で約 12.9 USD/月) に落ち、使わない期間は一時停止で課金そのものを止められます。一方 ALB は通信量に関係なく固定料金が発生し続けます。判断は単価表の比較ではなく、想定する稼働パターンに基づいて行ってください。

VPC 統合とセキュリティ

App Runner はデフォルトでパブリックなエンドポイントを提供しますが、 VPC コネクタを使用することでプライベートサブネット内のリソース (RDS 、 ElastiCache 、 DynamoDB VPC エンドポイントなど) にアクセスできます。 VPC コネクタはサブネットとセキュリティグループを指定して作成し、 App Runner サービスに関連付けます。アウトバウンド通信のみが VPC を経由し、インバウンドは引き続き App Runner のマネージドエンドポイントで受け付けます。 WAF (Web Application Firewall) との統合により、 App Runner のエンドポイントに WAF WebACL を関連付けて、 IP 制限やレートリミットなどのセキュリティルールを適用できます。 Secrets Manager や Systems Manager Parameter Store との統合により、データベースの認証情報や API キーを安全に管理し、環境変数として注入できます。 IAM によるアクセス制御、 CloudWatch によるメトリクス監視 (リクエスト数、レイテンシ、 HTTP ステータスコード)、 CloudWatch Logs へのアプリケーションログ出力も標準で提供されます。

ECS/Fargate との使い分け

App Runner と ECS/Fargate はどちらもコンテナワークロードを実行しますが、対象ユースケースが異なります。App Runner は HTTP/HTTPS ベースの Web アプリケーションや API に特化しており、リクエスト駆動のスケーリングが標準です。一方、ECS/Fargate はバッチ処理、ワーカープロセス、gRPC、WebSocket、サイドカーパターンなど幅広いワークロードに対応します。 選択の判断基準は以下のとおりです。App Runner を選ぶべきケースは、HTTP/HTTPS の Web アプリや API を素早くデプロイしたい場合、インフラ管理を最小限にしたい場合、チームにコンテナオーケストレーションの専門知識が少ない場合です。ECS/Fargate を選ぶべきケースは、サイドカーコンテナやサービスメッシュが必要な場合、TCP/UDP プロトコルを使用する場合、タスク配置戦略やキャパシティプロバイダーの細かな制御が必要な場合、バッチ処理やキューワーカーなど非 HTTP ワークロードの場合です。EKS は Kubernetes エコシステムとの互換性が必要な場合や、マルチクラウド戦略でワークロードのポータビリティを重視する場合に選択します。App Runner は ECS/Fargate より抽象度が高く、設定できる項目を絞る代わりに構成の手間を省く設計です。制御の柔軟性とシンプルさのトレードオフと捉えると選びやすくなります。Elastic Beanstalk も簡易デプロイを提供しますが、裏側で EC2 や ALB のリソースが可視化されて管理でき、カスタマイズ幅が広い反面、管理対象リソースが増えます。Dockerfile 不要で CI/CD も不要、VPC や ALB の設定を省きたい場合は App Runner が最適です。

まとめ - App Runner の活用指針

AWS App Runner は、コンテナ化された Web アプリケーションを最小限の設定でデプロイ・運用するためのサービスです。ソースコードまたはコンテナイメージを指定するだけで、ビルド・デプロイ・ TLS ・ロードバランシング・ Auto Scaling が自動的に構成されます。VPC コネクタによるプライベートリソースへのアクセス、WAF 統合によるセキュリティ強化、Secrets Manager との連携による認証情報管理など、本番運用に必要な機能も備えています。ECS/Fargate と比較して制御の柔軟性は劣りますが、ALB やターゲットグループの設定が不要なため、小〜中規模の Web アプリケーションでは運用負荷を大きく下げられます。コスト面は稼働パターン次第で、常時フル稼働なら Fargate + ALB とほぼ同水準、トラフィックに波があるほど App Runner が有利になります。コンテナデプロイの第一歩として、あるいはプロトタイプの迅速な公開手段として、App Runner は有力な選択肢です。