AWS App Runner for Container Deployments

AWS App Runner is a fully managed service that enables developers to quickly deploy containerized web applications and APIs without managing infrastructure. It automatically builds, deploys, scales, and load balances applications from source code (stored in GitHub or AWS CodeCommit) or from an existing container image in Amazon ECR (Elastic Container Registry) or Docker Hub.

App Runner is designed for applications that are:

When you create an App Runner service, the following steps occur:

1. Source Configuration: You specify the source of your application. Options: - Source code from a repository: Provide a connection to GitHub or AWS CodeCommit. App Runner uses a build configuration file (apprunner.yaml) or detects the runtime automatically. - Container image from a registry: Provide the image URI from Amazon ECR (public or private) or Docker Hub.

6. Scaling: App Runner automatically scales the number of instances based on request traffic. You can configure: - Min instances: Minimum number of instances running (default 1, can be 0 for cost savings). - Max instances: Maximum number of instances (default 10, max 200). - Concurrency: Maximum number of concurrent requests per instance (default 100).

Using AWS CLI:

# Create a service from source code
aws apprunner create-service --service-name my-service \
  --source-configuration '{"AuthenticationConfiguration":{},"CodeRepository":{"RepositoryUrl":"https://github.com/user/repo","SourceCodeVersion":{"Type":"BRANCH","Value":"main"},"CodeConfiguration":{"ConfigurationSource":"API","CodeConfigurationValues":{"Runtime":"NODEJS_16","BuildCommand":"npm install && npm run build","StartCommand":"npm start"}}}}' \
  --instance-configuration '{"Cpu":"1 vCPU","Memory":"2 GB"}'

# Create a service from an image in ECR
aws apprunner create-service --service-name my-image-service \
  --source-configuration '{"AuthenticationConfiguration":{},"ImageRepository":{"ImageIdentifier":"123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest","ImageRepositoryType":"ECR"}}'

# List services
aws apprunner list-services

# Describe service
aws apprunner describe-service --service-arn arn:aws:apprunner:us-east-1:123456789012:service/my-service/abc123

# Start deployment
aws apprunner start-deployment --service-arn arn:aws:apprunner:us-east-1:123456789012:service/my-service/abc123

A SaaS company needs to deploy a stateless REST API microservice that handles authentication and user management. The team uses App Runner because it abstracts infrastructure and integrates with their GitHub repository. They configure automatic deployments from the main branch. The service uses Node.js 18 with a build command npm install && npm run build and start command npm start. They set minimum instances to 2 for high availability and maximum to 20 to handle traffic spikes during peak hours. Concurrency is set to 200 requests per instance. They enable VPC Connector to access an RDS database in their VPC. In production, they observe that cold starts occur when scaling from 2 to 3 instances during a spike, but the auto-scaling handles it within seconds. They use CloudWatch alarms to notify if error rates exceed 1%. The main challenge was configuring the VPC Connector correctly—the ENI must be in a subnet with a route to a NAT gateway for internet access (App Runner instances need internet to pull images). Misconfiguring security groups caused connectivity issues. They also learned that App Runner does not support sticky sessions, so their stateless design was appropriate.

A marketing agency hosts a customer-facing web application built with Python Flask and served via uWSGI. They containerize the app and push the image to Amazon ECR. They create an App Runner service pointing to the image, set minimum instances to 1, and maximum to 10. They configure a custom domain app.example.com with a TLS certificate from ACM. They set health check path to /health and interval to 5 seconds. During a campaign launch, traffic surges and the service scales to 10 instances. The application handles the load without issues. However, they notice that the default health check path / was returning a 302 redirect, causing health checks to fail. They fixed it by setting the health check path to /health. They also enabled access logs to analyze traffic patterns. The main performance consideration is that App Runner's scaling is based on requests per instance, not CPU/memory, so they monitor concurrency to avoid overwhelming instances.

An internal IT team deploys a dashboard that is used occasionally during business hours. They set minimum instances to 0 to save costs. When a user accesses the dashboard after idle time, there is a 5-10 second cold start delay as App Runner provisions a new instance. They find this acceptable. They use a private ECR repository and configure automatic deployment when a new image is pushed. The main challenge was ensuring that the IAM execution role had permissions to pull from ECR. They also learned that with min=0, the first request may timeout if the cold start takes too long, so they set a higher idle timeout in their application.