AWS App Runner
A fully managed service that automatically builds, deploys, and scales web applications and APIs from container images or source code
Overview
AWS App Runner is a fully managed service that lets you deploy and operate containerized web applications and APIs without any infrastructure knowledge. Simply specify an ECR container image or a GitHub repository with source code, and the build, deployment, TLS termination, load balancing, and auto-scaling are automatically configured. When traffic drops to zero, instances scale down to the minimum count, and they automatically scale out as requests increase.
Selection Criteria vs. ECS Fargate and Lambda
App Runner, ECSFargate, and Lambda can all run containers or code in a serverless fashion, but they differ in the trade-off between abstraction level and control. App Runner has the highest abstraction level - you rarely need to think about VPC configuration, load balancer setup, task definitions, or service discovery. It's well suited for quickly deploying web applications and REST APIs. ECS Fargate offers more control than App Runner, letting you fine-tune container CPU/memory, sidecar containers, volume mounts, and health checks through task definitions. It includes production-ready features like service-to-service communication control (ECS Service Connect), service discovery (Cloud Map), and Blue/Green deployments (CodeDeploy integration). Choose Fargate for microservice architectures or complex networking requirements. Lambda specializes in event-driven function execution and supports triggers beyond HTTP requests (S3 events, SQS messages, schedules). However, it has a 15-minute execution time limit (as of September 2026) and isn't suited for workloads that hold long-lived connections. The typical division of labor has been: App Runner for simple web apps, Fargate for production microservices, and Lambda for event-driven processing. However, AWS has closed App Runner to new customers (as of September 2026; existing customers can continue to use it), so for new builds, ECS Fargate and Lambda are the realistic choices.
Deployment Pipeline and Auto-Scaling Mechanics
App Runner supports two kinds of deployment sources: ECR container images and source code repositories such as GitHub or Bitbucket. With ECR sources, you can configure automatic deployment triggered by image pushes, so deployment completes simply by pushing an image to ECR from your CI/CD pipeline. With GitHub sources, App Runner automatically builds and deploys the source code. It supports managed runtimes for several languages (see the official documentation for the current list), with build and start commands defined in apprunner.yaml. Auto-scaling operates based on concurrent request count - when the maximum concurrent requests per instance (default 100, as of September 2026) is exceeded, it scales out. Setting the minimum instance count to 1 keeps one instance always running even with zero traffic, avoiding cold starts. The minimum cannot be set to 0, so if you need true scale-to-zero, consider Lambda instead. During deployment, rolling updates are performed automatically, with traffic switching to the new version only after it passes health checks.
VPC Connectivity and Private Resource Access
App Runner has a public endpoint by default, but by configuring a VPC connector, you can access private resources within a VPC (RDS, ElastiCache, DocumentDB, etc.). A VPC connector establishes a network connection between the App Runner service and the VPC, reaching private resources through specified subnets and security groups. An important caveat: once a VPC connector is configured, all outbound traffic from App Runner routes through the VPC, so a NAT Gateway is required for internet access. This incurs additional costs, so cost estimation is necessary upfront for applications that call external APIs. For inbound traffic, App Runner's private endpoint feature lets you build internal services accessible only from within the VPC. This is ideal for internal admin dashboards or inter-microservice communication that shouldn't be exposed to the internet. Pricing is based on hourly charges for instance vCPU and memory, and what is billed differs between active request processing and idle periods, so see the official AWS pricing pages for details.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon ECS official page
- AWS Fargate official page
- Amazon ECR official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.