SysPad › Lessons › compute lessons › AWS App Runner

How AWS App Runner works

DEPRECATED BY AWS: App Runner entered maintenance mode in March 2026 and is closed to new customers since April 2026. Kept for existing architectures; for new designs use ECS Fargate or ECS Express Mode. Fully managed containerized web apps with automatic scaling and load balancing.

Sometimes you just have a web app or API and want it online, without touching load balancers, clusters, scaling policies, or TLS certs. App Runner is the "here’s my code, run it" button: give it a repo or a container image, and it builds, deploys, secures, load-balances, and auto-scales it for you.

What you will learn

What does App Runner do for you that ECS/EKS make you assemble yourself?
How does deploying from source differ from deploying an image?
How does its auto-scaling (including near-zero) work?
When do you outgrow App Runner and need ECS/EKS instead?

Code in, running web app out

App Runner is the most hands-off way to run a containerised web service on AWS. You provide a source repository or a container image; it handles build, deployment, an HTTPS endpoint, load balancing, and scaling. There’s no cluster, load balancer, or scaling policy for you to set up.

Availability note: AWS moved App Runner to maintenance mode in March 2026 and closed it to new customers in April 2026. The managed-container patterns here still apply; AWS points new workloads at ECS Express Mode (the same idea inside ECS), and ECS Fargate remains the closest "just run my container" alternative.

From source or from an image

Point it at a source repo and App Runner builds the container for you on each push (it manages the build). Or point it at an existing image in a registry and it just deploys that.

Either way you get continuous deployment: push or publish a new version and App Runner rolls it out.

⚓ APIs, web backends, and microservices for teams that want speed-to-production over infrastructure control.

Auto-scaling, including near-zero

App Runner scales the number of running instances with request volume, up during spikes, down to a minimum when quiet (it can scale active instances toward zero, keeping you from paying for idle compute beyond a small baseline).

When you outgrow it

App Runner is ideal for straightforward HTTP services. You move to ECS/Fargateor EKS when you need fine-grained control: private-VPC ingress, multiple containers per task with sidecars, special hardware (GPUs), complex scaling, or non-HTTP workloads.

Flashcards

What does App Runner handle that you’d assemble yourself on ECS/EKS?: Build, deploy, HTTPS endpoint, load balancing, and auto-scaling, no cluster, LB, or scaling policy to configure.
Two ways to give App Runner your app?: A source repo (App Runner builds the container) or a prebuilt container image (it just deploys it).
How does App Runner handle quiet periods?: It auto-scales down toward near-zero active instances when idle, and back up with traffic, no manual sizing.
What do you give up choosing App Runner over ECS/EKS?: Control: sidecars, GPUs, private-VPC ingress, complex scaling, and non-HTTP workloads. App Runner trades knobs for simplicity.
Ideal App Runner workload?: A straightforward HTTP web app or API you want online fast with no infrastructure management.

Sources

Open the SysPad canvas · Official AWS App Runner documentation