AWS App Runner takes a container image or a source repository and hands back an HTTPS URL. What does it create on your behalf, what does it scale on, and how are you billed when no requests are arriving?

## What App Runner replaces App Runner is the most opinionated container service AWS sells. On a typical container deployment you would create a cluster or capacity provider, a task or service definition, a load balancer, a target group, a listener, a certificate, security groups, and scaling policies. App Runner replaces all of that with one resource: a *service*. There is no cluster to size, no load balancer in your account, and no certificate to renew — the HTTPS endpoint on `*.awsapprunner.com` is provisioned with an AWS-managed certificate, and a custom domain can be attached with validation records. ## Two source types A service is created from either: - **an image**, from a private or public ECR repository. App Runner pulls it using an *access role* you grant, and can redeploy automatically when a new image is pushed to the tracked tag; - **source code**, from a GitHub or Bitbucket connection. App Runner builds it with a managed runtime (Python, Node.js, Java, .NET, Go, PHP, Ruby) and either the build/start commands you supply in the console or an `apprunner.yaml` in the repository root, and can auto-deploy on every push to the tracked branch. The container itself gets an **instance role** for the AWS API calls your application makes — the same separation ECS draws between pulling the image and running the code. ## The scaling model, and why it is not CPU-based An Auto Scaling group scales on a metric such as average CPU. App Runner scales on **concurrency**: the auto scaling configuration sets *max concurrency* — how many requests one instance handles simultaneously — plus *min size* and *max size*. When the number of in-flight requests would exceed max concurrency on the existing instances, App Runner starts another, up to max size; when load falls, it retires instances back down toward min size. This is the request-driven model, and it fits HTTP services whose cost is dominated by concurrent request handling. It fits badly when work is not request-shaped: a service whose load is a background queue drain looks idle to App Runner no matter how busy it is. Max concurrency is a real tuning knob. Set it to 1 and you get one request per instance — strong isolation for a thread-unsafe or heavily CPU-bound app, at the price of many instances and a much higher chance of hitting max size under a burst. Set it high and you pack more requests per instance, using CPU better but risking queueing inside your own process. ## The billing model, and what "idle" means App Runner splits the bill. **Provisioned memory** is billed for every instance that exists, including warm min-size instances with nothing to do. **CPU** is billed only while an instance is actively processing requests. So a service at zero traffic with min size 1 is not free, but it is cheap — you pay to keep a warm container ready, and warm is exactly what buys you the absence of cold starts. The non-obvious consequence is behavioural rather than financial: between requests, an instance's CPU is throttled. **Background threads, in-process schedulers and async work kicked off after the response is written are unreliable** — they may make almost no progress until the next request arrives. Anything periodic belongs outside the request path (for example a scheduled event that calls an endpoint), not in a timer thread inside the container. ```yaml # apprunner.yaml — source-code services version: 1.0 runtime: nodejs18 build: commands: build: - npm ci run: command: node server.js network: port: 8080 ``` ## Networking By default outbound traffic leaves over AWS-managed networking, which is fine for calling public AWS APIs but cannot reach anything in a private subnet. To talk to an RDS instance, an ElastiCache cluster or an internal service, you attach a **VPC connector**: you nominate subnets and security groups, App Runner creates network interfaces there, and the database's security group allows the connector's. Once egress is routed through the VPC, calls to the public internet need the usual route through a NAT gateway — the identical trap that catches functions placed in a VPC. Inbound can also be made private through an interface VPC endpoint, so the service is not reachable from the internet at all. ## Where it stops One container per service, one HTTP port, no sidecars, no direct control of the load balancer, no non-HTTP protocols. Those limits are the whole product: App Runner is for a stateless HTTP service you want online without operating a platform, and the moment you need a second container next to it, the abstraction is the wrong shape.