Simplifying Container Deployment - Zero-Configuration Deployment with AWS App Runner

App Runner's Role and Container Deployment Challenges

When deploying containerized web applications to AWS, the traditional approach has been to use ECS (Elastic Container Service) or EKS (Elastic Kubernetes Service). However, these services require configuring numerous resources such as cluster management, task definitions, service definitions, load balancers, target groups, and security groups, demanding significant infrastructure knowledge. AWS App Runner, released in 2021, is a fully managed container application service that completely abstracts away this complexity. Simply specify a source code repository (GitHub) or container image (ECR), and App Runner automatically handles building, deployment, scaling, load balancing, and TLS termination. Developers can focus on application code and deploy to production without infrastructure expertise, as long as they have a Dockerfile. Note that App Runner has stopped accepting new customers and is now available only to existing customers (as of August 2026); for new container deployments, options such as ECS (Express Mode) are the way forward.

Deployment Methods and Source Configuration

App Runner supports two source types. The first is a container image source, where you specify an ECR image (public or private). You can also configure automatic deployment triggered by image pushes to ECR. The second is a source code repository, where you connect a GitHub repository and App Runner handles everything from build to deployment. If you select a managed runtime, it works by simply specifying the build and start commands without needing a buildspec.yml (the supported runtimes are covered in the next section).

# App Runner service definition in CloudFormation
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'

For instance configuration, you choose from combinations of vCPU (0.25 / 0.5 / 1 / 2 / 4) and memory (0.5 to 12 GB). Unlike ECS Fargate, which requires separate configuration of task definitions, service definitions, ALB, listeners, and target groups, App Runner completes deployment with a single resource definition.

GitHub Integration and Source Code Deployment in Practice

With source-based deployment, you connect a GitHub repository and App Runner automatically builds a container image from your code and deploys it. Several managed runtimes are available, including Python, Node.js, Java (Corretto), Go, .NET, PHP, and Ruby; selecting one of them allows deployment without writing a Dockerfile. Runtime versions are added and reach end of support from time to time, so check the official documentation for the current support status when you start. By placing an apprunner.yaml file at the repository root, you can declaratively define build commands, start commands, runtime versions, and environment variables, enabling infrastructure configuration to be version-controlled alongside your code. GitHub integration offers a choice between automatic and manual deployment. With automatic deployment enabled, pushes to the specified branch trigger builds and deployments automatically, eliminating the need to set up a separate CI/CD pipeline. With manual deployment, you explicitly trigger deployments from the console or API. Automatic builds cost $0.005 per minute, so repositories with frequent pushes should be aware of accumulating build charges. In addition, a fixed fee of $1 per month applies to each application with automatic deployment enabled (as of August 2026, Tokyo region).

Custom Domains and Observability

Custom domain configuration is completed by entering the domain name in the console and adding a CNAME record to your DNS provider (Route 53 or an external DNS service). An ACM (AWS Certificate Manager) certificate is automatically issued and renewed, enabling HTTPS access on your custom domain. When using VPC connectors, ENIs (Elastic Network Interfaces) are created, so the specified subnets must have sufficient IP address space available. For observability, enabling X-Ray tracing allows you to visualize distributed traces of request latency and errors. Access logs and application logs are automatically sent to CloudWatch, with metrics recording HTTP 2xx/4xx/5xx counts and response times. Health checks can be configured with HTTP path or TCP, and unhealthy instances are automatically replaced.

Auto Scaling and Cost Structure

