AWS App Runner Service
Does ZopNight manage 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.
Rules that fire on AWS App Runner Service
No active rule family targets AWS App Runner Service today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Stop verb | apprunner:PauseService |
| Scheduling notes | service paused via apprunner:PauseService on stop and resumed via apprunner:ResumeService on start. |
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.