AWS App Runner Costs: Pause, Resume and Idle Memory

How App Runner charges

App Runner has two instance states on its pricing page. When an application is idle you pay per GB of memory for provisioned container instances that keep it warm. When it processes requests you pay for active instances, which consume compute and memory. So a service nobody calls overnight still carries its provisioned memory charge.

Note that AWS has announced App Runner is no longer open to new customers; existing customers can keep using it.

What pausing does

AWS documents that pausing a service reduces its compute capacity to zero. Resuming provisions new capacity and redeploys the version that was running, without a rebuild, and the App Runner domain stays the same. Two consequences matter for a schedule:

• State is lost. Any ephemeral storage the code used is gone after a pause; for the code, it is like deploying to a new service.
• New versions wait. Source versions pushed during the pause are not deployed automatically on resume, even with automatic deployment on. And while paused, you cannot start a deployment or update the service.

ZopNight and App Runner

App Runner is on ZopNight’s Start/Stop supported list as pause and resume. A schedule pauses services in the evening and resumes them before working hours, in your timezone, attached to one service or a resource group. Overrides keep a service running for a late demo, and expire on their own. Each pause and resume lands in the state history with what triggered it, and notifications can go to Slack, Teams, Google Chat or a webhook.

There are no App Runner-specific recommendation rules in ZopNight’s rule reference, so the value here is the schedule and the cost visibility, not a findings list. Scheduled execution needs a read + write connection.

Related

The App Runner fact sheet and App Runner scheduling cover the details. For the scheduling model across services, see scheduling.