# Scheduling 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.

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

---

## 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.