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 don't need to think about VPC configuration, load balancer setup, task definitions, or service discovery at all. It's optimal 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 mesh (App Mesh), 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 and isn't suited for WebSocket or streaming responses. As a guideline: App Runner for simple web apps, Fargate for production microservices, Lambda for event-driven processing.
Deployment Pipeline and Auto-Scaling Mechanics
App Runner supports two deployment sources: ECR container images and GitHub repositories. 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 Python, Node.js, Java, Go, .NET, Ruby, and PHP runtimes, 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) 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. For a deeper understanding of container deployment strategies, books on container deployment (Amazon) are a great resource.
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 provisioned instance vCPU and memory, with standard rates during active request processing and lower standby rates during idle periods.