App Runner provides request-based auto scaling as a standard feature. The Auto Scaling Configuration lets you set the concurrent request threshold (default 100), minimum instance count (1 to 25), and maximum instance count (up to 25). When traffic decreases, instances are automatically reduced down to the minimum count. The Pause feature reduces compute capacity to zero, and no charges accrue while the service is paused. Here is how the cost structure breaks down (as of August 2026, Tokyo region; all monthly figures assume 730 hours). The unit prices are $0.0809 per vCPU-hour and $0.00885 per GB-hour of memory. Active instances are charged for both vCPU and memory, while provisioned (idle) instances are charged only for memory. This idle memory charge is the cost floor for a configuration that keeps the minimum instance count at 1 or more to avoid cold starts. For example, running a 1 vCPU / 2 GB memory configuration around the clock costs approximately $72.0/month. Running the equivalent ECS Fargate configuration (1 vCPU / 2 GB) around the clock in the same Tokyo region costs approximately $45.0/month, and the cost of an ALB is added on top. An ALB has a fixed charge of $0.0243/hour (approximately $17.7/month) plus $0.008/hour per LCU (load balancer capacity unit), so for a small workload that constantly consumes 1 LCU the total comes to approximately $23.6/month. In other words, at constant full utilization the totals are approximately $68.6/month for Fargate + ALB versus approximately $72.0/month for App Runner, so App Runner is not cheaper on unit prices alone. Where App Runner's cost advantage shows is when traffic fluctuates. For a service with almost no access at night or on weekends, idle periods drop to the memory charge alone (approximately $12.9/month for 2 GB), and pausing during unused periods stops billing altogether. An ALB, by contrast, keeps incurring its fixed charge regardless of traffic volume. Base your decision on the expected usage pattern rather than on a comparison of price tables.

VPC Integration and Security

App Runner provides a public endpoint by default, but VPC connectors allow access to resources in private subnets (RDS, ElastiCache, DynamoDB VPC endpoints, etc.). Create a VPC connector by specifying subnets and security groups, then associate it with your App Runner service. Only outbound traffic routes through the VPC; inbound traffic continues to be received through App Runner's managed endpoint. WAF (Web Application Firewall) integration lets you associate a WAF WebACL with the App Runner endpoint to apply security rules such as IP restrictions and rate limiting. Integration with Secrets Manager and Systems Manager Parameter Store enables secure management of database credentials and API keys, injecting them as environment variables. IAM-based access control, CloudWatch metrics monitoring (request count, latency, HTTP status codes), and application log output to CloudWatch Logs are all provided as standard features.

Choosing Between ECS/Fargate and App Runner

Both App Runner and ECS/Fargate run container workloads, but they target different use cases. App Runner specializes in HTTP/HTTPS-based web applications and APIs, with request-driven scaling as the default. ECS/Fargate, on the other hand, supports a wide range of workloads including batch processing, worker processes, gRPC, WebSocket, and sidecar patterns. Here are the criteria for choosing between them. Choose App Runner when you want to quickly deploy HTTP/HTTPS web apps or APIs, when you want to minimize infrastructure management, or when your team has limited container orchestration expertise. Choose ECS/Fargate when you need sidecar containers or a service mesh, when using TCP/UDP protocols, when you need fine-grained control over task placement strategies and capacity providers, or for non-HTTP workloads like batch processing and queue workers. Choose EKS when you need compatibility with the Kubernetes ecosystem or when workload portability is a priority in a multi-cloud strategy. App Runner offers a higher level of abstraction than ECS/Fargate: it narrows the set of configurable items in exchange for eliminating setup effort. Viewing it as a trade-off between control flexibility and simplicity makes the choice easier. Elastic Beanstalk also provides simplified deployment, but the underlying EC2 and ALB resources are visible and manageable, offering broader customization at the cost of increased operational resources. When you want to skip Dockerfiles, CI/CD setup, and VPC/ALB configuration entirely, App Runner is the optimal choice.

Summary - Guidelines for Using App Runner

AWS App Runner is a service for deploying and operating containerized web applications with minimal configuration. Simply specify source code or a container image, and build, deployment, TLS, load balancing, and auto scaling are automatically configured. It also provides features needed for production operations, including VPC connector access to private resources, WAF integration for security hardening, and Secrets Manager integration for credential management. While it offers less control flexibility compared to ECS/Fargate, the elimination of ALB and target group configuration greatly reduces operational overhead for small to medium-sized web applications. On the cost side it depends on the usage pattern: at constant full utilization it is roughly on par with Fargate + ALB, and the more traffic fluctuates, the more advantageous App Runner becomes. App Runner is a strong choice as a first step into container deployment or as a means to quickly publish prototypes.