Scheduling AWS App Runner Service
apprunner:PauseServiceCan ZopNight schedule AWS App Runner Service?
App Runner has a purpose-built pause. apprunner:PauseService releases the provisioned container instances that bill even with zero traffic, and apprunner:ResumeService brings them back. The service URL and custom domains survive, but a paused service rejects deployments, and requests fail until resume completes, typically within 1-2 minutes.
How the stop works
| Field | Value |
|---|---|
| Behaviour | service paused via apprunner:PauseService on stop and resumed via apprunner:ResumeService on start. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
Pause is a first-class verb here
Most compute services need a scale-to-zero workaround. App Runner does not. The schedule calls
apprunner:PauseService at the stop time and apprunner:ResumeService at the start time, and the
platform handles the rest.
The reason the pause is worth money: App Runner bills for provisioned container instances whether or not they receive requests. A service that idles all night still pays the provisioned-memory rate for every warm instance. Pausing releases those instances and ends that charge.
Identity survives, availability does not
A paused service keeps its default URL, its custom domains, its TLS certificates, its autoscaling configuration and its environment variables. Nothing needs to be re-created in the morning.
What callers experience is a hard failure. There is no queueing and no held connection. A request to a paused service simply does not get served. Anything that polls the service overnight, including uptime monitors, will page you unless it is told about the window.
Deployments bounce off a paused service
An overnight CI run that pushes a new image and expects App Runner’s auto-deploy to pick it up will not succeed while the service is paused. The deployment goes through once the service is resumed. Teams that ship at odd hours should either schedule around the release window or accept that the morning resume is also the morning deploy.
Resume needs a head start
Resuming provisions fresh container instances and waits for the health check to pass before traffic flows. Budget a couple of minutes and set the start cron earlier than the first expected request, not at the same moment.
Sizing the saving
The overnight saving is the provisioned-instance charge multiplied by the paused hours. For a staging service on a weekday 8am-6pm window, that is 118 of 168 hours each week, roughly 70% of the provisioned-instance line. Request-driven active charges were already zero overnight, so those do not change.