# AWS App Runner Service

> App Runner meters provisioned container instances even while they idle, charging for provisioned memory continuously and adding vCPU charges only while handling requests. Pausing a service stops the provisioned meter entirely. ZopNight discovers services on the 6-hour cycle and pauses them off-hours via apprunner:PauseService, resuming with apprunner:ResumeService.

Source: https://zop.dev/integrations/aws/apprunner
Updated: 2026-08-19

---

AWS App Runner runs containerized web applications and APIs from source or an image, with managed scaling and load balancing. Provisioned container instances bill even while idle, which makes pausing non-production App Runner services an easy saving.

## Memory always, vCPU on demand

App Runner's meter splits by state. A provisioned container instance that is idle bills for its memory allocation only. That is the warm standby that lets it answer the next request without a cold start. When requests arrive, the instance becomes active and bills for vCPU as well. Automatic scaling adds and removes instances with traffic, but the configured minimum size of provisioned instances never drops below one per service, so every service carries a permanent memory-hours floor. Build resources for source-based deployments bill separately per build-minute.

## Pause as a first-class cost lever

Uniquely among AWS container services, App Runner has a real pause verb, and ZopNight uses it: services are discovered on the 6-hour cycle, cost is attributed per resource from Cost Explorer or CUR 2.0, and scheduled stops call apprunner:PauseService, with apprunner:ResumeService restoring the service for working hours. A paused service keeps its configuration and URL but drops its provisioned instances, taking the memory floor to zero for the paused hours. Idle-service recommendations cover the rest: services whose request counts suggest pausing should be permanent.

## Small floors, wide sprawl

App Runner waste is rarely dramatic per service; it compounds through count. Preview and demo services deployed from a repository per branch each keep a provisioned instance warm. Internal APIs serving a handful of daily requests pay round-the-clock memory-hours for seconds of active compute. And services whose autoscaling minimum was raised during a launch spike keep the higher floor long after traffic normalized.

## Auditing services and their floors

The App Runner console lists services with status, instance configuration, and autoscaling settings. The per-service metrics show request volume against active instances; a service with single-digit daily requests and a permanently provisioned instance is either a pause-schedule candidate or a case for moving the workload to Lambda.