コンテナデプロイの簡素化 - 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 さえあればインフラの知識なしに本番環境へデプロイできます。Azure Container Apps も同様のコンセプトを持つサービスですが、App Runner は ECR・Secrets Manager・Systems Manager Parameter Store との統合が深く、AWS エコシステム内での運用効率が高い点が特徴です。Azure Container Apps は Dapr (分散アプリケーションランタイム) との統合やリビジョン管理の柔軟性で優れる一方、App Runner はセットアップの簡素さで上回ります。

この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。

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

App Runner は 2 つのソースタイプをサポートします。1 つ目はコンテナイメージソースで、ECR (パブリックまたはプライベート) のイメージを指定します。ECR へのイメージプッシュを検知して自動デプロイする設定も可能です。2 つ目はソースコードリポジトリで、GitHub リポジトリを接続し、App Runner がビルドからデプロイまでを一貫して実行します。Python と Node.js のマネージドランタイムが提供されており、buildspec.yml 不要でビルドコマンドと起動コマンドを指定するだけで動作します。 ```yaml # 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 つのリソース定義でデプロイが完結します。

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

App Runner はリクエスト数に基づく自動スケーリングを標準で提供します。Auto Scaling Configuration で同時リクエスト数の閾値 (デフォルト 100)、最小インスタンス数 (1 〜 25)、最大インスタンス数 (最大 25) を設定できます。トラフィックが減少するとインスタンスを自動的に削減し、最小インスタンス数まで縮退します。一時停止 (Pause) 機能を使えばインスタンスをゼロにでき、メモリ料金のみの課金となります。料金体系は vCPU あたり 0.064 USD/時、メモリ GB あたり 0.007 USD/時です。アクティブなインスタンスには vCPU + メモリの両方が課金され、プロビジョニング済み (待機中) のインスタンスにはメモリ料金のみが課金されます。たとえば 1 vCPU / 2 GB メモリの構成で月 730 時間稼働した場合、約 56.9 USD/月です。ECS Fargate の同等構成 (1 vCPU / 2 GB) は約 44.3 USD/月ですが、App Runner は ALB (約 22.3 USD/月〜) が不要なため、小規模なサービスでは App Runner の方がトータルコストで有利になるケースがあります。

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 の上に構築されたより高い抽象化レイヤーであり、制御の柔軟性とシンプルさのトレードオフです。

さらに詳しく知りたい方は、関連書籍 (Amazon) で理解を深められます。

まとめ - App Runner の活用指針

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